Last week, I got to experience my first technical interview... ever! To be fair, there were some aspects of it that probably aren't typical of actual technical interviews. But nonetheless, I walked away feeling grateful. I wanted to write a little blog post about the experience in the hope that others can take something away from this, especially if you've never gone through a technical interview.
A Quick Refresher About Technical Interviews
The actual makeup of a technical interview depends from company to company. But they all pretty much have the same objective: evaluate the candidate's ability to solve problems and put the solutions to code. Before the emergence of COVID-19, technical interviews were almost always done with a whiteboard. For my particular interview, we used CodeSandbox instead.
The point of this kind of interview isn't necessarily about finding "the right answer". It's about showcasing what your thinking process is like as you tackle complex problems.
As part of Flatiron School Career Services, I had the opportunity to be interviewed by a seasoned engineer in the industry. I was interviewed by a person who works at a large company in Boston who has been in the industry for 10 years. From the moment we started the virtual call, I felt like I was in good hands. They were kind, patient and incredibly supportive during the whole process.
I was tasked with turning all the keys of a valid JSON string from kebab-case to camel-case within 40 minutes. During the first 10 minutes, to my surprise, I had already decided how I was going to tackle the problem, I spoke out in pseudocode and then typed it out. Eventually, after stumbling through an important edge case, I was able to pass through the first part of the problem with about 10 minutes to spare.
Next, for the second and final part of the problem, I was asked how I would refactor my answer to account for nested objects (specifically, JSON objects with kebab-cased keys). This definitely leveled up the challenge of the problem, but I was able to almost solve the second part. However, I ran out of time and I was 1-2 lines away from solving it. There's gonna be an upcoming post about just that!
Aftermath & Final Thoughts
All in all, I felt confident coming out of the interview because I was able to communicate my thoughts out loud and translate them to code. The few things I should work on to make the next technical interview even more successful:
Practice common technical interview questions. A lot of them.
When thinking out loud, do so one step at a time and don't rush into the solution.
- This could lead to a time-consuming refactor later on. It's important to thinking about now but also about the future.
Become familiar with Array and Object methods/ manipulation.
- These are two of the most common datatypes in the software industry.
- Depending on the language, look into things like map, reduce, transform, forEach, for..in, for..of, select, and filter.