A “strong yes” technical interview.
It actually starts before the interview, you’ve done your research. You have context into the company, maybe even into your interviewer and their role. These things are indicators that you are taking this process seriously.
I always ask a few questions to get to know you better before we jump into the technical portion. When you answer these questions about your past roles and ideal future position I can tell that you are passionate. You are proud of the things you’ve built in the past, enjoy challenges, and love taking ownership.
When we hop into the coding pad you choose a language you are comfortable in, the one you use every day at work is perfect. If you show proficiency in one language, I’m confident that you can pick up the tech that we use.
As the question and requirements are explained you take notes of information that you think will be important.
To ensure you understand the breadth of the question you repeat the question back and ask clarifications. This indicates to me which pieces of information you are deeming as important to the solution.
When it’s time to think of a solution you brainstorm multiple approaches and weigh the trade-offs. You might bounce some ideas off me to get my opinion- it’s great to get a glimpse of how we would collaborate together.
Once we’ve decided on an approach you plan the solution fully. By the end of the planning phase, we are both confident about where we will be once everything has been coded. You might choose to write some light pseudocode at this step to ease the implementation phase.
Next, you get some failing tests running. In fact, you get a lot of failing tests running. You’ve asked about the test infrastructure the coding environment supports, and write tests that will cover the edge cases of the problem. You may find some pieces you missed in your planning phase and adjust.
Your implementation is mechanical, you’ve already done all of the thinking and now just need to translate your thoughts into code. Code is concise, variables are well named, and the flow makes sense. No problem.
If something goes wrong you take a sensible approach to debugging. Most code pads don’t have a debugger so adding reasonable print statements is totally fine.
Now that the tests are passing, you take a final minute to review everything you’ve done, and then rest assured in your solution. You may mention ways it could be improved, but if you’ve gotten this far you’ve done fantastically.
Finally, we’ve reached my favourite part, our chance to just talk. You ask questions about the role, culture, company, or anything else. I love answering questions, and the types of questions you ask can help signal what type of co-worker you will be. This is also a great time for you to gather information to help determine if we are a good fit for you.
Interviewing can be nerve-racking, my best advice for practicing would be to find someone else and hold mock inteviews, be both the interviewer and the interviewee, it’s amazing how much you learn by sitting on the other side.
