Cover photo by Mark Rabe
When I was asked to present to high school developers on the subject of technical interviews I did what any professional developer does to prepare, I turned to the internet. It's been about a year since I've done a technical interview and as I researched I revisited the idea that there was more to the technical interview than just answering a problem on a whiteboard.
What is the purpose of a technical interview?
Horror stories of developers having to answer brain teasers are still passed around and can definitely be spooky. Thankfully, it seems like the community is moving forward as interviewers are getting better at wanting to see your skillset and work-related abilities. These interviews are mainly an opportunity for you to show your thought process when faced with a new, sometimes difficult problem. I discovered that one particular soft skill was referenced over and over as being the most important part of the technical interview.
What is the most important part of the Technical Interview?
The best thing you can do as an interviewee is to communicate with your interviewer. They're there to get to know you and your problem solving skills. The more pertinent information you give, the more insight they have about you as a professional developer.
1. Talk out your reasoning & problem solving process
Ask Questions:
Be sure to ask any questions you have about the problem before you even start coding. Write down important information like the input/output expected, validation of the inputs, or if spacial/time complexity is important to the solution.
Explain what you’re thinking:
It’s easy to go silent when confronted with a difficult problem and while this is natural, it is not very helpful for the interviewer. You speaking about your thoughts helps them understand your skills and critical thinking.
Describe what is your process:
How do you break down the different components? How do you arrive at a solution? Writing in pseudocode after you've written your notes will help with breaking the problem into smaller pieces and can be converted to actual code once you're comfortable with your logic.
Example of Explaining Your Reasoning
“I’m going to store this data in an array.”
Cool, you've heard of an array, but expand on why you're using it.
“I’m going to store this data in an array because I already know that the input given is sorted and lookup would be efficient with this data structure.”
Great! This answer shows what data structure you're planning on using and why you believe it's the best one to use.
2. Solve it Twice
I know, you may have a hard time solving it just once but hear me out.
Few problems only have one solution and focusing on one way to solve a problem misses a major opportunity to prove your know-how. Most likely the first idea that comes to mind will be a brute force answer. Open up the conversation by mentioning your initial thoughts, an idea about a more efficient answer, and your plan on returning to the problem for refactoring later. This is extremely valuable as it shows that you recognize the solution can be improved upon.
Let's say you're able to answer the problem with a brute force method. Once complete, test it with edge cases that come to mind. Ask your interviewer if there's time for you to refactor and if not then explain how you would if you had more time.
If you can't think about a secondary answer then that's ok. Continue practicing answering algorithmic questions and study when you can. Interviewing is a skill on its own and practicing will only make it easier.
3. Answering with “I don’t know”
Try not to answer the question with "I don't know". You're a human, it's ok to not know everything. The interviewer (hopefully) doesn't expect you to be perfect, what they do want is someone who doesn't quit on the problem.
A better answer would be “I don’t know how to do that, but here’s how I would go about figuring it out”. This gives you the chance to explain your learning process and that is valuable information for the interviewer to know!
4. Breaking down the interview into steps
No matter the company, from brand new startup to Fortune 500, these steps are integral to communicating your knowledge in a technical interview. Here's a simple process on how to go about answering the question.
If you can, practice whiteboarding with a friend! This can be beneficial for you improving your communication skills and practice the above steps while coding in a safe space. I believe that our greatest resource is our peers and there's no better way than to learn from each other.
Conclusion
Thank you so much for being on this platform. dev.to is really my favorite and I'm so happy that I get to contribute. I couldn't have written this post without the plethora of resources I found online.
Resources
There is so much material available that I've made a list of my favorites. I've included different mediums such as articles, videos, and practice questions. I hope that one of these will match your best learning style.
Practice Questions
The Ultimate Guide to Acing Your Technical Interview
The Best Whiteboard Interview Advice I Ever Received
Decoding the Front-end Interview Process
5 Smart Moves to Make in a Technical Interview (That have nothing to do with coding)
Leetcode
Hackerrank Interview Preparation Kit
How To: Work at Google - Example Coding/Engineering Interview
CSDojo - Coding Interview Questions & Answers Playlist
6 Dynamic Programming problems and solutions for your next coding interview
The Interview Study Guide For Software Engineers
My Google Technical Interview Cheat Sheet
11 Mistakes to Avoid On A Technical Interview
Cracking the Coding Interview Playlist
Top comments (11)
I have mixed feelings about this article. On one hand, I enjoyed reading it and I'm glad you share your thoughts with us. On the other hand, I'm freaking out at the idea of going again to a job interview.
I've had this job for so long, I'm used to work alone from my room, without talking to people and solving specific kind of problems. I mostly google and copy / paste stuff. (yes, I am still the kind of guy that checks mdn whenever has to use something like
array.reduce().).There wasn't a reason for me to learn a lot of stuff that are necessary in an interview and I keep asking myself if I'm actually a software engineer or just an imposter...
The company I worked for recently lost a dev to Amazon. I was chatting to him a bit before he left, and I asked him what prompted him to apply, and he said his goal going in was just to find out what the interview process was like - he had no intentions of working there. That all just followed after.
It just had me thinking - going into interviews with the goal of learning has always calmed me down immensely. Maybe that would help you as well?
Also, I'd have to check MDN for
reduce()for the details as well. I think, so long as you know what the function does, that's just fine!I've actually heard similar advice from companies when prepping for an interview. They suggested that I interview at other places so that I could learn and get some experience doing it! It was a surprise to hear that but it really made sense.
At some point I think most of us have felt like an imposter and that's ok. As long as you choose to continue learning you'll become a better developer.
Also, I look up stuff all the time! We're people and there's no way of us remembering what each method does all the time :)
Maybe I'll set up starting with January and go to some random interviews, just to learn and be rejected. (I guess that's a lesson too)
I figure: A) there's entirely too much shit to know cold/off the top of my head; B) I switch far too frequently between different types of tasks, languages, etc. to have much more than "most recently used" techniques/languages at the top of my head. If all a place is looking for is solving an immediate problem, I'm probably the wrong person for the job. If they're looking for someone who's going to be capable of long-term problem-solving, they're not going to be hung up on me not immediately-knowing something but will, instead, be happy to see that I know how to use what I know to extend my knowledge to the particulars of a given situation.
But, yeah, I've never considered myself a specific subject "expert" ...even when the people that have advertised themselves as experts have demonstrably-less knowledge in their domain than I (down side of being aware of how much you don't know).
That's what I'd like to believe about myself too. I've always been the last one in the company, and therefore I had to learn whatever was needed. Like this, I got to work with 6 different languages and yet I didn't get the chance to get good at any of them...
I guess there's an upside to this too, I just didn't see it yet.
Hi Kiara, I really love this article thank you! I'll share it for sure, it's exactly my thoughts on this topic.
Have a nice day :)
Thanks so much Maxime! I'm glad you loved the article. Hope you have an awesome day :)
Some great tips here!
Thanks Andrew!
Whew! It's encouraging to read this, since this is exactly how I approach technical interviews as an interviewee.
Meanwhile, as an interviewer, I can definitely confirm that this is right on.