Programmers often experience a high degree of frustration during the interview process, and one primary source of annoyance is how the programmer perceives the line of questioning or exercises. In a buyer’s market where supply exceeds demand, hiring managers will often be a bit more selective in evaluating candidates, and talent evaluators may request or require more specific skill-sets than they would if the talent pool were deeper. These tactics are short-sighted but deemed necessary in a crunch.
I recently stumbled on two articles with an identical theme. “If Carpenters Were Hired Like Programmers” was written in 2004, and “What If Cars Were Rented Like We Hire Programmers” was posted very recently. The tl;dr of these posts is essentially that programmers being interviewed are asked incredibly esoteric questions or are
grilled about experience with irrelevant topics (wood color for carpenters, car wiring for car renters). The comments sections on Reddit and Hacker News are a mix of agreement, criticism, and various anecdotes about interviews that reflected the articles’ theme. No analogy is perfect.
There are surely companies that are ‘doing it wrong’ and asking questions that will reveal little about a candidate’s potential as an employee, but I’m getting the sense that many candidates are starting to claim that even appropriate lines of questioning and requests are now somehow inappropriate. More importantly, it appears that candidates may not understand or appreciate the true value of certain questions or tasks.
To continue the carpenter analogy, let’s look at the types of questions or tasks that would be both useful and appropriate in evaluating either a carpenter or a programmer (or anyone that builds things) for potential employment.
- Overall experience and training – No one
willshould argue these.
- Experience specifically relevant to the project at hand – This is where we may first see some candidates crying foul, particularly if the relevancy of the experience is judged predominantly by the level of experience with very specific tools. Learning a new programming language is probably not equivalent to learning how to use a different brand of saw, but engineers can sometimes be overconfident about the amount of time required to become productive with a new technology. The relevancy of experience factors into a hiring decision most when project delivery is valued over long-term employee development.
- Answer some questions about your craft – When hiring managers ask questions, candidates should keep in mind that there can be a few reasons why a question is asked. Obviously, one objective may be to truly find out if you know the answer. However, sometimes the interviewer asks a difficult question simply to see how you may react to pressure. Another possibility is that the interviewer wants to reveal if you are the type of person who may confidently give a wrong answer to try and fool the interviewer, if you are more likely to admit what you do not know, and to evaluate your resourcefulness by how you would research a problem with an unknown answer. A genuinely, laugh-out-loud stupid question may be asked to see how well you may deal with frustration with a co-worker or an unruly customer. Lastly, the interviewer may simply want to see your method of approaching a tough question and breaking it down. Candidates that are quick to complain about being asked seemingly minute or irrelevant details often overlook the true purpose behind these exercises.
- Design something – I’m always amazed when candidates call me in a state of shock after being asked to do a whiteboard exercise in an interview, as if these types of requests were either unfair, insulting, or a ‘gotcha’ technique. Anyone who builds things should be somewhat comfortable (or at least willing) to either visually depict a past design or attempt to design a quick solution to a problem on the spot.
- Show us how you work alone – Assigning a short task for someone to complete either in an interview setting or at home before/after an interview is absolutely an appropriate request, which candidates can choose to accept or deny. It is both only an opportunity to demonstrate skills and to further express your interest in the position by being willing to invest time. Providing a bit more than the minimum requested solution is a valuable method to differentiate yourself from other candidates.
- Let’s see how you work with a team – As candidates are often hired to build things collaboratively, a short pairing exercise or a group problem-solving activity could be the best way to efficiently evaluate how well one plays with others.
- Show us some samples – Professionals who build things have the unique interviewing advantage of actually showing something physical that they have built. A carpenter bringing a piece of furniture to an interview should be no different than an engineer offering a past code sample. Companies are increasingly using past code as an evaluation tool.
- References – At some point in the process of evaluating talent, asking for references is a given. Being unwilling or unable to provide references can make someone unemployable, even if all other tasks are met.
If you go back and reread the articles about the carpenter and rental car interviews, you may have a new perspective on the reasons some questions may be asked. Think back on some interviews that you have had, and consider whether it’s possible that the interviewer had ulterior motives. It’s not always about simply knowing an answer.
Reference: What If We … Like We Hire Programmers – What Questions Are Appropriate? from our JCG partner Dave Fecak at the Job Tips For Geeks blog.
An interview gives both parties an opportunity to explore each other. In all too many cases, the interviewer does all the exploring. An interviewer that focuses too much on the detail misses the fact that we developers are problem solvers. Keeping to the carpentry example, an interviewer that asks many questions about nail guns will determine if the candidate knows all about nail guns. But will learn nothing about their ability to frame a house. It’s a classic forest and trees problem. It’s easy to ask details on classes in Java or some framework. It’s more difficult to ask about… Read more »
Good points. Developers that are unable to show their work (internal apps, proprietary code, etc.) need to be aware of this and make an effort to contribute to open source projects or write some code to solve a potential interview exercise.
:) to me this is all silly..actually to hire a person based on interview is close to a loterry draw. To me the only possible way to get someone good who the interviewer hasn’t known before is to be able to ask questions from the area the candidate worked in. Which is what is not usually done. Way too often questions being asked are either algorithmic nature (basically coming down to searches, hash tables, algo complexity etc, which in the world of carpenters would be like knowing how to hammer a nail in a single blow..nice optimisation sure…but it tells… Read more »
This is also interesting: ask a programmer in an interview what the framework is doing “under the hood”. See http://yakovfain.com/2012/10/11/the-degradation-of-java-developers/