Jan 11, 2010

How to not suck at a technical interview*

This is partially a rant and partially an honest to goodness attempt to raise the overall bar in our industry. Given that there are about 4 people who read this blog the latter is mostly a pipe dream but still.

I have been involved in the interview process at my last couple companies. In the last few years I have picked up on a few things that I see consistently in interviewees. My hope is to distill these things in this post and try to offer some insight into what we, as interviewers, think of these traits and what we would really like to see from an interviewee.

Ok enough altruism about helping the industry. Bottom line is MOST applicants in the software development industry suck. Yeah yeah yeah, bitch all you want about my exaggerations and oversimplifications. The thing is, it’s true. Interviewing is painful. It is the exception not the rule that I find someone who is even worth more than 5 minutes of my time.

For a while I honestly thought I was a bad interviewer and that my questions were too complicated or convoluted to be understood. I still don’t think I am the best interviewer by any means. I have however changed my approach to asking questions and try to work with the interviewee to get them talking and make them comfortable. But it isn’t my style that is broken it is the overall level of skill in the industry that is broken.

I am not talking about  personality quirks, nervousness, or any other interview related issues. Look, I get it, programmers are a strange bunch. It is expected that you are going to interview odd balls, eccentrics, type A assholes whatever. I can deal with that. One piece of interviewing that I like to think I am ok at is filtering out these types of things and trying to identify the applicants true skill set. Sure, personality is part of an interview and certainly a vital part to team chemistry. I take a person’s personality traits very seriously in determining my opinion of the applicant. But, none of that matters if they don’t have the fundamental skill set needed.

So here are a few things I see repeatedly during interviews.

1. Stretching your skill set: Ok, I get this one. I understand how it works, you need to throw the buzzwords on the resume to get your foot in the door. If you copy and paste a laundry list of the current buzzwords on your resume you better be prepared to answer questions about ANY of the buzzwords on your resume. Don’t tell me you are “an expert in Entity Framework and LinqToSQL” and not expect me to ask you a question about it. If you can’t hold your own in a discussion about a technology don’t put it on your resume. Also, choose the nouns you use to clarify your skill level carefully. If you say you are an “expert” at something then I am going to drill you with deep technical questions. If you are an “expert” you better be able to teach a class on the technology. Don’t be afraid to say you are simply proficient or even that you are a novice. This sets my expectations properly so I can formulate questions. No one is an expert at everything, I don’t expect that. So when I see someone that is an “expert” at every current buzzword I get highly suspicious.

2. Few details about current position: I almost always lead with something like “tell me what you have been working on lately.” One, I am trying to ease the nerves and let the person talk about a subject they should be intimately familiar with. Inevitably I get some high level response with a bunch of superfluous buzz words and very little technical meat. This doesn’t help! If you can’t explain your current position, in detail, I am already out on you. Out of any of the questions I am going to ask this is by far the simplest. Just tell me what you are working on. Talk to me like I am a co-worker and we are chatting in the hallway at work. I am a nerd too, I understand geek speak, I can fill in gaps. Don’t fear losing me or giving me to0 much detail. A solid response to this question frames the entire rest of the interview. It gives me content to build on. It gives me areas to press you on. But, most importantly it give me insight into how you think.

I really can’t stress that last sentence enough. It will be a recurring theme in this post.

3. Unwillingness to say “I don’t know.” Arggggghhh seriously, this one gives me a headache more than anything else. For god’s sake just say “You know, I am not sure I know the answer to that question.” So many people just try to talk themselves out of a corner or give some vague answer hoping I will buy it. Really? Do you really think,  if I ask you a question, that I don’t know the answer? If ask you something I damn well know the answer and I expect you to either give a correct answer or tell me you don’t know. BS’ing the answer or trying to weasel out of the question just pisses me off. Like I said, Arrrgggghhhh. Again, as I said, I have no expectation that people will be experts in everything. I am fine with you admitting you don’t know. Even if the question is related to something on your resume and you don’t know. I would much rather you admit you don’t know then try to fake it. I will often ask questions that I fully expect the person not know the answer to. The reason for this is two fold. One, I want to see if you will admit your lack of understanding and two I want to see how you would go about finding the answer. In almost every programming job you are going to work on problems that you don’t know how to solve, what I want to know is how do you go about finding the answer. If you don’t know the answer to the question tell me you don’t know and add something about how you would go about finding the answer. Would you Google it with Bing. Would you scour blogs, forums, pick a coworkers brain, fire up reflector, read the SDK. Whatever it is explain to me how you would go about it.

4. Not enough use of the whiteboard. This one sounds weird to most I think but it seriously makes a difference. In every single interview I have done the room we are interviewing in has a whiteboard. USE IT. Not just use it but don’t be afraid to jump up and go for it. Every good programming problem requires a white board at some point. We use them daily in our jobs but for some reason we just don’t feel comfortable using them in an interview. I fully expect you to use a white board to solve hard problems in the day to day job so why not use it in the interview. More than anything, watching some one work through a problem on the whiteboard shows me how they think. Seriously, next time a co-worker jumps up to use a whiteboard pay attention to how they organize information on the board. How do they represent different conceptual aspects? How do they move through the flow of information? You can learn a lot things from how someone uses the whiteboard.

5. Thinking too procedurally. If you get nothing else from this rant please understand this. The number one issue I come across with applicants is a fundamental flaw in their problem solving approach. Too often people suffer from tunnel vision when it comes to solving problems. They find a solution to their problem and don’t take the time to understand why the particular solution works or what, conceptually, they have accomplished. I call this “thinking procedurally” because people seem to understand how to get from point A to point B but throw in even the smallest speed bump and they completely fall apart. They understand the “procedure” to get the work done but they fail to see the larger concept in play. This is the number one issue that causes me to end an interview or give a thumbs down on an applicant. This goes back to the previous two points. I don’t expect you to know everything, be willing to say I don’t know, but if the question sounds like something familiar work your way through the answer, out loud. Talk me through your thinking. Explain to me where you are getting your background from and why you feel it might be similar to X. Use the whiteboard to draw it out (remember your high school math teacher “show your work!”). This is eye opening for me. Listening to you work through the problem and explaining how you would approach it shows me if you truly understand the concepts behind the solution or if you have tunnel vision and can’t see the forest for the trees.

Ok I will wrap up my rant now. A few key takeaways if you made it this far.

1. Expect questions about ANYTHING on your resume. If you don’t know it, even if you did long ago but have since forgotten it, take it off your resume.

2. Give me something to go on. Tell me about your recent work, in detail. Tell me why you did things a certain way. Explain the challenges you faced. Explain what worked. Explain what didn’t.

3. Recognize your shortcomings and be honest about them. Explain how you would work to find the answer. Tell me what resources you use to solve these types of problems. What is your workflow? If it sounds sort of like something you are familiar with talk through it. Give me an insight into your thought process.

4. Use all the tools you have at your disposal. Whiteboards are readily available during an interview. Use it. Draw it out, organize your thoughts on the board. Don’t be afraid to scribble, erase, cross out or generally make a mess of the board (you should see mine right now)

5. Think outside the box. Ok that cliché makes me vomit but in all seriousness understand the concepts. If you don’t understand why your solution is actually working, spend time on it. Use reflector, step through the framework source, do whatever it takes for you to understand the fundamentals happening under the hood to solve your problem.

Feel free to give me feedback on this. Am I being too harsh? Am I a dick? (I already know the answer to that one) Do you totally disagree? Praise, flame, bash whatever I am open to it.

*NOTE: This is a personal blog. The opinions expressed here represent my own and not those of my employer.

Labels: ,

22 Comments:

Blogger ether said...

The only redeeming quality of bad candidates is that they are generally bad at hiding it on their resumes as well, avoiding the timesuck of the interview. Seriously, I don't know how many resumes I've discarded because the experience section was thinly veiled "was in the room while others did impressive work".

January 12, 2010 at 9:52 AM  
Blogger Unknown said...

So true! Please do yourself (as the interviewee) and the interviewer a favor and don't waste your or their time by embellishing (and sometimes flat out lying) on your resume. Be real. Be honest. If you're worried you might need to embellish to compete against fellow interviewees who are embellishing themselves, keep in mind that you probably don't want to work for an organization who would hire those type of employees anyway. ;-)

January 13, 2010 at 2:09 PM  
Blogger Brad said...

Great point Troy. Sometimes I feel like I am being a dick to people by cutting them off and ending the interview quickly, but seriously why waste everyone's time?

January 13, 2010 at 3:20 PM  
Anonymous Anonymous said...

What about the people that can talk hours about some framework, but cant tell the difference between list and hashset ?

January 14, 2010 at 12:25 AM  
Blogger Giedrius said...

Many people write, how to interview experienced people, but how to interview junior programmers? You can't expect too much from them, but you need to expect something and usually it's not the technological skills. I've interviewed for a junior programmer position some time ago and now i feel, that i made mistake choosing person that works now.

January 14, 2010 at 1:10 AM  
Blogger Danny Douglass said...

Great post - saw it on the DNK feed. I completely agree about the frustration over inaccurate resumes, especially when I see nearly every technology known to man listed. Some resumes do a good job of faking the funk (so to speak) and, unfortunately, this negatively impacts those that really only list technologies they have a decent amount of experience using.

Personally, I promote a general technologies table where I split up my most prominent technologies in "Advanced, Moderate, and Novice" levels of knowledge. That way I can still list certain experience without appearing (intentionally or unintentionally) as an expert on all digital matters. =]

January 14, 2010 at 8:16 AM  
Anonymous Anonymous said...

Number 2 has become my go-to interview starter. If you can't tell me in depth what problems you are solving in your most current job, I pretty much tune out. You wrote your resume, don't be surprised when I start asking questions about the first job listed.

January 14, 2010 at 8:46 AM  
Blogger James said...

On the flip side, make sure job postings are realistic. Too often HR screen resumes first filtering out those that don't contain all the buzzwords, this means padding a resume with buzz words just to get an interview. It never ceases to amaze me the things job postings ask for.

Examples:
Requiring knowledge of both Ajax and Javascript.
Requiring 10 years of experience in a new language that was released in the last couple years.
A laundry list of languages. Prefer a candidate with strong knowledge of PHP, ASP, HTML, JavaScript, CSS, Ajax, Java, Ruby, C#, VB, etc.

It's impossible to find a candidate who fills that criteria. Don't be surprised if some candidates realize that and apply regardless of their skill level. The whole hiring process seems screwed up, from posting the job, to creating a resume.

January 14, 2010 at 8:51 AM  
Blogger Brad said...

Giedrius,

I definitely understand your situation. I do interview people for junior positions as well and I have found that my number 5 point: "Understand the concepts" is vital to getting a gauge on a junior person.

For juniors it is all about "how do they think" not "what do they know". Do they think conceptually? Can they grasp an idea, even if it is foreign to them? Within a matter of minutes you can usually spot the people who know "how to think" as opposed to the people that know "what to think."

great comment.

January 14, 2010 at 9:10 AM  
Blogger Brad said...

James,

Totally agree. I try my hardest to ensure our job posting are realistic. Sometimes it works better than others. Often times the skillset we are looking for is almost less important then the type of person we are looking for. If someone knows "how" to think about problems and can adhere to my number 5 point (like my previous comment about juniors) then I think they are a good fit.

Most aspects of programming can be taught and people can adapt and learn new things IF they have the right mindset.

January 14, 2010 at 9:13 AM  
Blogger Unknown said...

Good post. In an interview for a previous job I ended up getting, I was expecting the interview to be about Java. When I got into the interview they started drilling me about Visual Basic stuff which I had limited experience with. I thought I did horribly because I could answer maybe half the questions and said "I don't know" to the others.

Turns out I the stuff I did know I answered well, and set myself ahead of competition by not trying to B.S. on things I didn't know.

On the flip side I hate going to job interviews where the interviewer asks all vague, generic, non technical questions that don't really tell the interviewer anything about your ability as a programmer. Usually this is because they are a management type that isn't technical. In this case I think they should bring a programmer with them to ask some technical things, or else they are going to shoot themselves in the foot and fall for all the buzzwords being thrown around.

Similarly if that is the case I feel it's my job as the interviewee to inject some show of technical competency into the interview anyway and hope it sinks in.

January 14, 2010 at 11:27 AM  
Blogger Joshua Ewer said...

I think you can definitely tell a lot about a person's depth when they are up at a whiteboard, but also keep in mind you are probably taking someone out of their comfort zone.

If you're hiring for a developer position (where someone would spend the majority of a time in an IDE banging away) I learn a lot more about them by seeing them in the natural habitat. If someone professes to be an adept developer in XYZ, then I had better be able to *see* them be adept while using XYZ. I've had people with a lot of breadth be able to explain a concept on a board, but when it came to actually building the thing, they clearly were better at talking about it than actually doing it.

So, vet them out with the basic opening questions, talk concepts at the whiteboard, then sit down with them at a workstation and build something. Then you'll be able to know as much about them as you can reasonably expect in an hour or two of talking.

January 14, 2010 at 1:27 PM  
Anonymous Anonymous said...

You are reading my mind. We are going through the exact same problem now in DC at the DOJ.. I keep getting foooled by these reseumes and seriously most mid/sr interviews cannot tell me how to bind data to a data grid!

January 15, 2010 at 9:58 AM  
Blogger Unknown said...

You whine about things that are easily alleviated by not interviewing those types of candidate to begin with. If you see their resume's have too many buzzwords, then simply don't invite them in for an interview. That's what I do.

Too often developers sit on their high horse of arrogance to try and push their egos around to display how much more they know than the candidates. Panel interviews - even worse. Now you've got five developers drilling someone who probably knows their stuff and can do the job just fine, but may perform poorly because some D-bag want's to make the candidate feel inferior to them. Furthermore, who solves a problem easily with another person judging their every word, action and idea.

Your points are somewhat valid, but ridiculously over indulgent with how you think the process ought to be. If you take a step back and look at an even larger problem - it's our profession in general. In the 2000's far to many Joe Shmoe's got into the programming game who should not have been in the programming game.

I've worked in places that have hired persons with a Liberal Arts, History, Psychology and even an Economic's degree; hell even person's with no education; yet give them the title of Software Engineer. Seriously! Software Engineer. These people have absolutely NO ENGINEERING BACKGROUND!

Our profession is losing its credibility as a prestigious profession because it's becoming diluted with individuals with no formal education. I hold a BS, and an MS in Computer Science yet salaries are dwindling because they can hire programmer X with no education for peanuts instead of hiring someone with the theory and knowledge of the field and paying them what they're worth.

It's really getting bad. Our profession has lost it's value and it's decreasing every year. It sucks because Doctors, Nurses, Lawyers, and other professions require the education and background; without it - you CANNOT practice that profession. Software Engineering on the other hand has lost that caliber. Don't get me wrong our industry still pays relatively well even in this economy, but it continues to decline because employers are hiring capable - but highly unqualified personnel.

Yeah I know, there's always an exception to the rule. Bill Gates - Harvard dropout. A broken clock is right twice a day. Off topic I guess - but that's my rant and I'm stickin' to it.

Too many companies have such high expectations for their prospective developers. They want you to know every technology under the sun or at least ask that you do, they want you to be passionate about technology - yeah okay to a point. I really enjoy coding - but I also like doing a lot of other stuff too! I don't want to engulf myself in a 12-14 hour day of solving a coding problem with no overtime. Let me do my time just like everyone else I like going home to see my family, I like spending time with them. Just because I'm not a dork, doesn't mean I'm not a great engineer.

Brad I think you have the right idea and I know where you're going with some of your thoughts, I just don't think you're able to express it in words. Just my .99 cents.

April 9, 2010 at 12:50 AM  
Blogger Unknown said...

Antonia, I think I am more inline with you. When my startup was hibernated recently due to an unexpected loss of an investor, I was on the job market for the first time in YEARS. I have made a career of building large, enterprise-grade systems and have been quite successful at it. But I was shocked by the interview process. It was typically bookish and not reflective of real-world conditions, and often arrogant... especially the panels, who seemed to take glee in humiliating the candidate with their "knowledge". I expressed this to the recruiters, who are finding frustration with this new attitude as well.

The rant in this blog began with an assumption that most people on the job market are crap... and that is a preconceived bias that clearly colors the interview process.

June 26, 2010 at 12:49 PM  
Blogger Unknown said...

btw... i found this blog because of a session on it being held at code camp in San Diego this morning... wasn't able to make it, but intrigued by the session blurb.

June 26, 2010 at 1:47 PM  
Blogger bwc said...

The main question is are technical interviews just as good or better at predicting the interviewee's success at the job than regular penetrating behavioral interviews? I beg to differ if everyone say the former is a better predictor.

In the company I worked in, my VP boss never gave anyone a technical interview because he trusts your resume, and expects you to be able to learn other technicalities on the job and not be dumb. So far in his 30 years in the same company, there was only 1 or 2 out of 50 or so that he had hired and didn't work out after 1 year. That's at least a 95% success rate. He did it by looking at their degree, experience, summing up the person behaviorally and also see if they are a fit personality. That's it!

Over 95% success rate without technical interviews and these are programmers who either majored in Computer Science, Mechanical, Civil, or Aerospace Engineering who coded non-trivial software and solvers which other professional Engineers use to design the cars which you and I drive, airplanes and military jets and also the F1 formula race car which took 1st place after using the software to calculated air flow efficiency on different frame design (not to mention pace maker blood flow and other stuff). Again, all WITHOUT technical interviews. Surprised?

So why are other industries which doesn't have this mission critical software requires stupid technical interviews. Take Microsoft for example. Their software is not mission critical and their software CONTINTUES TO CRASH AND HOG MEMORY! Yet they still have intense technical interviews. What's the point then! Since they had intensely interviewed these candidates, shouldn't the software be flawless and not crash nor hog memory?! This just shows that technical interviews are not a good predictor of success nor guarantee good software engineering practices.

Now MAYBE it's because majority of the people in my company has at LEAST a MS degree in their field?... But go figure again how places like Microsoft which give technical interviews have their software crash and hog memory like cray while places that didn't have them are able to make provide critical software?

August 20, 2010 at 7:36 PM  
Blogger Unknown said...

Brad, You have a flawed interview approach, in fact most techies do. It doesn't matter if someone can admit that "they don't know" your finicky technical question. Even if they have memorized how to code a hashset what good is that. You are actually wasting the candidates time, and causing them to go back to college text books or memorize definitions which takes away from what really matters. What really matters you ask? Can they do the actually day to day work, and can they do it well. Good developers can piece together frameworks and solve problems from an architecture perspective. In fact the less code written the better. What you should be asking is how do they use frameworks like: NHibernate, EF, Validation, Concurency, MVC, MVVM, etc. what features do they utilize and how do they piece them together to create an end to end application. If they can explain to you why and how they do this you have a keeper. Save your time and assume they can use google to figure out the rest.

March 17, 2013 at 8:09 PM  
Blogger Brad Cunningham said...

Unknown, I think you are missing the point. I agree with what you are saying, maybe it wasn't clear from my posting. How to hand code a hashset isn't useful. I want to know HOW you think. All the points I call out above speak to that approach. I want to see if you understand the concepts. Using google to solve a problem doesn't show me that you understand the concepts.

Using frameworks is also a very bad indicator or HOW a developer thinks. Most people use frameworks as a crutch. Throwing a framework in because you can is a bad practice. I want to know WHY you chose that framework and what it is giving you that you wouldn't have otherwise had.

I don't quite understand your response, it seems as if you might have read the first paragraph of my post and then got so upset you needed to post a comment. Maybe reading the whole article would have shown that my thoughts align with yours

March 18, 2013 at 9:16 AM  
Blogger Unknown said...

I'm a developer with 12+ years of experience, usually interview very well, and have never coded a hashset by hand. That is a dumb and irrelevant question. I'd rather see someone having to think through a problem that is relevant.

October 14, 2013 at 10:34 AM  
Blogger Unknown said...

I feel the same I have over 15 years developer experience and yet I struggle to see why when I go to an interview for a tech role the technical boffin interviewing me always tries to assume he’s much better throwing questions at you about things that is fresh on his mind. For example we can’t possibly recite the exact signature for a function call in some language but they have it fresh in their head as they work on that specific function recently. Its just a lack of respect for yourself and a power trip for them and you are left to prove yourself through their questions which is not fair. I’ve blogged about this on the following and how I plan to address this.
https://medium.com/@glamor11/applying-for-a-technical-job-sucks-and-what-you-can-do-about-it-707d1d844fb5

July 23, 2014 at 10:51 PM  
Anonymous Anonymous said...

This is the problem with most technical interviews with engineers. That is, most of them are colossal self important douchebags like the author who think their skills are infallible and their shit smells like roses. The one sentence that sums up this author's shitty attitude is how he says most people aren't even worth 5 minutes of his time. I had to fight tooth and nail to get my job (which is great) but I swear half the battle was having to deal with pieces of shit like you. I've worked with several people with this mindset and none of them know what the fuck teamwork is. They can't listen to ideas without having an aneurysm. You're a dime a fucking dozen. People like you don't last no matter how good you are; nobody likes an asshole and you can't cure stupid.

So what if I'm resentful; these shitty attitudes are literally affecting livelihoods and creating an atmosphere that most certainly negatively affects what you see. How about instead of putting out vibes (which the interviewee most certainly will pick up on) that induce stress, worry, and uncertainty which, you know, affects his/her performance, why can't you be a decent fucking person? You were once that guy too and, in my experience, the people who bark the loudest know their own shit the least.

I'm so fucking sick of engineering departments that are rampant with fucking douchebags like you. Get some fucking humility.

/rant

September 25, 2014 at 12:25 AM  

Post a Comment

Subscribe to Post Comments [Atom]

<< Home