5 ms·

The best interview is a pair programming session around some 1-2 hour problem. It takes longer, and it may come later in the interview process, but it's a high

by sunir 15y ago

The best interview is a pair programming session around some 1-2 hour problem. It takes longer, and it may come later in the interview process, but it's a high bandwidth way of assessing someone. If they don't have a strong open source background (not everyone does), earlier in the process it helps to ask a couple very simple programming tasks, such as writing a function to reverse a string in place or the infamous fizzbuzz. It will weed out people with great resumes but poor skill.

divtxt 15y ago
Unit testing is another simple topic that provides insights into how a person thinks about code. Exercise: give them a class with empty functions, and some unit tests. Ask them to write the class and add some more tests. Also, one of the tests you provide must be subtly buggy.
- cam- 15y ago
  fwiw we make people who are interviewing do unit tests on our production code. We have enough old gnarly code that we can always find something that doesn't have coverage. It is a great way to see how they code, how they interact with unfamiliar code and how they get on socially with the person doing the interview.
  - gtrak 15y ago
    and a great way to improve test coverage for free!
fogus 15y ago
The best interview is a pair programming session Maybe, but I've come to find that pair programming is a certifiable skill that unless you've been doing it for a while needs honing. Pairing with someone great might not seem great if they have no experience with pairing. So once again, we're back to: there is no single best-way to fully assess a candidate.
- sunir 15y ago
  Well there is the intense XP understanding of pair programming, and then there is just sitting next to someone while they code version of pair programming. I can't believe anyone hasn't done something in that spectrum. Even for juniors and new grads, at school people code next to each other all the time.
  - fogus 15y ago
    sitting next to someone while they code Then that's not pair programming. Pairing is an act of give and take, Ying and Yang, Ping and Pong, and sometimes Tweedledee and Tweedledumb. Sitting next to someone looking over their shoulder solving a problem that you know the answer to is not pair programming. There is no act of mutual discovery at all.
    - sunir 15y ago
      Why limit interview questions to problems you already know the answer to? You can have them help you with some problem in your actual codebase you're already working on.
      - kooshball 15y ago
        > You can have them help you with some problem in your actual codebase you're already working on. This is a terrible idea. If they come up with a brilliant solution can you actually use this in production? Who owns the code they write during an interview?
  - HeyLaughingBoy 15y ago
    I can't believe anyone hasn't done something in that spectrum The last time I did anything like that was over 10 years ago. How would that skew your hiring process?
    - sunir 15y ago
      In my case, I may not hire you. Why haven't you worked with another developer in 10 years?
jader201 15y ago
I think this would work well. I had an interview once that had me complete 3 small tasks on my own: a debugging task, a database task, and a small web site. All three had to be completed in under 2 hours. I wasn't given much direction, other than the specs of the 3 tasks. While I think this was a moderate evaluation of my skills, it ended up being more a test of if I could complete the tasks on time, vs. the quality of my work: I ended up not making it to the next step of the interview because I was too concerned about quality code over actually completing the tasks (with mediocre code), and didn't complete the tasks, thinking that they would rather get a feel for my quality vs. if I can complete a task. I did it remotely, so they never really got a feel for my character or personality. Had it been in a paired session, things likely would have gone differently. However, I did learn more about where their priorities were, and ultimately feel I probably would not have been a good fit.

by sunir 15y ago

divtxt 15y ago

Unit testing is another simple topic that provides insights into how a person thinks about code. Exercise: give them a class with empty functions, and some unit tests. Ask them to write the class and add some more tests. Also, one of the tests you provide must be subtly buggy.

cam- 15y ago
fwiw we make people who are interviewing do unit tests on our production code. We have enough old gnarly code that we can always find something that doesn't have coverage. It is a great way to see how they code, how they interact with unfamiliar code and how they get on socially with the person doing the interview.
- gtrak 15y ago
  and a great way to improve test coverage for free!

fogus 15y ago

The best interview is a pair programming session Maybe, but I've come to find that pair programming is a certifiable skill that unless you've been doing it for a while needs honing. Pairing with someone great might not seem great if they have no experience with pairing. So once again, we're back to: there is no single best-way to fully assess a candidate.

sunir 15y ago
Well there is the intense XP understanding of pair programming, and then there is just sitting next to someone while they code version of pair programming. I can't believe anyone hasn't done something in that spectrum. Even for juniors and new grads, at school people code next to each other all the time.
- fogus 15y ago
  sitting next to someone while they code Then that's not pair programming. Pairing is an act of give and take, Ying and Yang, Ping and Pong, and sometimes Tweedledee and Tweedledumb. Sitting next to someone looking over their shoulder solving a problem that you know the answer to is not pair programming. There is no act of mutual discovery at all.
  - sunir 15y ago
    Why limit interview questions to problems you already know the answer to? You can have them help you with some problem in your actual codebase you're already working on.
    - kooshball 15y ago
      > You can have them help you with some problem in your actual codebase you're already working on. This is a terrible idea. If they come up with a brilliant solution can you actually use this in production? Who owns the code they write during an interview?
- HeyLaughingBoy 15y ago
  I can't believe anyone hasn't done something in that spectrum The last time I did anything like that was over 10 years ago. How would that skew your hiring process?
  - sunir 15y ago
    In my case, I may not hire you. Why haven't you worked with another developer in 10 years?

jader201 15y ago

I think this would work well. I had an interview once that had me complete 3 small tasks on my own: a debugging task, a database task, and a small web site. All three had to be completed in under 2 hours. I wasn't given much direction, other than the specs of the 3 tasks. While I think this was a moderate evaluation of my skills, it ended up being more a test of if I could complete the tasks on time, vs. the quality of my work: I ended up not making it to the next step of the interview because I was too concerned about quality code over actually completing the tasks (with mediocre code), and didn't complete the tasks, thinking that they would rather get a feel for my quality vs. if I can complete a task. I did it remotely, so they never really got a feel for my character or personality. Had it been in a paired session, things likely would have gone differently. However, I did learn more about where their priorities were, and ultimately feel I probably would not have been a good fit.