6 ms·

> Interviews are weird: the pressure of time, and not being able to look things up, distorts the code. In the interviews I do, I tell the candidate that: 1. T

> Interviews are weird: the pressure of time, and not being able to look things up, distorts the code. In the interviews I do, I tell the candidate that: 1. There is no time pressure. Work at a normal pace, as if you were working here. This is not a speed test. I don't expect you to finish. I mainly want to know how you think. 2. You should look things up. Behave the same way you would when coding at home. Use Google, Stack Overflow, documentation, etc. This probably works better for the interviews I give because the problem is not implementing an existing algorithm. It's a realistic task, something that we've actually built on-the-job.

voltagex_ 11y ago
Can I interview with you? Normal tech interviews make me physically ill.
- eru 11y ago
  You might also want to talk to Matasano. They are really keen on work sample tests.
  - jerematasno 11y ago
    Note that our work-sample tests are, not-insanely, done in the comfort of your own home, at your own pace, on your own schedule, and represent the work we actually do. As co-head of recruiting for NCC US (aka head of recruiting for Matasano), I think the answer to the in-person interview question of "write code to do this," is "thank you for your time, I'll see myself out."
mianos 11y ago
I wish, I did a google code interview once. The guy said we had only a short amount of time. When I solved the first one really quickly he told me, 'oh, ok, can we do another puzzle we don't have much time'. Suffice to say I went down in flames somewhat like the topic.
serve_yay 11y ago
I don't think that's good enough. It's unfair to ask candidates to write code on the spot.
- eru 11y ago
  Why? Isn't writing code exactly what you are interviewing for?
  - learc83 11y ago
    How often are you asked to solve a problem in 15 minutes while someone watches over your shoulder?
    - eli 11y ago
      Seems like you'd have a similar problem with almost any job interview for any type of position.
      - learc83 11y ago
        Ask your friends who aren't software engineers. How many of them solve problems they've never seen before while someone watches over them during an interview? The vast majority of other professions spend their time talking about past projects. For instance all my designer friends show off their portfolios, then maybe they get a take home work sample. My writer friends submit samples of their work. And my engineer friends discuss past projects they've worked on.
        eli 11y ago
        I take your point, but actually I work in media and a lot of my writer friends had to take writing or editing tests as part of their interview.
  - fapjacks 11y ago
    Maybe if you give the candidate four hours. But in the hour or so that is ubiquitous among individual interviews (even if repeated four or five times with different interviewers), you aren't going to be any meaningful information out of anything the interviewee will have time to code. An hour is enough time to write something trivial. Anything that really pushes a developer's skills is going to need a big part of that hour just for them to put pen to paper for design. The best interviews I ever had involved a week-long spare-time development project at my own pace. Those are the only interviews I ever was able to really show what I'm capable of. Incidentally, my interview at the Googleplex I thought was worthless.
madeofpalk 11y ago
We use a variation: the scenario is that us, the interviewer, is a junior developer and we've submitted our code for code review. Then later we ask the candidate to add some trivial functionality. We've found this works really well. There are unit tests, so its always a promising sign if they go for them first. Depending on what they pick up, change or ask questions about, lets us a lot about the candidate.
- julianz 11y ago
  Yep we've used a page of code from one of our systems and asked the person to talk through what they can see, what it does, what they would ask further questions about and so on. It almost instantly separates people who know a bit about code from those who don't, as the latter will literally just stare at the page for a while before giving up.
  - Corrado 11y ago
    I really like this idea and think it would work wonderfully for me. Plant a couple of easy-to-spot errors in there as well as some more difficult optimizations and see who finds them. :) It takes the pressure away from writing new code, doesn't require a computer, and still allows you to see the thought process of the interviewee.
muddyrivers 11y ago
-- "I mainly want to know how you think." I totally agree with you on this. I hope my case could help contribute to the implementation details. People have very different working styles. Since interview as a process can't be tailored to all of them, it is rationally refined to suit for the majorities. For the minorities left, I have to say one has to adjust, trying to go through the 5-hour drills. I, unfortunately, is one of the minorities. Given a hard question, one has to think first. I am the opposite of thinking aloud. In real work, I either stare at walls, or look at the vast void far away, silently. I might have a piece of paper, drawing odd shapes and graphs, because I am primarily a visual thinker. In the interview, it would definitely look odd. It could be awkward as well if I completely fall into silence, ignoring the interviewers. So I would face to the white board, wrote a few lines of pseudo-code, uttered some words, while trying to get my inner self into my real work routines. Sometimes it works relatively well, sometimes it failed completely, especially the interviewers kept talking that requires my interaction. In many cases, I understand the interviewers were trying to help, giving my hints, while the effect was the opposite of their intents.
- phamilton 11y ago
  If you think exactly like I do, you may not be the ideal candidate. However, if your approach is so radically different that I can't see how you got there, you may not be the ideal candidate. Don't worry about being different in your approach. It is, however, very important that you are able to keep someone on the same page. Edit: autocorrect
- agumonkey 11y ago
  Repeatedly it's been written how the biggest minds found solutions at random times, and more often far from their workplace. At my next interview, I'll bring a bed, ideas come when I lay in and stare at the ceiling.
  - kevrom 11y ago
    Mine always happen while in the shower. Me and that interviewer are going to come out of it a lot closer.
PopeOfNope 11y ago
Does anybody believe you when you say those things in a job interview, though? I wouldn't. A job interview is fundamentally a competition against other candidates. If you have two candidates and one finishes the task in half the time he's more likely to get the job. Time is a factor in everything. Same with looking things up. It's considerably more impressive to be able to recall minute technical details without having to look them up. The resulting cognitive dissonance adds more pressure to the situation instead of relieving it.
- shubhamjain 11y ago
  > A job interview is fundamentally a competition against other candidates. That's hardly the case. Hiring for programming is different from hiring for a cashier. The programming world, at least, if you hiring for good programmers, would rarely have a queue of candidates lined-up. You get tons of resumes daily, sift through BS, find someone good, get to know him more and after some rounds, you hire him if he is worth his salt. Rarely you would hear the phrase, "We hired the other candidate because he was skin-of-teeth better than you." Judging from the lack of engineers, a company would be very lucky to have more than one really good candidate for a position.
  - metaphorm 11y ago
    this is exactly my experience as well. having very recently completed a round of interviews for new hires, I experienced this directly. we wanted to hire 2 engineers. we interviewed about 20. found 4 that we liked. 2 of those 4 took other offers at other places they interviewed. we hired the 2 (that we liked, they have been good hires so far!) that were left. there was never anything close to anybody getting "cut" in favor of another interviewee that was fractionally better than they were. we fully intended to make offers to everyone that we thought was good.
- com2kid 11y ago
  > Does anybody believe you when you say those things in a job interview, though? I wouldn't. A job interview is fundamentally a competition against other candidates. If you have two candidates and one finishes the task in half the time he's more likely to get the job. Not at all. I have one hour to decide if I want to work with a candidate. How quickly someone works? Sure, that is important. How good is their sense of humor? Can they joke around? Can they be involved in a technical deep dive on a problem? How about coming up with test cases? I have 60 minutes and one programming problem. I've hired people who've taken from 5 minutes to 40.
perdunov 11y ago
Having no time limit is actually more stressful than to have a reasonable time limit. No time limit is basically "as fast as you can".

voltagex_ 11y ago

Can I interview with you? Normal tech interviews make me physically ill.

eru 11y ago
You might also want to talk to Matasano. They are really keen on work sample tests.
- jerematasno 11y ago
  Note that our work-sample tests are, not-insanely, done in the comfort of your own home, at your own pace, on your own schedule, and represent the work we actually do. As co-head of recruiting for NCC US (aka head of recruiting for Matasano), I think the answer to the in-person interview question of "write code to do this," is "thank you for your time, I'll see myself out."

mianos 11y ago

I wish, I did a google code interview once. The guy said we had only a short amount of time. When I solved the first one really quickly he told me, 'oh, ok, can we do another puzzle we don't have much time'. Suffice to say I went down in flames somewhat like the topic.

serve_yay 11y ago

I don't think that's good enough. It's unfair to ask candidates to write code on the spot.

eru 11y ago
Why? Isn't writing code exactly what you are interviewing for?
- learc83 11y ago
  How often are you asked to solve a problem in 15 minutes while someone watches over your shoulder?
  - eli 11y ago
    Seems like you'd have a similar problem with almost any job interview for any type of position.
    - learc83 11y ago
      Ask your friends who aren't software engineers. How many of them solve problems they've never seen before while someone watches over them during an interview? The vast majority of other professions spend their time talking about past projects. For instance all my designer friends show off their portfolios, then maybe they get a take home work sample. My writer friends submit samples of their work. And my engineer friends discuss past projects they've worked on.
      - eli 11y ago
        I take your point, but actually I work in media and a lot of my writer friends had to take writing or editing tests as part of their interview.
- fapjacks 11y ago
  Maybe if you give the candidate four hours. But in the hour or so that is ubiquitous among individual interviews (even if repeated four or five times with different interviewers), you aren't going to be any meaningful information out of anything the interviewee will have time to code. An hour is enough time to write something trivial. Anything that really pushes a developer's skills is going to need a big part of that hour just for them to put pen to paper for design. The best interviews I ever had involved a week-long spare-time development project at my own pace. Those are the only interviews I ever was able to really show what I'm capable of. Incidentally, my interview at the Googleplex I thought was worthless.

madeofpalk 11y ago

We use a variation: the scenario is that us, the interviewer, is a junior developer and we've submitted our code for code review. Then later we ask the candidate to add some trivial functionality. We've found this works really well. There are unit tests, so its always a promising sign if they go for them first. Depending on what they pick up, change or ask questions about, lets us a lot about the candidate.

julianz 11y ago
Yep we've used a page of code from one of our systems and asked the person to talk through what they can see, what it does, what they would ask further questions about and so on. It almost instantly separates people who know a bit about code from those who don't, as the latter will literally just stare at the page for a while before giving up.
- Corrado 11y ago
  I really like this idea and think it would work wonderfully for me. Plant a couple of easy-to-spot errors in there as well as some more difficult optimizations and see who finds them. :) It takes the pressure away from writing new code, doesn't require a computer, and still allows you to see the thought process of the interviewee.

muddyrivers 11y ago

-- "I mainly want to know how you think." I totally agree with you on this. I hope my case could help contribute to the implementation details. People have very different working styles. Since interview as a process can't be tailored to all of them, it is rationally refined to suit for the majorities. For the minorities left, I have to say one has to adjust, trying to go through the 5-hour drills. I, unfortunately, is one of the minorities. Given a hard question, one has to think first. I am the opposite of thinking aloud. In real work, I either stare at walls, or look at the vast void far away, silently. I might have a piece of paper, drawing odd shapes and graphs, because I am primarily a visual thinker. In the interview, it would definitely look odd. It could be awkward as well if I completely fall into silence, ignoring the interviewers. So I would face to the white board, wrote a few lines of pseudo-code, uttered some words, while trying to get my inner self into my real work routines. Sometimes it works relatively well, sometimes it failed completely, especially the interviewers kept talking that requires my interaction. In many cases, I understand the interviewers were trying to help, giving my hints, while the effect was the opposite of their intents.

phamilton 11y ago
If you think exactly like I do, you may not be the ideal candidate. However, if your approach is so radically different that I can't see how you got there, you may not be the ideal candidate. Don't worry about being different in your approach. It is, however, very important that you are able to keep someone on the same page. Edit: autocorrect
agumonkey 11y ago
Repeatedly it's been written how the biggest minds found solutions at random times, and more often far from their workplace. At my next interview, I'll bring a bed, ideas come when I lay in and stare at the ceiling.
- kevrom 11y ago
  Mine always happen while in the shower. Me and that interviewer are going to come out of it a lot closer.

PopeOfNope 11y ago

Does anybody believe you when you say those things in a job interview, though? I wouldn't. A job interview is fundamentally a competition against other candidates. If you have two candidates and one finishes the task in half the time he's more likely to get the job. Time is a factor in everything. Same with looking things up. It's considerably more impressive to be able to recall minute technical details without having to look them up. The resulting cognitive dissonance adds more pressure to the situation instead of relieving it.

shubhamjain 11y ago
> A job interview is fundamentally a competition against other candidates. That's hardly the case. Hiring for programming is different from hiring for a cashier. The programming world, at least, if you hiring for good programmers, would rarely have a queue of candidates lined-up. You get tons of resumes daily, sift through BS, find someone good, get to know him more and after some rounds, you hire him if he is worth his salt. Rarely you would hear the phrase, "We hired the other candidate because he was skin-of-teeth better than you." Judging from the lack of engineers, a company would be very lucky to have more than one really good candidate for a position.
- metaphorm 11y ago
  this is exactly my experience as well. having very recently completed a round of interviews for new hires, I experienced this directly. we wanted to hire 2 engineers. we interviewed about 20. found 4 that we liked. 2 of those 4 took other offers at other places they interviewed. we hired the 2 (that we liked, they have been good hires so far!) that were left. there was never anything close to anybody getting "cut" in favor of another interviewee that was fractionally better than they were. we fully intended to make offers to everyone that we thought was good.
com2kid 11y ago
> Does anybody believe you when you say those things in a job interview, though? I wouldn't. A job interview is fundamentally a competition against other candidates. If you have two candidates and one finishes the task in half the time he's more likely to get the job. Not at all. I have one hour to decide if I want to work with a candidate. How quickly someone works? Sure, that is important. How good is their sense of humor? Can they joke around? Can they be involved in a technical deep dive on a problem? How about coming up with test cases? I have 60 minutes and one programming problem. I've hired people who've taken from 5 minutes to 40.

perdunov 11y ago

Having no time limit is actually more stressful than to have a reasonable time limit. No time limit is basically "as fast as you can".