17 ms·

What not to do when giving technical interviews (2014)

69 points by andrelaszlo 7y ago

yoz-y 7y ago
I agree that it is best to hire people that will evolve as that is the crucial part of being a good engineer, but you still need people that know how to start, your company is not a school. The problem FizzBuzz test is trying to solve is not to find the good candidate, but to weed out the vast majority of applicants that can't code at all. Depending on where you put your job postings you can get really swamped by them.
- perl4ever 7y ago
  "to weed out the vast majority of applicants that can't code at all." I think one ought to consider the possibility that if the vast majority of interviewees can't code at all, there is something wrong with the company/process. I mean, I'm not saying it necessarily follows, but the question is worth considering. I have never been asked to implement FizzBuzz, so I can't buy the claim that "everybody does it". Rightly or wrongly, if I was asked tomorrow, I wouldn't have the preconception that it was appropriate or necessary, and thus wouldn't necessarily choose to continue if I thought it was indicative of culture. If other people react similarly, it doesn't necessarily matter if it is a reasonable standard of competence; you're still skewing the pool in other ways than you intend.
  - yoz-y 7y ago
    I think FizzBuzz is an example, when I was interviewing I mostly got questions in this vein during first or second telephone screen (some companies use an online multiplayer notepad or some other method). When I was doing interviews I was always mostly discussing motivation. Most of the time the hires turned out very good, but I did happen to have one bad one and it cost us quite some time.
    - perl4ever 7y ago
      I have had the experience of doing well on the programming test at the beginning of the process and being rejected for other reasons. Maybe counter-intuitively, that made me less interested in doing such tests, since in that case it wasn't determinative. It's possible that many or most places feel that to ensure someone doesn't cheat on a take-home, they must demonstrate their ability in the in-person interview. Which is logical, but it also makes me think that going through a process starting with a take-home is a waste of my time, as long as it's not a universal requirement.
      - yoz-y 7y ago
        What you describe is normal. Assignments usually go from easy to hard because usually it is faster to solve the easy problems and usually these questions can be also asked by less technical people. Several companies I have interviewed with had the first programming questions asked by recruiters (who clearly had CS background, but most probably just shifted careers)
        perl4ever 7y ago
        What I'm talking about had a much more involved test than Fizzbuzz at the beginning, IIRC something like 5 small projects, but with your choice of language, and a generous amount of time (days). During the interview, it was simpler, but in an environment I'd never used before and a language which I had disclosed up front I didn't have recent experience in. It seemed like they were only interested in hiring new college grads at the end, but perversely the process started by senior people referring me and screening me. While I admit it sounds like sour grapes, I thought later that the organization probably had communication/coordination problems that would've made it unpleasant to work for. In some organizations, they start by recruiting people they think have talent in general, and then the interview is about finding where you fit in. In others, they have a very specific need and they focus on winnowing down the pool to get the (hopefully) best person for it. The place I'm talking about seemed to have a split personality. Also, I've had enough interviews, both successful and unsuccessful, to be clear that there is no "normal". Every place is unique, as was this.
ddelt 7y ago
Thank you for posting this. Not sure how many times these same points need to be repeated for it to sink in.
- andrelaszlo 7y ago
  You're welcome. I'm not sure either. I think my main take-away from this article is that hiring is a human activity first and a technical one second. There seems to be an attitude of "I had to go through this, so I don't see why new hires shouldn't" hidden under a thin layer of justifications but in fact we're playing a game with very limited information. We probably don't even have the tools to know if we're doing good or bad hires except in extreme cases. We almost certainly don't know if we're rejecting the wrong people. Still we pretend like it's working. To me, it seems overly rigid, pattern-matching against a too-narrow idea of what a good developer/employee/team member is. So much could be improved by just adding some flexibility, but maybe we're afraid of losing the illusion of having a Process and Objective Criteria. Maybe I'm naive, but aren't we looking for what people are good at and what they might bring to the table? Maybe someone likes programming puzzles and whiteboards, let them do it, but don't insist if it freaks another person out. Maybe someone else would rather do a take-home assignment, but don't insist on it if someone else don't have the will to do several hours of unpaid work. Others might prefer pair-programming in person, technical quizzes, Codility-style problem solving online, actual paid work on a project basis.
  - perl4ever 7y ago
    One self-defeating pattern is having different parts of the interview process filter out different types of people, so that neither one can make it through the whole process. Sometimes (well, maybe even typically) the beginning and ending of an application process are with different groups, and types, of people.
JoshTriplett 7y ago
I agree entirely with the premise of the article. One nit, though: > The famous fizzbuzz test simply asks "are you aware of the modulo operator?" FizzBuzz also tests basic programming skill, and it's surprising how often people fail that part. FizzBuzz isn't necessarily the best test of that; I know one interviewer who instead uses "write a function to swap two numbers". But some test of basic programming skill does help, albeit it should happen long before the in-person interview.
- logicallee 7y ago
  How would you swap two numbers?
  - JoshTriplett 7y ago
    Part of the point of the question is to get people thinking about that, solving it on the fly, and explaining their reasoning. One of the lightbulb moments is when they realize the function needs to take pointers or similar (and typically ask if that's OK).
    - itronitron 7y ago
      Have you, as part of your day job, ever written a function solely for the purpose of swapping two numbers?
      - whatshisface 7y ago
        I have written code that swaps numbers as part of a larger function.
      - JoshTriplett 7y ago
        Yes, for code in languages that don't have it as a built-in library function. I've also written functions to swap strings, and implementations of various standard library functions. Also: have you, as part of your day job, ever written code to solve a specific word puzzle? (Based on an actual interview question I've answered.) An interview question is supposed to be representative; that doesn't mean every interview question must come directly from a specific problem encountered in production code. You ask questions to prompt people and see how they think and how they communicate.
gjm11 7y ago
There is at least one serious misconception in this article. > The famous fizzbuzz test simply asks "are you aware of the modulo operator?" Nope. The famous fizzbuzz test simply asks "can you actually write code at all?", because it turns out that some people applying for software development jobs basically can't. Even people with relevant-looking experience on their CV/resume. Even people who talk convincingly about what they've done. (If you don't know about your preferred language's modulo operator but can do truncating integer division, you can do FizzBuzz that way instead. If you don't know how to do division, you can do it by having counters that count up mod 3 and mod 5, or one counter that counts up mod 15, and you don't need "mod" in your vocabulary to do any of that.) Now, whether a candidate can write code -- like whether they know their language's modulo operator -- is also just one bit of information, but it's a really important bit of information that turns out to be tricky to get. This is also one reason for the "code on a whiteboard" tasks that many interviews use, which the author also doesn't like. It may be that those are bad ways to get that one bit of information. But the author doesn't seem to appreciate what problem those things he criticizes are trying to solve.
- acjohnson55 7y ago
  In my experience, this just isn't a real problem. If someone has any sort of track record in the industry, I've been able to correctly conclude that they can code. The only time I've found sample code useful is for people who are brand new.
  - q3k 7y ago
    In my experience, it is. I've done technical screens with _failed_ fizzbuzz-grade problems to people whose CV said that they have been coding for years, and those people were looking for (Senior) developer roles (not management, 'architect', just plain developer).
    - ScottFree 7y ago
      If you can't screen those people out in the introductory phone call then your hiring process is broken.
acjohnson55 7y ago
Totally agree. I hadn't seen this article until now, and I'm thankful for it because I think this is a message that needs repeating from many points of view. Engineering hiring is a farce through much of the industry. I've written two articles along these same lines: https://m.huffpost.com/us/entry/us_7973484 https://m.huffpost.com/us/entry/us_7973484 https://acjay.com/2019/05/16/hiring-developers-is-easy/ https://acjay.com/2019/05/16/hiring-developers-is-easy/
mnd999 7y ago
I’ve recently learned via a few interviews at tech companies that interviewing for tech companies is a completely different skill to working at one. I’m sticking to contracting for now I guess.
- turk73 7y ago
  The problem with contracting is that you end up interviewing even more, not less!
- skizm 7y ago
  Do you not have to go through the same interviews for contract work, assuming you are programming?
  - mnd999 7y ago
    Usually it’s a lot more straightforward. Contracts can be terminated at very short notice if you’re not delivering so it’s not usually worth spending a lot of time interviewing.
pjc50 7y ago
As pointed out in the article, fizzbuzz doesn't test "can you code at all", it tests "can you code under interview conditions, including highly unnatural ones like on a whiteboard". On the other hand, "hiring for future potential" sounds great but is really vulnerable to personal bias since it's inherently about the unknown future. If you want to run a deterministic interview process you need to have a standard set of questions and a rubric for assessing answers, written up in advance.
- taneq 7y ago
  If you can't write fizzbuzz in a few minutes on a whiteboard, even in pseudocode, then you can't code.
  - mikelevins 7y ago
    I can't write fizzbuzz in a few minutes on a whiteboard under interview conditions, but I've shipped multiple products over three decades. Several of them are from 50% to 100% code written by me. The syllogism you're proposing overlooks some human variables. Interpersonal interaction tends to completely occupy my cognitive capacity, the moreso if the other person is a stranger, or if they are challenging me in some way (such as, for example, posing puzzles and evaluating the quality of my answers). I can't think about logical operations under those conditions. I require peace and detachment from human concerns in order to think that way. This is, of course, a personal quirk, or, if you prefer, disability, and nobody should have to bear the burden of it but me. But I've been an actual 10X programmer on a shipping product, as verified by DVCS statistics. I submit that as evidence that I can, in fact, code. I just can't do it in interview conditions. I also can't navigate while interacting with someone. I can drive just fine; I can operate a vehicle safely. I just can't navigate. Everyone in my close family is aware of this limitation. When my daughter was a teenager, she exploited this quirk for laughs. I have to admit, I thought it was pretty funny, too. In particular, I remember a pause in a conversation where I looked around and realized that I was parked at a Safeway in Capitola, California, and had no idea how I got there. My daughter and I both laughed when I realized what had happened. But if you want me to drive, and you want to reach a specific, predictable destination, you have to leave me alone to navigate. Similarly, if you want me to be a 10X programmer, or indeed any kind of working programmer, you have to leave me alone to do it. Maybe I'm not the only one. I won't argue that you should accommodate me, or people like me. Maybe you don't need us. That's okay. I've found other ways to get by--being hired by people already familiar with my other work, for example, or making my own products. It's maybe a less predictable career path than the usual, but it's worked so far. But for obvious reasons, I can't agree with your claim.
hahamrfunnyguy 7y ago
I can't say I agree with everything here. I've found live coding to be a useful way to gauge how someone thinks. Prior to the in-person interview, a 10-15 minute phone screen has already been done as well as a easy programming problem that takes most senior developers 5-10 minutes to solve it. So when we bring them in, we think they should be able to "pass" the interview. When they arrive on site, we give them a 90% completed program that needs 2-3 lines of code to finish. We tell them they can use the web to look up anything they need to. We're mainly looking to see how the candidate thinks, and we discuss what they're doing and why. We're more concerned about the why than the what. Once this is done (about 15-20 minutes in), we have a reasonable understanding if someone would be able to do the work. Next we try to figure out how much they would need to learn to be productive, and try to see if the candidate would be a good fit culturally. We had one candidate who a minute or two into the live coding exercise said "Geez, I really don't think I can do this." I reminded him we weren't looking for a correct answer and to just give it a try, and he wouldn't. I thanked him for his time and ended the interview.
- JustSomeNobody 7y ago
  I like this. Of course I enjoy reading code so that may be why. On the other hand I’ve met a fair number of devs who either can’t read code or just wont. I wonder if the person in your example would have passed had you simply given him a problem to code from scratch.
- cableshaft 7y ago
  If this (finishing a program missing only a few lines of code) were all most coding interviews were, I don't think there'd be anywhere near as many complaints about them. That's very similar to what you'd actually be doing on the job. It's coming up with what you took in your data structures/algorithms class a decade ago on the spot and write full functions about them, especially on a whiteboard, that gets really annoying, and makes programmers feel like they have to refresh their knowledge of an entire class (plus a bunch of other trivia from across CS) every time they want to find a new job.
Lendal 7y ago
Sometimes I do have time constraints fixing a bug. In fact most of the time that constraint is imposed by me, because I have pride in my work. But at the same time I hope my manager understands that staring over my shoulder for 45 minutes doesn't help. Hopefully in my next interview I can get these ideas across respectfully.
- perl4ever 7y ago
  There are different levels of distraction. Staring over my shoulder is one. Having a conversation with me about what I need to fix is another. For some reason, I find it impossible to figure things out when I am looking over someone else's shoulder, or in a meeting, but when I am seated at my desk, it is vastly easier.
collyw 7y ago
"No Assholes policy" The golden question being "who gets to decide who is an asshole" Ironically a paragraph down they say: "You are NOT hiring for "team fit""
- fogetti 7y ago
  Right? It's the same age old question as "Whose code is the worst?" Not surprisingly it's always someone else's code.
tictacttoe 7y ago
Anecdoctal, but while we are discussing narrow scope interviews... I just finished a physics PhD and applied to a finance firm. Before I get a chance to speak with a human, they send me a 15 problem 20 min timed exam. Some of the questions were easy and some required thought, unless you’ve been sitting around practicing riddles and LSAT questions all day. I timed out halfway through the exam. It wasn’t even clear a priori how to navigate the exam, or if I could skip questions or how I would be graded. The company effectively canceled my application based on the 50% score. Now, I’ve probably taken 100+ math exams in my life and I’d be happy to provide data from any one of them. Why trump all that data with 15 questions? Viewing the application process as a pure machine learning problem, their decision seems crazy.
sexyflanders 7y ago
You lost me at Joel Spolsky. Hosting a tech Q&A site doesn't make you the canonical source of how to structure interviews. The live coding interview style was a toxic and negative contribution to the tech industry as a whole, IMO.
- xtracto 7y ago
  Sorry, but I strongly disagree with you. Reading the cited book (Smart and gets thing done) was an absolute eye opener for me, and for every person that I have recommended it to. Really, you should read it (unless you were only trolling). It is a very fast read and full of insight. Also, "tech Q&A site " is a huge mischaracterization of Joel's blog. He has really insightful articles like "Evidence based Scheduling", or the ones about (not) rewriting-code.
invalidOrTaken 7y ago
I think next time I interview someone I'll ask them to fizzbuzz: - if they are confident and fail, I'll pass on them - if they are nervous and we'll fail, we'll talk about it, and move on with the interview - if they succeed, I'll move on w/the interview - if they refuse, I'll hire them immediately and recommend them for promotion

69 points by andrelaszlo 7y ago

I agree that it is best to hire people that will evolve as that is the crucial part of being a good engineer, but you still need people that know how to start, your company is not a school. The problem FizzBuzz test is trying to solve is not to find the good candidate, but to weed out the vast majority of applicants that can't code at all. Depending on where you put your job postings you can get really swamped by them.

perl4ever 7y ago
"to weed out the vast majority of applicants that can't code at all." I think one ought to consider the possibility that if the vast majority of interviewees can't code at all, there is something wrong with the company/process. I mean, I'm not saying it necessarily follows, but the question is worth considering. I have never been asked to implement FizzBuzz, so I can't buy the claim that "everybody does it". Rightly or wrongly, if I was asked tomorrow, I wouldn't have the preconception that it was appropriate or necessary, and thus wouldn't necessarily choose to continue if I thought it was indicative of culture. If other people react similarly, it doesn't necessarily matter if it is a reasonable standard of competence; you're still skewing the pool in other ways than you intend.
- yoz-y 7y ago
  I think FizzBuzz is an example, when I was interviewing I mostly got questions in this vein during first or second telephone screen (some companies use an online multiplayer notepad or some other method). When I was doing interviews I was always mostly discussing motivation. Most of the time the hires turned out very good, but I did happen to have one bad one and it cost us quite some time.
  - perl4ever 7y ago
    I have had the experience of doing well on the programming test at the beginning of the process and being rejected for other reasons. Maybe counter-intuitively, that made me less interested in doing such tests, since in that case it wasn't determinative. It's possible that many or most places feel that to ensure someone doesn't cheat on a take-home, they must demonstrate their ability in the in-person interview. Which is logical, but it also makes me think that going through a process starting with a take-home is a waste of my time, as long as it's not a universal requirement.
    - yoz-y 7y ago
      What you describe is normal. Assignments usually go from easy to hard because usually it is faster to solve the easy problems and usually these questions can be also asked by less technical people. Several companies I have interviewed with had the first programming questions asked by recruiters (who clearly had CS background, but most probably just shifted careers)
      - perl4ever 7y ago
        What I'm talking about had a much more involved test than Fizzbuzz at the beginning, IIRC something like 5 small projects, but with your choice of language, and a generous amount of time (days). During the interview, it was simpler, but in an environment I'd never used before and a language which I had disclosed up front I didn't have recent experience in. It seemed like they were only interested in hiring new college grads at the end, but perversely the process started by senior people referring me and screening me. While I admit it sounds like sour grapes, I thought later that the organization probably had communication/coordination problems that would've made it unpleasant to work for. In some organizations, they start by recruiting people they think have talent in general, and then the interview is about finding where you fit in. In others, they have a very specific need and they focus on winnowing down the pool to get the (hopefully) best person for it. The place I'm talking about seemed to have a split personality. Also, I've had enough interviews, both successful and unsuccessful, to be clear that there is no "normal". Every place is unique, as was this.

ddelt 7y ago

Thank you for posting this. Not sure how many times these same points need to be repeated for it to sink in.

andrelaszlo 7y ago
You're welcome. I'm not sure either. I think my main take-away from this article is that hiring is a human activity first and a technical one second. There seems to be an attitude of "I had to go through this, so I don't see why new hires shouldn't" hidden under a thin layer of justifications but in fact we're playing a game with very limited information. We probably don't even have the tools to know if we're doing good or bad hires except in extreme cases. We almost certainly don't know if we're rejecting the wrong people. Still we pretend like it's working. To me, it seems overly rigid, pattern-matching against a too-narrow idea of what a good developer/employee/team member is. So much could be improved by just adding some flexibility, but maybe we're afraid of losing the illusion of having a Process and Objective Criteria. Maybe I'm naive, but aren't we looking for what people are good at and what they might bring to the table? Maybe someone likes programming puzzles and whiteboards, let them do it, but don't insist if it freaks another person out. Maybe someone else would rather do a take-home assignment, but don't insist on it if someone else don't have the will to do several hours of unpaid work. Others might prefer pair-programming in person, technical quizzes, Codility-style problem solving online, actual paid work on a project basis.
- perl4ever 7y ago
  One self-defeating pattern is having different parts of the interview process filter out different types of people, so that neither one can make it through the whole process. Sometimes (well, maybe even typically) the beginning and ending of an application process are with different groups, and types, of people.

JoshTriplett 7y ago

I agree entirely with the premise of the article. One nit, though: > The famous fizzbuzz test simply asks "are you aware of the modulo operator?" FizzBuzz also tests basic programming skill, and it's surprising how often people fail that part. FizzBuzz isn't necessarily the best test of that; I know one interviewer who instead uses "write a function to swap two numbers". But some test of basic programming skill does help, albeit it should happen long before the in-person interview.

logicallee 7y ago
How would you swap two numbers?
- JoshTriplett 7y ago
  Part of the point of the question is to get people thinking about that, solving it on the fly, and explaining their reasoning. One of the lightbulb moments is when they realize the function needs to take pointers or similar (and typically ask if that's OK).
  - itronitron 7y ago
    Have you, as part of your day job, ever written a function solely for the purpose of swapping two numbers?
    - whatshisface 7y ago
      I have written code that swaps numbers as part of a larger function.
    - JoshTriplett 7y ago
      Yes, for code in languages that don't have it as a built-in library function. I've also written functions to swap strings, and implementations of various standard library functions. Also: have you, as part of your day job, ever written code to solve a specific word puzzle? (Based on an actual interview question I've answered.) An interview question is supposed to be representative; that doesn't mean every interview question must come directly from a specific problem encountered in production code. You ask questions to prompt people and see how they think and how they communicate.

gjm11 7y ago

There is at least one serious misconception in this article. > The famous fizzbuzz test simply asks "are you aware of the modulo operator?" Nope. The famous fizzbuzz test simply asks "can you actually write code at all?", because it turns out that some people applying for software development jobs basically can't. Even people with relevant-looking experience on their CV/resume. Even people who talk convincingly about what they've done. (If you don't know about your preferred language's modulo operator but can do truncating integer division, you can do FizzBuzz that way instead. If you don't know how to do division, you can do it by having counters that count up mod 3 and mod 5, or one counter that counts up mod 15, and you don't need "mod" in your vocabulary to do any of that.) Now, whether a candidate can write code -- like whether they know their language's modulo operator -- is also just one bit of information, but it's a really important bit of information that turns out to be tricky to get. This is also one reason for the "code on a whiteboard" tasks that many interviews use, which the author also doesn't like. It may be that those are bad ways to get that one bit of information. But the author doesn't seem to appreciate what problem those things he criticizes are trying to solve.

acjohnson55 7y ago
In my experience, this just isn't a real problem. If someone has any sort of track record in the industry, I've been able to correctly conclude that they can code. The only time I've found sample code useful is for people who are brand new.
- q3k 7y ago
  In my experience, it is. I've done technical screens with _failed_ fizzbuzz-grade problems to people whose CV said that they have been coding for years, and those people were looking for (Senior) developer roles (not management, 'architect', just plain developer).
  - ScottFree 7y ago
    If you can't screen those people out in the introductory phone call then your hiring process is broken.

acjohnson55 7y ago

Totally agree. I hadn't seen this article until now, and I'm thankful for it because I think this is a message that needs repeating from many points of view. Engineering hiring is a farce through much of the industry. I've written two articles along these same lines: https://m.huffpost.com/us/entry/us_7973484 https://m.huffpost.com/us/entry/us_7973484 https://acjay.com/2019/05/16/hiring-developers-is-easy/ https://acjay.com/2019/05/16/hiring-developers-is-easy/

mnd999 7y ago

I’ve recently learned via a few interviews at tech companies that interviewing for tech companies is a completely different skill to working at one. I’m sticking to contracting for now I guess.

turk73 7y ago
The problem with contracting is that you end up interviewing even more, not less!
skizm 7y ago
Do you not have to go through the same interviews for contract work, assuming you are programming?
- mnd999 7y ago
  Usually it’s a lot more straightforward. Contracts can be terminated at very short notice if you’re not delivering so it’s not usually worth spending a lot of time interviewing.

pjc50 7y ago

As pointed out in the article, fizzbuzz doesn't test "can you code at all", it tests "can you code under interview conditions, including highly unnatural ones like on a whiteboard". On the other hand, "hiring for future potential" sounds great but is really vulnerable to personal bias since it's inherently about the unknown future. If you want to run a deterministic interview process you need to have a standard set of questions and a rubric for assessing answers, written up in advance.

taneq 7y ago
If you can't write fizzbuzz in a few minutes on a whiteboard, even in pseudocode, then you can't code.
- mikelevins 7y ago
  I can't write fizzbuzz in a few minutes on a whiteboard under interview conditions, but I've shipped multiple products over three decades. Several of them are from 50% to 100% code written by me. The syllogism you're proposing overlooks some human variables. Interpersonal interaction tends to completely occupy my cognitive capacity, the moreso if the other person is a stranger, or if they are challenging me in some way (such as, for example, posing puzzles and evaluating the quality of my answers). I can't think about logical operations under those conditions. I require peace and detachment from human concerns in order to think that way. This is, of course, a personal quirk, or, if you prefer, disability, and nobody should have to bear the burden of it but me. But I've been an actual 10X programmer on a shipping product, as verified by DVCS statistics. I submit that as evidence that I can, in fact, code. I just can't do it in interview conditions. I also can't navigate while interacting with someone. I can drive just fine; I can operate a vehicle safely. I just can't navigate. Everyone in my close family is aware of this limitation. When my daughter was a teenager, she exploited this quirk for laughs. I have to admit, I thought it was pretty funny, too. In particular, I remember a pause in a conversation where I looked around and realized that I was parked at a Safeway in Capitola, California, and had no idea how I got there. My daughter and I both laughed when I realized what had happened. But if you want me to drive, and you want to reach a specific, predictable destination, you have to leave me alone to navigate. Similarly, if you want me to be a 10X programmer, or indeed any kind of working programmer, you have to leave me alone to do it. Maybe I'm not the only one. I won't argue that you should accommodate me, or people like me. Maybe you don't need us. That's okay. I've found other ways to get by--being hired by people already familiar with my other work, for example, or making my own products. It's maybe a less predictable career path than the usual, but it's worked so far. But for obvious reasons, I can't agree with your claim.

hahamrfunnyguy 7y ago

I can't say I agree with everything here. I've found live coding to be a useful way to gauge how someone thinks. Prior to the in-person interview, a 10-15 minute phone screen has already been done as well as a easy programming problem that takes most senior developers 5-10 minutes to solve it. So when we bring them in, we think they should be able to "pass" the interview. When they arrive on site, we give them a 90% completed program that needs 2-3 lines of code to finish. We tell them they can use the web to look up anything they need to. We're mainly looking to see how the candidate thinks, and we discuss what they're doing and why. We're more concerned about the why than the what. Once this is done (about 15-20 minutes in), we have a reasonable understanding if someone would be able to do the work. Next we try to figure out how much they would need to learn to be productive, and try to see if the candidate would be a good fit culturally. We had one candidate who a minute or two into the live coding exercise said "Geez, I really don't think I can do this." I reminded him we weren't looking for a correct answer and to just give it a try, and he wouldn't. I thanked him for his time and ended the interview.

JustSomeNobody 7y ago
I like this. Of course I enjoy reading code so that may be why. On the other hand I’ve met a fair number of devs who either can’t read code or just wont. I wonder if the person in your example would have passed had you simply given him a problem to code from scratch.
cableshaft 7y ago
If this (finishing a program missing only a few lines of code) were all most coding interviews were, I don't think there'd be anywhere near as many complaints about them. That's very similar to what you'd actually be doing on the job. It's coming up with what you took in your data structures/algorithms class a decade ago on the spot and write full functions about them, especially on a whiteboard, that gets really annoying, and makes programmers feel like they have to refresh their knowledge of an entire class (plus a bunch of other trivia from across CS) every time they want to find a new job.

Lendal 7y ago

Sometimes I do have time constraints fixing a bug. In fact most of the time that constraint is imposed by me, because I have pride in my work. But at the same time I hope my manager understands that staring over my shoulder for 45 minutes doesn't help. Hopefully in my next interview I can get these ideas across respectfully.

perl4ever 7y ago
There are different levels of distraction. Staring over my shoulder is one. Having a conversation with me about what I need to fix is another. For some reason, I find it impossible to figure things out when I am looking over someone else's shoulder, or in a meeting, but when I am seated at my desk, it is vastly easier.

collyw 7y ago

"No Assholes policy" The golden question being "who gets to decide who is an asshole" Ironically a paragraph down they say: "You are NOT hiring for "team fit""

fogetti 7y ago
Right? It's the same age old question as "Whose code is the worst?" Not surprisingly it's always someone else's code.

tictacttoe 7y ago

Anecdoctal, but while we are discussing narrow scope interviews... I just finished a physics PhD and applied to a finance firm. Before I get a chance to speak with a human, they send me a 15 problem 20 min timed exam. Some of the questions were easy and some required thought, unless you’ve been sitting around practicing riddles and LSAT questions all day. I timed out halfway through the exam. It wasn’t even clear a priori how to navigate the exam, or if I could skip questions or how I would be graded. The company effectively canceled my application based on the 50% score. Now, I’ve probably taken 100+ math exams in my life and I’d be happy to provide data from any one of them. Why trump all that data with 15 questions? Viewing the application process as a pure machine learning problem, their decision seems crazy.

sexyflanders 7y ago

You lost me at Joel Spolsky. Hosting a tech Q&A site doesn't make you the canonical source of how to structure interviews. The live coding interview style was a toxic and negative contribution to the tech industry as a whole, IMO.

xtracto 7y ago
Sorry, but I strongly disagree with you. Reading the cited book (Smart and gets thing done) was an absolute eye opener for me, and for every person that I have recommended it to. Really, you should read it (unless you were only trolling). It is a very fast read and full of insight. Also, "tech Q&A site " is a huge mischaracterization of Joel's blog. He has really insightful articles like "Evidence based Scheduling", or the ones about (not) rewriting-code.

invalidOrTaken 7y ago

I think next time I interview someone I'll ask them to fizzbuzz: - if they are confident and fail, I'll pass on them - if they are nervous and we'll fail, we'll talk about it, and move on with the interview - if they succeed, I'll move on w/the interview - if they refuse, I'll hire them immediately and recommend them for promotion