What to do in a technical interview
Technical interviews are hard. Especially if you're applying to the top 5% of Engineering companies out there. Part of our job as recruiters is to prepare people adequately for all the stages of the interview process. I often get asked the same question from Engineers "what exactly is the {Companies} expectation of me?".
Whilst I can't tell you how Garbage Collection works, or the differences between TCP and UDP or how to work out the space/time complexity of an algorithm - I can help you with some transferable skills which will help you put your best foot forward for that elusive role.
1. Clarify the problem
Before you begin giving any kind of answers, make sure you've clarified the problem. Assumptions are a double edged sword. They can be a great way to dissect a problem and make sense of it in your head (if the question is particularly ambiguous). On the other hand, an incorrect assumption can be a very bad thing. Make sure that if you need to assume something, it is a reasonable assumption to make.
If you don't quite understand the interviewers question or the problem at hand - define it out loud as YOU see it. Ask them if your definition is correct - and if not, they can guide you to the right question (and drop valuable hints along the way on what to focus on).
Always let your interviewer know what you're thinking as they will be just as interested in your thinking as your final solution. If you're stuck and they know what you're doing/thinking, they will be able to give you hints
2. Consider trade-offs
With around 60 minutes per interview, time is a constraint. You won't be able to design the most optimised, scalable, reliable and well-tested solution. Something has to give. Be sure to communicate the trade-offs you're making with regards to your tech choices and your approach of solving the problem. If you're pressed for time and have to take shortcuts - let the interviewer know and explain what you would have done differently had you more time.
When it comes to Systems Design and Architecture, there are lot's of moving parts. If you pick X over Y, explain why you did that. What's the gain? What do you lose? Why did you pick X in this context? In what context would X not be the right thing to use? Your answer should rarely be "I chose X because I've used it before and it kind of does the same thing".
If you want to flex your TDD approach - ask the interviewer if they'd like to see a Unit Test. If they do, you can spend time on it - if they don't, explain how you would have done it in simple terms and move onto the solution. Most importantly, understand the context of why testing is important and under what circumstances. If you're interviewing for a Seed/Series A stage start-up who are in MVP mode, TDD will slow you down and likely won't be needed in the immediate future. If you're working on large scale, mission critical systems - you probable should demonstrate the approach.
3. Communicate clearly
This is perhaps one of the most important points. Practice mindful communication. Be transparent, clear and honest. Remove as much ambiguity as you can. The interviewer can't read your mind. If you've been silent for more than 5 minutes whilst coding a solution or designing your system - you're probably getting rejected.
Be self-critical and honest. If you don't know something, admit it and ask for guidance so you can leverage first principal thinking to attack the problem. If you know you could have done certain things better, show your self awareness. If you're getting hints, follow them rather than blindly going deeper into your rabbit hole. All of this is a display of communication. Be collaborative and involved.
4. Do your research
Doing the basics can go a long way. Check out the company website. Read the Job Description. Check out their tech stack and look up who's interviewing you on LinkedIn. Read blogs written by the company and especially the engineers (if they have them). Familiarise yourself with the types of problems the company is solving. Why is it important in their industry? What are the domain challenges?
Ask intelligent questions during your interview. Coming prepared with a few of these won't go a miss. "What are you solving?", "What does your team do?", "What's the impact of your team on the company?", "What's the impact of the company on the world?", "What are you most proud of?", "What engineering principles guide you at {Company}?"
This information, whether you know it or not, subconsciously affects your answers. It shows the interviewer that you're genuinely interested in the company, the role and your potential future colleagues.
5. be on time
Last but not least - be on time. If you're running late, let someone know with at least 30m notice. If you cannot make it - communicate this with your recruiter or the company. First impressions make a huge difference. In a post-pandemic world, a lot of interviews are still conducted remotely. It makes it that much more obvious that you're late when an interviewer is hanging out in an empty Zoom / Meet / Teams call all by themselves for 5/10 minutes.
Make sure you check your audio and video is working clearly and you have no wifi issues. The time to do this is before the interview, not once you join. If a company is going through hyper-growth, they're likely interviewing 4-5 candidates per day and their schedule is often back to back. You only have 60m to show them what you can do, don't make it shorter because you didn't come prepared.
