Dave Fecak

About Dave Fecak

Dave Fecak has been recruiting software engineers for start-ups since 1998 and he has served as the founder and president of the Philadelphia Area Java Users’ Group since 2000. Dave is often cited and published on career topics for technology professionals, and he blogs at JobTipsForGeeks.com.

What If We … Like We Hire Programmers – What Questions Are Appropriate?

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 will should 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.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

4 Responses to "What If We … Like We Hire Programmers – What Questions Are Appropriate?"

  1. 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 the problem at hand or problems that the candidate solved in previous jobs. The idea about providing examples of work is not well thought out. There are many types of carpenters. A rough framer is not able to show you their work. It’s inside some house. Whereas a finish carpenter can show you pictures of what they done. Many developers cannot show their work since it is the property of their employer. If I were hiring I would want a carpenter (developer) who can see the whole house. Who can see issues with the blueprint (design). Who can see how what’s done in this house can be used in the building of the whole subdivision (system). Not just someone who knows all about nail guns.

    • Dave Fecak says:

      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.

  2. spalda2 says:

    :) 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 you nothing about the nail being in the right place at all:)) or from the area of the interviewer domain of expertise. That way one ends up either hireing a person who learnet algos for the interview purpose or a person who happened to be sufficiently familiar with the interviewer’s area of experties (e.g have you ever used rock 5.1 describes it excelently:))

    Given the fact that 90% of problems in computer world are not algos related at all and the area of expertise takes no time to learn for anybody a bit capable, all the above is a futile quest to get “best” engineers.
    More one actually gets programmers who appeal to interviers ego:)

  3. M.L. says:

    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/

Leave a Reply


+ 2 = seven



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close