7 ms·

8. Have them code. For me, nothing else comes close to evaluating talent. I prefer making my candidate comfortable and writing something simple. 15 minutes, p

by edw519 11y ago

8. Have them code. For me, nothing else comes close to evaluating talent. I prefer making my candidate comfortable and writing something simple. 15 minutes, privacy, a drink, and pencil & paper. I hate white boards for this. I come back & see what they've done. It doesn't have to be perfect. It doesn't even have to be right. I am less concerned about their code than our discussion about their code... How did you approach the problem? Why did you name your variables like this? What is that supposed to be doing? What happens if...? What would you change if I added <x> to the problem? How else could you have done this part? Why did you choose your way? 15 minutes of coding followed by 15 minutes of Q & A about their code tells me alot. Not everything, but alot. And no programmer, no matter how nervous or introverted, should have a problem with this. As a matter of fact, most of the best programmers I've interviewed have embraced and enjoyed this. Fizzbuzz is a great problem for this. I'm still amazed by how many "experienced" programmers can't do this.

prht 11y ago
violated pen & paper, left the interview
matthewmacleod 11y ago
That's appealing. If you handed me a pen and paper and asked me to code, I'd leave. It bears essentially no relation to my work day-to-day.
- edw519 11y ago
  Thanks for proving my point. If you won't code for me in an interview, why would I possibly be interested in you? Thanks for saving me so much time.
  - deleted 11y ago
    [deleted]
    - edw519 11y ago
      Everyone and their dog is trying to hire me. Good. Go work for them. My "prima donna" filter is working nicely.
      - logfromblammo 11y ago
        I'd love to work for a retriever or pointer. Herders or guard dogs would probably be okay, too. Terriers would be nightmare bosses. I can only assume that I have never noticed these putative canine job postings because I have been looking (or smelling) in the wrong place. At the interview, should I attempt to alter my personal odor, or leave it as is? Will I be asked to sketch out an implementation of "disc fetch" on the whiteboard, or will I be given an actual flying disc and a long hallway? Should I remove experience working for cats from my resume, or leave it in?
  - Bahamut 11y ago
    He/she didn't say he/she wouldn't code during an interview, just only made a commentary about his/her reaction if expected to do so with pen and paper. I think I might walk out too, because it's clear that power will be exerted on any candidates who choose to subject themselves to it - it says a lot about the type of work environment that is fostered.
  - lostcolony 11y ago
    Thanks for being so upfront about your expectations; it saves applicants so much time, too.
  - krisdol 11y ago
    I've had to code for interviews where I was given a project to complete in my own time, and then talk about it later if it was a good solution. I aced that process and got the job. I bombed the whiteboard/paper tech interview when I was first invited to interview at my current job (lots of ex co-workers here), and was declined as a candidate. Months later I was invited again, this time just to start, skipping the interview. I'm finishing up my last week here and have nothing but praise and recommendations from my higher-ups, yet I would have never had a shot if people I worked with in the past didn't work here and reach out to me. Actually at one of the places I recently interviewed, I got past the phone screens, cultural interviews, and even a google hangouts/screen-share session where I coded live while talking about the solution -- but I still had a 'get on the whiteboard and write some twist on academic sort functions' and of course froze up more and more with each time I used the eraser. I'm confident I would have done better with a computer. I don't code on paper and whiteboards. Most of us aren't trained to, and state-dependent learning is a real thing. You cannot expect most people to perform as well in a drastically different environment from how they typically do their job.
sergiotapia 11y ago
Bad bad bad idea. There is nothing more off putting than to be asked to dance like a monkey and write code with someone over your shoulder. Ask for references, read his open source code and talk to him over lunch about some of the stuff he's worked on. Someone who doesn't know how to develop software will be easy to spot.
- edw519 11y ago
  1. No one's looking over his shoulder (re-read GP). 2. If you think coding = dancing like a monkey, maybe you should do something else. 3. I've done everything you suggest, but the interview test is much more effective. You can bullshit through your suggestions (references are a joke), but not mine. (2500 technical interviews)
dropit_sphere 11y ago
>Why did you name your variables like this? I never know how to approach this question, because often the answer is, "the problem is so simple and general to the point that all variable names are either academic (solved computer science problem with technical name for each concept involved) or hopelessly generic ("counter"). When I code things that actually do things, I just name things what they should be called. I think functional programming makes this glib prescription much more tenable, as many of the things you write are abstract of the implementation, so you never find yourself naming something "screen_refresh_counter_for_process_x."
- edw519 11y ago
  See. You're also proving my point. I don't give a shit about what you wrote on the page, I care what you have to say about it. Your comment tells me more about you than you imagine.
  - dropit_sphere 11y ago
    Maybe so, but if that's the case, isn't the entire process a case of unspecified, morphing requirements? I'll flatter myself and assume you liked what you saw in what I wrote. But if that's the case, why code at all? Why not just sit down and have a short conversation? I feel like there's something about a rigorous, test-of-endurance interview process that feels professional. "We can't afford to hire anyone but the best." So experienced hackers with good instincts end up ignoring them in favor of a gauntlet they know is not representative of actual work.
Tenhundfeld 11y ago
> I'm still amazed by how many "experienced" programmers can't do this. ... can't do this in your incredibly artificial, unrealistic context. I hate live coding in an interview, especially on paper or whiteboard. I know you say you don't care about syntax and little stuff, but that's not what happens in my brain. I suddenly forget the most basic things. "Wait, do I use semicolons at the end of lines in Ruby? Aaaah, I've been using Ruby for 5 years. How can I not know this. I'm going to bomb this interview. I should just leave now." I know it sounds ridiculous to you, but something very similar actually happened to me. Give me a block of time and a sample problem to work on at a computer, fine. Ask me to refactor code that already exists, whatevs. I'll happily write and discuss code. Just don't give me that blank piece of paper. My brain goes crazy. And the funny part is that I've been told one of my best qualities as a developer is my calm, thoughtful performance under pressure. When somebody accidentally drops that table in production or both load balancers go down, I'm your guy. I'll get it fixed quickly, without a lot of panic and fussing about. Just don't give me that piece of paper in an interview. I can't explain it, but it's true, for me. Maybe it's just that I deal with real crises often enough to have developed a mental muscle for it, but I interview so rarely that I don't have the patterns yet. Either way, I think you're missing out on great candidates with this approach.
- edw519 11y ago
  Can you do fizzbuzz in 15 minutes? It doesn't have to compile or even be right. But you should at least be able to pseudo code your way through it, explain what you did, and discuss it. For a professional programmer, anything less is just an excuse or an attitude problem.
  - Tenhundfeld 11y ago
    Sure, fizzbuzz is trivially easy – under normal circumstances. But some people find these types of exercises irrationally difficult in the context of an interview, especially when coupled with the artificiality of writing it out by hand on paper. > For a professional programmer, anything less is just an excuse or an attitude problem. You're entitled to your opinion. I disagree. I think you're projecting your personal experience of the world onto other people, which is your prerogative as the interviewer. However, speaking from personal experience, I know some people who would otherwise make excellent teammates, top contributors, etc., will fail this test, and many who pass this test will make terrible employees. As I said elsewhere, you will get many false positives and some false negatives. Thus, I think it's a bad test and a waste of time.
BinaryIdiot 11y ago
So it may not be perfect but I like approaching interviews in a similar way to the article. The questions leading up to and including #7 will let you know whether they can code or not so I'm not sure your #8 is really necessary.
qdog 11y ago
No one I generally know writes good or relevant code in 15 minute increments. In my own experience, I generally get warmed up by the 3rd or 4th interview, and it's an acting class as I regurgitate stuff. "What was your approach to the problem?" = I pretend to think for a few seconds, then answer. You're basically just figuring out if I've encountered your almost exact interview previously and I've got the canned answer ready. Currently we have a timed programming exercise we let people do at home, then review and ask questions like this over email as a filter, it seems to work fairly well. In person, I just like to ask people about their work experience, especially painful failures and learning experiences they've encountered. Things like variable names are meaningless, imho. Every company tends to have an arbitrary set of rules they like to follow, unless someone is using things like 1a a1 11a1 a1a1 altogether where I can't read it, I've gotten over caring.
nialo 11y ago
Why pen/paper and not some sort of computer? Even coding in Notepad seems better to me than paper, and can't be that hard to set up for an interview. (I think a longer work sample test on the candidates own time is probably still better, but any approximation is better than nothing)
pacofvf 11y ago
I kind of agree with you, point 7 is unrealistic, What problem could you give to the interviewee that could take a couple of days and that he/she will resolve it willingly and honestly. Yes it sounds nice but in practice I don't think so, totally agree with points 1-6 though
collyw 11y ago
I got fizzbuzzed in an interview recently. I knew exactly what to do, came out with it in a simple way in python. Then "how about without the modulo operator". The solution is so obvious - using the modulo operator, I had a mental block. It was fine once I got nudged in the right direction, but under normal circumstances I wouldn't have needed the nudge.

by edw519 11y ago

prht 11y ago

violated pen & paper, left the interview

matthewmacleod 11y ago

That's appealing. If you handed me a pen and paper and asked me to code, I'd leave. It bears essentially no relation to my work day-to-day.

edw519 11y ago
Thanks for proving my point. If you won't code for me in an interview, why would I possibly be interested in you? Thanks for saving me so much time.
- deleted 11y ago
  [deleted]
  - edw519 11y ago
    Everyone and their dog is trying to hire me. Good. Go work for them. My "prima donna" filter is working nicely.
    - logfromblammo 11y ago
      I'd love to work for a retriever or pointer. Herders or guard dogs would probably be okay, too. Terriers would be nightmare bosses. I can only assume that I have never noticed these putative canine job postings because I have been looking (or smelling) in the wrong place. At the interview, should I attempt to alter my personal odor, or leave it as is? Will I be asked to sketch out an implementation of "disc fetch" on the whiteboard, or will I be given an actual flying disc and a long hallway? Should I remove experience working for cats from my resume, or leave it in?
- Bahamut 11y ago
  He/she didn't say he/she wouldn't code during an interview, just only made a commentary about his/her reaction if expected to do so with pen and paper. I think I might walk out too, because it's clear that power will be exerted on any candidates who choose to subject themselves to it - it says a lot about the type of work environment that is fostered.
- lostcolony 11y ago
  Thanks for being so upfront about your expectations; it saves applicants so much time, too.
- krisdol 11y ago
  I've had to code for interviews where I was given a project to complete in my own time, and then talk about it later if it was a good solution. I aced that process and got the job. I bombed the whiteboard/paper tech interview when I was first invited to interview at my current job (lots of ex co-workers here), and was declined as a candidate. Months later I was invited again, this time just to start, skipping the interview. I'm finishing up my last week here and have nothing but praise and recommendations from my higher-ups, yet I would have never had a shot if people I worked with in the past didn't work here and reach out to me. Actually at one of the places I recently interviewed, I got past the phone screens, cultural interviews, and even a google hangouts/screen-share session where I coded live while talking about the solution -- but I still had a 'get on the whiteboard and write some twist on academic sort functions' and of course froze up more and more with each time I used the eraser. I'm confident I would have done better with a computer. I don't code on paper and whiteboards. Most of us aren't trained to, and state-dependent learning is a real thing. You cannot expect most people to perform as well in a drastically different environment from how they typically do their job.

sergiotapia 11y ago

Bad bad bad idea. There is nothing more off putting than to be asked to dance like a monkey and write code with someone over your shoulder. Ask for references, read his open source code and talk to him over lunch about some of the stuff he's worked on. Someone who doesn't know how to develop software will be easy to spot.

edw519 11y ago
1. No one's looking over his shoulder (re-read GP). 2. If you think coding = dancing like a monkey, maybe you should do something else. 3. I've done everything you suggest, but the interview test is much more effective. You can bullshit through your suggestions (references are a joke), but not mine. (2500 technical interviews)

dropit_sphere 11y ago

>Why did you name your variables like this? I never know how to approach this question, because often the answer is, "the problem is so simple and general to the point that all variable names are either academic (solved computer science problem with technical name for each concept involved) or hopelessly generic ("counter"). When I code things that actually do things, I just name things what they should be called. I think functional programming makes this glib prescription much more tenable, as many of the things you write are abstract of the implementation, so you never find yourself naming something "screen_refresh_counter_for_process_x."

edw519 11y ago
See. You're also proving my point. I don't give a shit about what you wrote on the page, I care what you have to say about it. Your comment tells me more about you than you imagine.
- dropit_sphere 11y ago
  Maybe so, but if that's the case, isn't the entire process a case of unspecified, morphing requirements? I'll flatter myself and assume you liked what you saw in what I wrote. But if that's the case, why code at all? Why not just sit down and have a short conversation? I feel like there's something about a rigorous, test-of-endurance interview process that feels professional. "We can't afford to hire anyone but the best." So experienced hackers with good instincts end up ignoring them in favor of a gauntlet they know is not representative of actual work.

Tenhundfeld 11y ago

> I'm still amazed by how many "experienced" programmers can't do this. ... can't do this in your incredibly artificial, unrealistic context. I hate live coding in an interview, especially on paper or whiteboard. I know you say you don't care about syntax and little stuff, but that's not what happens in my brain. I suddenly forget the most basic things. "Wait, do I use semicolons at the end of lines in Ruby? Aaaah, I've been using Ruby for 5 years. How can I not know this. I'm going to bomb this interview. I should just leave now." I know it sounds ridiculous to you, but something very similar actually happened to me. Give me a block of time and a sample problem to work on at a computer, fine. Ask me to refactor code that already exists, whatevs. I'll happily write and discuss code. Just don't give me that blank piece of paper. My brain goes crazy. And the funny part is that I've been told one of my best qualities as a developer is my calm, thoughtful performance under pressure. When somebody accidentally drops that table in production or both load balancers go down, I'm your guy. I'll get it fixed quickly, without a lot of panic and fussing about. Just don't give me that piece of paper in an interview. I can't explain it, but it's true, for me. Maybe it's just that I deal with real crises often enough to have developed a mental muscle for it, but I interview so rarely that I don't have the patterns yet. Either way, I think you're missing out on great candidates with this approach.

edw519 11y ago
Can you do fizzbuzz in 15 minutes? It doesn't have to compile or even be right. But you should at least be able to pseudo code your way through it, explain what you did, and discuss it. For a professional programmer, anything less is just an excuse or an attitude problem.
- Tenhundfeld 11y ago
  Sure, fizzbuzz is trivially easy – under normal circumstances. But some people find these types of exercises irrationally difficult in the context of an interview, especially when coupled with the artificiality of writing it out by hand on paper. > For a professional programmer, anything less is just an excuse or an attitude problem. You're entitled to your opinion. I disagree. I think you're projecting your personal experience of the world onto other people, which is your prerogative as the interviewer. However, speaking from personal experience, I know some people who would otherwise make excellent teammates, top contributors, etc., will fail this test, and many who pass this test will make terrible employees. As I said elsewhere, you will get many false positives and some false negatives. Thus, I think it's a bad test and a waste of time.

BinaryIdiot 11y ago

So it may not be perfect but I like approaching interviews in a similar way to the article. The questions leading up to and including #7 will let you know whether they can code or not so I'm not sure your #8 is really necessary.

qdog 11y ago

No one I generally know writes good or relevant code in 15 minute increments. In my own experience, I generally get warmed up by the 3rd or 4th interview, and it's an acting class as I regurgitate stuff. "What was your approach to the problem?" = I pretend to think for a few seconds, then answer. You're basically just figuring out if I've encountered your almost exact interview previously and I've got the canned answer ready. Currently we have a timed programming exercise we let people do at home, then review and ask questions like this over email as a filter, it seems to work fairly well. In person, I just like to ask people about their work experience, especially painful failures and learning experiences they've encountered. Things like variable names are meaningless, imho. Every company tends to have an arbitrary set of rules they like to follow, unless someone is using things like 1a a1 11a1 a1a1 altogether where I can't read it, I've gotten over caring.

nialo 11y ago

Why pen/paper and not some sort of computer? Even coding in Notepad seems better to me than paper, and can't be that hard to set up for an interview. (I think a longer work sample test on the candidates own time is probably still better, but any approximation is better than nothing)

pacofvf 11y ago

I kind of agree with you, point 7 is unrealistic, What problem could you give to the interviewee that could take a couple of days and that he/she will resolve it willingly and honestly. Yes it sounds nice but in practice I don't think so, totally agree with points 1-6 though

collyw 11y ago

I got fizzbuzzed in an interview recently. I knew exactly what to do, came out with it in a simple way in python. Then "how about without the modulo operator". The solution is so obvious - using the modulo operator, I had a mental block. It was fine once I got nudged in the right direction, but under normal circumstances I wouldn't have needed the nudge.