To be honest, I have not been in a position to hire anyone for at least a couple years. Nonetheless, I have always been frustrated with how ineffective the resume, screen, interview, aptitude test, etc. process really is. In light of recent posts about hack challenges for job applicants, un-resumes, and other general rants, I thought I would post my two cents (apologies for not digging up example links, there are several available from Hacker News, for the truly interested). In particular, I was motivated by two posts. Today’s coding interview game, regarding the newfound difficulties that tech interviews sometimes pose, and hinting at the worth (or lack thereof) of these coding challenges. And this self-professed rant, which is (as the author admits) nothing new, but he did relay it eloquently.
So I was inspired by the notion that if a developer (any tech-related position, really - and most positions are tech-related these days) is not constantly striving to better themselves, they are not worth hiring. I’ll skip dealing with the bullshit resumes and phone screenings, I have not (yet) come up with anything worthwhile to better those aspects of the process. But how do you determine if someone is yearning for self development and un-ending advancement in an interview, while simultaneously addressing the issue of worthless coding interviews?
The linked rant above notes that only two things matter, “can you think? and what conscious action do you take to make yourself a better coder?” Let us see if you agree with my prediction for the interview (I am not suggesting that the post indicated this was an appropriate way to get these answers - it’s just the most direct.):
“So, Mr. Applicant, can you think?”
“Yes, Sir, I can think.”
[Pause - wondering if Mr. Applicant will offer a more open-ended answer to the not-so-open-ended question.]
“Well then, Mr. Applicant, what conscious action do you take to make yourself a better coder?”
“I read a lot of tech blogs, and stay very current with changing technologies. Many of my side projects use not only staple languages with which I am quite familiar, but also languages and technologies that are new and challenging for me to implement.”
Ok. Check, and check. If only it were that easy.
Now that I highlighted a not so promising technique for gathering this information, I will propose the following alternative. I believe this could be successful at genuinely pruning applicants, and doing so in much the same way that “hack our site to apply” type challenges do - a technique which I will admit to liking. My proposition however, allows the sleeper candidate to get through. The sleeper candidate is the applicant who makes a killing once they get started, but can’t get their foot in the door because they don’t know the technology that you use (or similar scenario). I like this alternative because I know that I have grown exponentially when I managed to acquire positions for which I was nowhere near qualified. As such, I think it is important to allow some of these candidates through.
The interview is 90 minutes, but only you know that. 15 minutes of opening BS, this is make or break in my mind. A good interviewer knows a lot in the first 2 minutes of the interview. That said, the meat of my proposed interview technique starts in the second 15 minutes, during which you offer the candidate a list - something like:
Agile Development Team To Do List application in Ruby
HTML code cleanup/reformatter in Python
Database, Web Server, and Web Application backup strategy in Bash
Java-based screen scraper, capable of scraping pure Javascript sites.
“Candidate, put these in order 1-4, 1 being the project with which you have the most comfort/expertise, and 4 being the project with which you have the least comfort/expertise.”
Now spend 15 minutes discussing project experiences pertaining to numbers 1 and 4. Also touch on how exactly the candidate would go about addressing projects rated 1 and 4, given a one week timeline to complete each. The layout for 1 is good because you get to see a little more about how well they actually know the technology with which they claimed to be most familiar. It also lets you see how they might plan out a project, for small organizations without formal project guidelines, these are pivotal skills.
The more interesting effort is the comfort level 4 project. This brainstorm session should be abstract enough that it breaks through a lot of the interview-shell, and lets you see the gears turn a little. Depending on the nature of your organization, bonus points are possible for a wide range of questions/responses:
Are we tied to this technology? (For the purpose of the interview, yes. But often this is a good question to ask.)
Are there others on the team with experience in this language? (Possibly, but they aren’t available for consultation in time)
Do I have design and functional specifications? (Ha!)
After spending a little time walking through these projects, focusing only on 1 and 4, and paying more attention to 4, get the candidate a computer with appropriate tools installed and web access. Tell them that the timeline has changed and they now have 1 hour to make project 4 work. They have the option for you to stay there as a non-technical consultant during the 1 hour mini-hackathon, or you can leave and come back in about an hour (But tell them where to find you in case they have questions - or get finished early). Interrupt them at 45 minutes to discuss how far they have gotten, how they implemented or strayed from the plan you discussed earlier, if they would have done things differently given a second chance, and their general thoughts on the rush project.
It doesn’t matter how far they get in the development. A candidate that can muscle their way through this effort, and come out with no hint of cynicism after the fact is likely a productive team member. Someone who can analyze the ideas previously discussed in a reasonable way, and think about how to move forward. This interview is not hard. It’s not meant to be, it’s meant to be informative. And I think it would be very informative, both for the candidate and the interviewer.
I’m filing this under education, because that’s really the goal here.