10 Things to Start Doing in Technical Interviews
Published: 2018-10-09 23:54:08

---
title: 10 Things to Start Doing in Technical Interviews
published: true
description: 
tags: 
---
There are many pieces out there about advice for technical interviews, so I will keep this one short and simple. I started interviewing candidates for software engineering a couple years ago and I’ve found that are several things I wish more candidates did in a coding style technical interview. Here are ten things that you should start doing (if you do not already) in technical interviews: 

1. Rephrase the problem description in one sentence (or less) to make sure you understand. For example, “So you want me to flip the bit, switch it and reverse it?” 

2. If it has not been provided, make sure you have an example input and an example output. Why? I’ve had candidates assume that they should return a true or false boolean instead of an index in my question, which affects how they write the solution. Clarifying this detail sets you up for success in your answer. 

3. Clarify edge cases at the beginning. I might say it's not worth it to code that part up yet, but it's good to mention them. 

4. Accept comments/questions, do not brush them off. Often candidates react poorly to suggestions or questions. Possibly because they don’t think they should need them, or see a suggestion as a sign that they aren’t doing something right. If you accept my suggestion and give it consideration, I probably won’t even remember that I had to offer it. If you react weirdly or ignore it, I will remember that and it will hurt your chances. 

5. Ask before you start coding. You don’t want to waste time with a less than optimal approach if I won’t care. It’s good to say, “Shall I code this up?” because often this gives me a chance to offer a “Can you think of a more optimal solution?” 

6. Always mention the brute force solution and other alternatives, even if they seem SUPER basic to you. It shows that you’ve thought about it and is a good way to frame discussion of alternatives. Even if there’s an obvious choice, mentioning that you evaluated other options shows a level of technical knowledge that goes beyond merely solving the problem. 

7. Ask questions you really want the answers to. Sometimes I get questions that I think are being asked just to make the candidate look better. Genuine interest definitely looks good in an interview, but skip the “What is your biggest challenge at X Company?” question if you don’t actually care about my answer. Also, questions about snacks might be better for an onsite.

8. Offer multiple test cases. If you have the time. 

9. Try and use names based on what something is in context of the problem, not its type. Use names like “nums,” for example, to refer to an array of numbers, over a name like “arr.”  

10. Be respectful of your interviewer’s time. If you are late to the interview and I ask to reschedule, take that option. Expecting your interviewer to let the time go long because you were late or want 5 more minutes reflects poorly on you--often I only have the room booked for an hour and a full schedule of things to do after we are done. 

Happy interviewing!

![cat typing](https://thepracticaldev.s3.amazonaws.com/i/w0n5a3wxj786dkbnn73e.gif)