Don’t make these three mistakes in your technical interview
I’ve been running a few tech interviews for the consulting company that I get work from and I’m realizing, most people aren’t very good at it.
But that’s understandable. It’s not like we do it very often and it’s hard to get practice in on the interviewee side (interviewers do this all the time). Here are a couple of mistakes I’ve seen recently:
Being non-chatty
Yes, I see this as a mistake. When an interviewer asks you a question, they’re looking for a thoughtful answer, but also an opinion, some kind of sign that you actually care about the topic at hand. When you give an answer with no room for discussion (some questions will require that, but not all) then it’s hard for the interviewer to see you as inquisitive and interested in the work that you’re being interviewed on.
Trying to answer every question
Just because I ask you a question doesn’t mean that I expect you to be able to answer it. Part of my job as an interviewer is to see where the limits of your knowledge lie. “I don’t know” is a perfectly good answer. “I’ve heard of that but never used it” is also okay. “I don’t know much about that. Can you tell me about it?” is the best answer in this situation, especially if you can then link it back to something you do know about. Remember, asking questions and getting the interviewer talking is good for you.
Just because someone asks you a question doesn’t mean they require you to know the answer. Be honest instead of trying to make something up and they’ll like you better for it.
Not assuming that every question has a purpose
I had two interviews on the same day recently and decided to give the same programming exercise to both interviewees. It involved writing a class that had three properties in whatever language the interviewee was most comfortable in and then adding a method that contained a simple algorithm that printed out some simple data.
The first interviewee chose Python as his language and immediately ran into problems writing the class. He couldn’t quite remember the syntax and stumbled a bit in getting it to compile. Then when adding the method, he couldn’t get it to work right away. He got frustrated after awhile and I had to jump in and fix it to get us moving along.
I then asked him to add a second method almost identical to the first but with one small change.
Now, how would you solve this? I hope your first thought would be, “Why is the interviewer asking me to do this?” If you think of it that way, it should be obvious that I’m seeing if you’ll follow good programming practices. If you copy and paste, you lose because now you’ll have a bunch of duplicated code and that’s never good. I expect you to refactor your code and change the existing method to either take a new parameter that tells it which thing to print or some other inventive way to solve the problem without duplicating a lot of code.
The first interviewee just copied and pasted after thinking about refactoring. He knew what I wanted and just took the easy route anyway! The second interviewee (who knew his chosen language way better than the first) talked about both options and then asked me if I had time for him to refactor. I told him, “If the interviewer is asking a question, it’s probably for a reason.” So he refactored.
It looks like I’m going to be running quite a few interviews over the next couple of weeks and hopefully, there are other little tips I can extract from my experience. Leave a comment and tell me what you think your biggest mistake was in a recent interview.