I’ve participated in a number of on-site technical interviews over the past few years, and one question that has come up over and over again has been something like, “Tell me about a feature you’ve built or a technical challenge you’ve faced”.
I LOVE this question!
In addition to coding questions, this question is another way for the interviewer to see how you approach problem solving. This question is especially good for bootcamp grads or anyone who comes from a non-traditional background, because answering it well is the perfect way to talk about something you’ve actually worked on as opposed to something you learned in school.
Answering this question well is also a big positive signal to your interviewers – being able to explain in detail a technical challenge you faced or a feature you built shows that you will be able to communicate effectively with other engineers.
Why is this important?
Good communication skills will help you advance your career. This skill can set you apart from other engineers who prefer to silo themselves off on projects, locking a lot of important domain knowledge in their heads. This can cause problems for organizations small and large in both the short and long term.
Additionally, there are many aspects of engineering that require good communication skills. For example, onboarding new team members, regular stand-ups and team meetings, technical design reviews, post-mortems, and code reviews are just a few scenarios in which communication about technical topics comes into play.
Also, as you become more senior within an organization, you may have the opportunity to propose adding new technology to the stack or other major changes. Being able to communicate well and get buy in from other teams is incredibly important. Communication in general is a valuable skill, but being able to demonstrate clear technical communication is crucial to your success as an engineer.
So, that brings us back to the question from the beginning of this post.
How should you answer it?
First, you’ll want to come up with a few examples from your own experience. Then, similar to my last post, How to Craft Your Story, you’ll want to write a few drafts for these examples, refine them, and practice and polish them. Over time, as you work on more projects, build more features, and fix more bugs, you’ll collect more of these stories and you’ll have many to choose from depending on the specific interview situation and format of the question.
But, when you’re first starting out, or if you’ve just graduated from a bootcamp, there are plenty of ways to come up with good answers. Think about a project you worked on, and a time that you got REALLY stuck. Did you encounter a strange bug that took you several hours to figure out? Or, did you start building something one way, only to realize a flaw in your initial design, leading you to change the overall architecture? These types of situations can make for great stories! You can also think about a technical problem you faced that was really interesting to you.
Here are some examples from my personal experience to help you get started:
Example 1: Angular Bug
For my final project during my bootcamp, I built an art generator using the MEAN stack (Mongo DB, Express, Angular, and Node.js). The basic concept was that a user would enter some parameters, click a button, and a piece of art would be generated based on those parameters. One of my instructors suggested generating the artwork automatically when parameters changed, rather than only when a button was clicked. I thought this was a cool idea, so I included this in my initial MVP requirements. Little did I know that I would be in for a weird bug!
As I was building my MVP, I noticed a strange flickering of the image that would occur as I was playing around with the parameters. My art generator was using a randomizer method, so what I eventually discovered was that due to Angular 1’s MVVM (Model <> View View <> Model) two-way data binding, each time the model updated based on the changed parameters, the view would also update, and vice versa. However, due to the randomizer method and the fact that I wasn’t actually saving the exact data for the generated art (just the user input) an infinite number of artworks could be generated from the same set of parameters, so the two-way data binding got caught in an infinite loop, causing the flickering in the UI.
After several hours of investigation, I realized what was happening, and I solved the problem by capturing the generated artwork data in the model, so an artwork could be easily reproduced if need be.
Example 2: URL Routing Project
In one of my previous roles, I was looking into our error rates using NewRelic. I noticed that 80% of our errors were
ActiveRecord::RecordNotFounderrors, meaning a request from the client was being made, causing a database call that was then erroring. When I investigated further, I realized that the way our system had originally been set up, any time a request was made to
/<anything>, a database call was being made looking for a record in a specific table. Restful routing had not been set up, and a lot of the extraneous requests we were getting to the
/route were caused by bots.
I came up with a fix for this that required two main steps. The first step was changing all of the places within our codebase that were
/items/<item>following the RESTful pattern. This was actually non-trivial, as there were many places within the codebase that needed to be changed and fully manually tested to ensure there were no broken links. The second step was making sure that old links with
/<item>were backwards compatible. For all items previously created, there were links that already existed in emails and on social media that still needed to work once this routing change was in place. For this, I created a special redirect controller that would get called every time a request to
/<item>was made. I then added a map with all of the previous items up until the change was made – for any request to
/<anything>the redirect controller would check if an item was in that map, and if so, redirect to the appropriate route. If the item wasn’t in that map, it would simply send a 404 response, preventing the call and round trip to the database.
Once this was implemented, we saw a significant reduction in the original
ActiveRecord::RecordNotFounderrors, making our overall error rate dip sharply. This also decreased the overall load on our database by preventing unnecessary requests in the first place.
Now that you’ve read these examples, take some time to think about your own potential answers to this type of question. Here’s how you can think about structuring them:
1. Give context
1. Give context
It’s important to set the stage for your story by providing a bit of context, as it’s very difficult to follow a detailed technical story without the proper frame of reference. As you saw in my first example above, part of the context was that I built my app using the MEAN stack. I then went on to describe the bug that was partially caused by a pattern used by Angular. In my second example, the context was the initial error rate I saw that made me want to investigate the errors further in the first place.
2. Describe the bug, challenge, or project
You’ll want to give enough technical detail so that the interviewer can follow your story, but not so much that it gets bogged down in the details. Many experienced interviewers may have encountered similar blockers and challenges themselves, so they will understand how you’ve felt if you describe the circumstances well – they’ve likely been in your shoes!
3. Explain what was tricky about the implementation or why it was hard to debug
Were you under intense time pressure? Was the environment you were working in not easy to debug in? Was there a business or other requirement (like the backwards compatibility I mentioned above) that made the project especially challenging? Being able to describe the symptoms of the problem clearly is an important skill to have as an engineer.
4. Explain how you solved the problem and the positive impact it had, if any
Was it just a matter of googling the right phrases? Did you have to read several pieces of documentation or Stack Overflow posts? Did you just try a bunch of different solutions until you found something that worked? Did you learn something new about how a tool or piece of technology you were using worked? Did you have to go read some source code?
It doesn’t really matter how you solved the problem, but explaining your solution demonstrates that you were willing to try different approaches to get something to work. When you solve a problem, not only do you get the sense of satisfaction, but in describing a story to your interviewer, it also demonstrates that you don’t give up easily and you’re willing to tackle difficult problems. After all, solving hard problems is part of the job!
These four steps make up my framework for answering this common interview question. This is a great question to master because it demonstrates your technical communication skills, which as I’ve explained above, are critical to your career growth.
Do you have a good story from a bug you’ve solved or technical challenge you’ve faced? I’d love to hear about it! Email me at firstname.lastname@example.org.