I’ve been on both sides of the technical interview process for over two decades now - most recently just a couple of weeks ago - and I have a few thoughts I wanted to share.
Tips for the interviewEE
Talk Talk a lot and do not stop. The more you talk, the more likely it is you’re talking about something you’re very familiar with and the less time the interviewER has to quiz you about things you know nothing about.
But do not ramble. Rambling looks bad. Rambling means you’re not talking about the topics you’re familiar with and is usually interrupted with requests for clarification from the interiviewER (“— What the heck are you talking about, man?”)
Practice Of course, if you want to be able to talk for hours about your favorite topics, you’ll need to practice a lot. Have a friendly banter with colleagues, go to conferences and read a lot.
If you’re going to be writing code on the whiteboard, you should practice that too. It’s different from coding on a computer, so a little bit of practice will help.
Be honest If your interviewER is good, she won’t let you talk about your favorite topics unchecked. Sooner or later you’ll be asked a question you don’t know the answer to. Be honest and say so. Trust me, if your interviewER is asking you a question, she most probably knows the subject pretty well and will be able to tell whether you’re winging it. Just say — “I don’t know the answer to this question, but…”
Think “…but let me think for a second and see if I can come up with an answer.”
There is a tendency to treat a technical interview as a quiz: “have you ever used blah?”, “what’s the system call for blah?” Sure, some companies and interviewERs do that, but you probably don’t want to work for them anyway. And the ability to come up with an answer to a novel problem is far more valuable than having a previous experience with a particular technology (that is probably going to be obsolete in a couple of years anyway).
Don’t be a fool, though, and learn the basics well. What’s the Big-O of the quick-sort? Worst case? Can you sort a sequence in O(n) time?
Tips for the interviewER
Be nice The purpose of the technical interview is not to show your superiority, it’s to assess the skills of the person you’re interviewing. If the job will require writing code under the gun, then by all means, stress and intimidate the interviewEE. Otherwise, make every effort to create a relaxing and pleasant atmosphere. Stress narrows your vision, creativity requires a playful and relaxed atmosphere. Being an interviewEE is a stressful job as it is, don’t make it worse.
Be prepared So often companies have no clear understanding of the requirements for the position they are trying to fill. Everybody suffers as a result. The interviewERs are confused about what to ask and how to asses the skills (“He has no idea what
if [[ $? -eq 0 ]] means, we can’t hire him for the Junior Visual Basic position!”). The interviewEEs get random, disjointed and sometimes repeating questions.
Talk to other interviewERs ahead of time, make sure you have a common strategy for the interview.
Interviewing people is a skill. Just because you’re an awesome engineer yourself, does not mean you know how to assess other engineers’ abilities. Read a book, take a class. Don’t try to wing it - it’s disrespectful to everybody involved and leads to poor results.
The best (both challenging and rewarding) technical interview I’ve ever had was at Amazon. It was a full-day interview - I’ve seen at least six people that day. And each next interviewER was building on the subjects covered by the previous interviewERs. There was some designing, some coding, and a lot of talking about it all.
Listen Do not interrupt unless to ask for clarifications. Give interviewEE a chance to explain themselves. If it sounds like the interviewEE is going in the wrong direction or you’re not sure you understand the answer (or even think the answer is incorrect) - ask a clarifying question, do not assume the worst automatically. Ask questions with the intention of understanding, not sinking the interviewEE.
Keep an open mind Would you rather have a team of engineers with diverse experience, combined covering a vast amount of knowledge? Or would you prefer to work with a bunch of clones of yourself? Do not structure your interview as a quiz. Allow an interviewEE to show you what they’ve got. They might not have an answer to the exact question you’re asking, but maybe they have a better solution. Talk about things, see how your interviewEE thinks. Hire a team member, not an automaton capable of performing a predefined limited number of tasks.
August 21, 2012
Feel free to comment on the post but keep it clean and on topic.comments powered by Disqus
Climber of rocks, maker of things, husband of wife and father of kids. Manage DevOps @SurveyMonkey. Views are my own, but damn they are good views!