Developer Job Interviews
-
So, I've conducted job interviews in the past while I worked in the restaurant industry. I quite liked it, and I feel like I was very successful at finding good team members. Now, I have the opportunity to interview people for developer positions on my team. I've been reading a little about what makes a good interview for computer programmers, and I am wondering if anyone here in the lounge has any good advice for quickly and effectively determining whether or not a developer is 'worth his/her salt'. What works for you? Are there any pitfalls that you experienced that I should avoid? Thanks!
-
I think #8 is very important. Don't wait six months for the guy to "settle in" if it's obvious that he's a time-wasting moron. Here are some other rules #9. Coding tests are not effective at finding senior people. Coding tests are exactly like computer science homework problems; a trick question and 12 lines of code. They reward candidates with recent practice doing CS homework problems. Senior devs on real projects don't code that way. They nibble away at a big problem a little every day until it's done. #10. Don't wait for the "perfect" candidate. Pick the best candidate who's "pretty close" and apply rule #8 if needed. If the new hire works out, he starts working down your backlog soonest. If he doesn't work out, fire him and continue looking. #11. People who can think are rare. People whose resume says they can program in WhizBang 2013 are common. Concentrate on finding people who can think. They can *learn* WhizBang 2013. #12. Team fit is more important than skill set. See previous rule. A bad team fit can make your whole team unproductive and grouchy. The damage from a poor skill set is usually more localized.
Team fit is definitely more important than skill set, but less important than the ability to think, IMO.
-
Awesome list! Especially 4, and 7 are very helpful. I'm used to hiring extroverts (they seem to do better with face-to-face customer service), so that is a great thing to be aware of. I like to think of myself as an introvert, so I hope that there won't be much bias. As far as being "expert", I am very lenient on that. I am more concerned with someone's ability to learn quickly than whether or not they are familiar with my entire technology stack, and so on.
I'm less concerned with someone's ability to learn quickly, as much as I'm concerned with his ability to learn thoroughly. I've seen people being able to write some hackish, working but ugly code in two days after meeting a new language, but unable to get their code straight after three more months, and people not being to produce anything for two weeks, but producing production-grade code right after that. It's just different learning patterns. Since you spend 90% of your time on code on maintenance, I'd say the first type is a liability, whereas the second one may incur a higher up-front cost for each new technology you introduce, but this cost is more than covered by the economies you do during maintenance. Of course, there are the extremes - slow learners which never produce usable code and fast learners which always produce usable code. But IME these are rare. Besides both categories being rare, the underperformers are quickly eliminated by the job market (they get so many bad references that you never call them to an interview, provided you check references), whereas the overperformers rarely look for a new job - when they do, they target a very specific position. IME, only experience gained after quite some interviews will allow you to tell the difference. OTOH, also IME, this is where coding tests make sense - not because the code alone allows you to gauge the interviewee, but because you can use the code the interviewee wrote as a pretext/base for a more hands-on discussion. You can even try pair programming during the coding test, to see how things work out.
-
So, I've conducted job interviews in the past while I worked in the restaurant industry. I quite liked it, and I feel like I was very successful at finding good team members. Now, I have the opportunity to interview people for developer positions on my team. I've been reading a little about what makes a good interview for computer programmers, and I am wondering if anyone here in the lounge has any good advice for quickly and effectively determining whether or not a developer is 'worth his/her salt'. What works for you? Are there any pitfalls that you experienced that I should avoid? Thanks!
My thoughts http://www.darrollwalsh.com/post/2012/10/22/Developer-Technical-Screenings.aspx[^]
Darroll
-
Have them code something that is exactly what they would be doing in the position, screw fizz buzz bop, whatever. My advice, once you determine someone to meet the competence level you expect, go on their personality, since you will probably spend more waking hours with them than your wife. Choose them like you are choosing a mate. Here's an analogy: Skills are like good looks and writing great code is the equivalent of being sexy, but a bad personality can make a mate, or in this case candidate, ugly. Do you want to spend 50 hours a week with a bitch/asshole just because they look good? Also, try to gauge if they are creepy. Is their outlook on life shitty? Can they at least hide that during the interview? Do they seem like they want the job? Or do are they only looking because they need a salary?
wizardzz wrote:
since you will probably spend more waking hours with them than your wife.
Why would you expect his wife to spend more time with them? :omg:
-
It was 100% the other way round, I was the candidate. My interviewer couldn't believe my code compiled using readonly, I tried to show him the MSDN link, he accused me of installing something and got a bit irate. I had to commandeer the mouse to show him the link.
-
Nice :) did you get the Job or not? if not I would urge you to consider that winning can sometimes be loosing
They offered me the job, but I didn't take it. One of my pet hates as a developer are people who think they know better than the manufacturer's documentation. Unfortunately my current employers have a few of these too, except they're not in any position of power.
-
They offered me the job, but I didn't take it. One of my pet hates as a developer are people who think they know better than the manufacturer's documentation. Unfortunately my current employers have a few of these too, except they're not in any position of power.