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:
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?”
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.
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.
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.
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?”
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.
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.
Offer multiple test cases. If you have the time.
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.”
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!
Top comments (4)
I love this!
I don't especially enjoy technical interviews - but once I learned to go at them like a conversation and less a public execution, they got much easier.
Now on the other side of the table - I fully agree with this advice. Well put together! I'd love to see something like this on successfully interviewing a technical interview :P Sometimes I still freeze and I'm not even the one being grilled.
Nowadays I'm starting to think technical interviews are only for junior devs and for most other people you really can't get enough benefit for them to bother with spending time on them.
You can't get an accurate idea of a person's skills with a technical test, and you'll end up having to rely on a trial period anyway. Just have a more of an informal chat -type thing to talk about passions, free form explanations of experience, trying to ensure a culture fit. Make sure they seem to fill your rough requirements on what you want from the hire based on their CV before that.
However, for all of the people having to go to interviews of any kind, I also wrote up something a few months ago, hope it helps: steemit.com/life/@lietu/how-to-do-...
This article is designed for people going into technical interviews, not for those who are creating them. And low blow linking to your own article after discounting this one.
Discounting this one? Where exactly did I do that? Also I'm really not sure what you're saying about going vs creating, sure seems to me like both have tips about going to technical interviews.