Ruminations of idle rants and ramblings of a code monkey

Passing the Technical Interview: Some Tips

Idle Babbling

I’ve been involved in doing technical interviews for … oh … I guess about the past 15 or so years. In my current role, I do quite a few and, while I don’t have the final hiring decision, I can completely nix the entire process for a candidate. In this post I’m going to share some tips to pass a technical interview because of how many technical interviews I do that don’t turn out well … for the interviewee. When I’ve talked with other senior level people in the industry, I’ve also discovered that this is, sadly, more the rule than the exception. While it does lead me to wonder how some of these people are actually getting jobs … it also scares me because they are actually getting jobs writing code. Or … well … maybe it’s that I hold my team to a higher standard than much of the rest of the industry.

Do Your Research

You are being interviewed to join a team of technologists … so it is in your best interest to do some research on the team and the position that you are being interviewed for! If you are working with a recruiter, ask the recruiter for details and ask the recruiter if you can get an email from the interviewer or the team that provides some more information. When you get that information, research it! Look up, at least at a high level, things that you don’t know or aren’t familiar with. The vast majority of interviews that I have for my team don’t show any pre-interview initiative, even when they are told that they would be interviewing for a StreamInsight-focused position. I have actually had candidates tell me that they were being interviewed for a position that involves Microsoft StreamInsight but they hadn’t heard of it before. OK … fair enough, I can accept that … but I’ll follow up with “Well, did you look it up?” C’mon folks … search engines work very well for these kinds of tasks. I do not expect someone to be an expert in StreamInsight but you will win major brownie-points for having taken 30 minutes of your time to do a quick overview. Sadly, far too often I am told that they didn’t look into the technology before the interview. (OK … so I guess you don’t want the job, do you?) They get more brownie points for mentioning my blog and discussing something that I’ve actually posted. Read – know your interviewer!

Beyond the technology, do your research on the company itself! This is pretty basic and doesn’t just apply to technical interviews but to all kinds of interviews. Show some interest in what the company does and their history. Provide some indication that you actually want the job and not that you are just there to collect your next paycheck. Yes, we are all at our jobs to collect paychecks but I want people on my team that actually want to be there for more than the money. My philosophy – for a long time – as been to follow your heart, your passion, your bliss … the money will follow. It has worked very well for me and, more importantly, I’ve been happy at my various jobs. It may sound corny but that doesn’t make it any less true – money cannot buy happiness.

Ask Questions

I love it when an interviewee asks questions, especially considering the topic above. There are few things better than a candidate that’s done a little research and has questions … it shows that they have a passion for the technology and that is someone that I’m actually interested in hiring. I will start the interview with a brief description of the project, the team, the technology and the position … which is a perfect opening for additional questions. At the end of the interview, I will also make a point to ask the candidate directly if they have any questions. And do not, under any circumstance, ask “How did I do on the interview?” Yes, I’ve actually had people ask that but then, of course, they already know that they didn’t do very well on the interview so it was pointless to ask. Regardless, it’s just poor form. It shows that you weren’t prepared and that you know that you didn’t do well but are, perhaps, hoping for some mercy. Sorry … if I recommend someone for hire to my team, that person reflects directly on me. Don’t take it personally if I’m not merciful. I want to hire the very best people that I can so that they can make me look good to my boss. And … guess what … every interviewer is going to feel the same way.

Say “I don’t know”

There’s nothing to be scared of here. It happens; it’s reality. No one in this industry can possibly know everything, not even your interviewer. And your tech interviewer is going to know this. So don’t be afraid to say that you don’t know the answer to a question but also be prepared to follow up with two things: 1) what you infer from what you already know and 2) how you would figure the answer out. I’ll tell you right now … how you deal with the follow up is FAR more important than what you don’t know (assuming that it’s not something so basic that it’s trivial … you better know how to declare a variable in C#). Rather than saying “I don’t know”, I often hear candidates stutter, stammer, stop and otherwise embarrass themselves because they won’t actually admit that they don’t know something. Believe me, saying you don’t know is not only easier and less embarrassing, but opens up new avenues for you to impress me. I’ll also occasionally get a candidate that likes to spew a load of BS rather than admitting that they don’t know … and this is FAR, FAR, FAR worse. I had a button that a friend gave me in college that said “If you can’t dazzle them with brilliance, baffle them with bullshit.” That, however, doesn’t work in a technical interview so get it out of your head. The developer that thinks that they know everything and that insists that they know everything when they don’t is a very dangerous developer indeed. I’ve heard stories of interviews where the interviewers simply made stuff up to mess with someone … and the interviewee happily played right along by claiming to know – and have worked with – this made-up technology. One thing that I do try to do with an interview is to push the candidate to the edge of their knowledge to a) see how much they really know and b) get them to admit that they don’t know. Yes, that’s right … I’m looking for an “I don’t know”. And from all of the discussions that I’ve had with other senior-level technical interviewers, they are also.

Be Honest on your Resume

Do not, under any circumstance, put buzz words on your resume just because you think it’ll impress someone. There is a very good chance that you will get questions about things on your resume and you need to be able to answer those questions. The most common example that I’ve seen of this lately is “Design Patterns”. I can tell you right now that if I see that on your resume, I’m going to ask. In fact, if I don’t see it, I’ll still ask but you won’t lose points if you can’t answer. But just about everyone puts that on their resume these days and very few can actually name some common patterns. Even when given some common patterns, some have difficulty with explaining those patterns. I asked one interviewee who claimed to be “deeply familiar with design patterns” and a Senior Architect, “What patterns have you used?” He said that he had used some pattern or another (I forget which) in a recent project. OK … so, why did you choose that pattern? What problems did it solve? Were there any potential downsides? His response … “I don’t know. The architect on the project chose that and I just implemented it.” Wrong answer … it would have been far better if you had excluded design patterns from your resume rather than lie. Now, I use design patterns as an example simply because it’s just so common; it’s probably the most frequent “stretching of the truth” that I regularly see. But it’s not the only one. Keep in mind that there is a reason that you’ve been asked to the technical interview and it probably has something to do with the skills that you list on your resume. Assume, when writing your resume, that you will be interviewed by an expert in every technology that you mention. If you don’t have those skills … if you can’t answer questions about those things intelligently … it is better to just leave them off.

Avoid the “And one time, at band camp” Answers

A big part of a technical interview is what you know and how you think. Yes, we will cover previous projects but I’m more interested in the how’s and why’s … how did you solve particular challenges? Why did you choose technology A over technology B? What was the good, the bad and the ugly. Look … I’ve been in the software development business for a long time. I know that there is no such thing as a perfect project or technology. And I’ve certainly had my share of projects that were “challenged” for one reason or another. I don’t expect every project that you’ve done to be perfect but I do look for what you learned from it and how you solved problems. Yet, too often, I get what we (my team) call the “one time at band camp” response … “I was on project XYZ and we used technology ABC”. Thank you, I can read that on your resume. Can we drill down a little bit please? And often I don’t get anymore than “the client chose that” … OK, that’s fine, I get that … what was your opinion of it? What was the good and the bad? What challenges did it solve and cause? A great deal of software development is analysis. What are the requirements? How should I attack them? What technologies do I have available? What questions do I need to ask to more deeply understand the problem? And I’m looking for analytical skills and the ability to learn and grow from that analysis. I’m not looking for a rehashing of something that I can already read on your resume. If that’s all that you are capable of doing then you aren’t going to be someone that I’m looking for … unless it’s a junior role where I know that you’ll be under a more senior and seasoned technologist that can do that and can make sure that you do what you need to do. I can tell you, in no uncertain terms, that “one time at band camp” interviews don’t lead to a job.

Have a Passion for Technology

Let’s face it … tech is a fast-paced, rapidly changing and dynamic industry and it’s not slowing down. If anything, the pace of change is speeding up. So … you have to love it. You need to have a fire for it. What you know and do today will not be the same that you know and do tomorrow … that’s just reality. If you don’t love what you’re doing, you’ll too quickly get left behind and become an albatross on the necks of your fellow teammates as they will have to pick up the slack for your lack of passion. I, for one, like to challenge the members of my team to push into new areas, get outside of their comfort zone and take on new challenges. And you have to love it to thrive in that kind of environment. Also, a real passion for technology drives you to look for new and better ways to solve problems … not just repeating the same things that you’ve been doing over and over and over again for the past x number of years. It drives innovation. I look for candidates with that kind of drive … they’ll also be the ones that take it on themselves to challenge my own assumptions and/or ways of doing things. I welcome that … I want the people on my team to do that; I want them to challenge me. It helps me, personally, grow and learn more. Beyond all of that, I don’t want to hire someone that’s going to come to work and simply go through the motions to do their job. It’s bad for the entire team’s morale when even one team member is like that. From a team lead perspective, I also know that these people will be far less productive and, typically, have lower quality code because they are simply doing it for a paycheck, not because they enjoy it. So make sure that you show that you love technology. Talk about the blogs that you read, cool stuff that you’ve done, whatever. Show some fire, show some spark. That passion can take you a long, long way. No passion == no job.

That’s what I’ve got right now. I may be adding to this (as a series) later on with other thoughts and comments … I have many. And no, I don’t ask “Why are manholes round?” Everyone knows the answer to that one already.