14

I have seen this happen multiple times:

The candidate likes the company, succeeds at the interview. Then comes to work and at the end of the first day he is sure the codebase/project is not what he would like to spend time with. So he leaves quickly.

I think that introducing candidates to the codebase at the interview could potentially solve this problem. Maybe even better: mixing this with interview questions like "how would you improve this part of the code?" This way, it would be obvious if the candidate is a "good fit for the codebase".

Have you seen this approach applied anywhere? Would you show your own codebase to the candidates at the interview: if they asked/as part of the interview process?

Improve this question

4 Answers 4

Reset to default
10

We not only show the candidates our code, we get them to work on it. We do pair programming, so we do interviews by pairing the candidate with one of our programmers and working on a real problem (albeit a carefully chosen one - something that doesn't need masses of contextual knowledge). They get to see our code, and we get to see their coding, and we both get to see how they fit in with our culture.

Improve this answer
5
  • 3
    I like this. What company are you working for? :)
    – Marek
    Oct 26, 2010 at 12:42
  • This would be so awesome to do, if only we did pair programming . . .
    – Wyatt Barnett
    Oct 26, 2010 at 12:52
  • But how long will be the interview process? Huge number of people might attend the interview!
    – Gopi
    Oct 26, 2010 at 14:08
  • @Sri: we only interview one person at a time. I should add that this is not the first-line interview; we start by reading CVs we are sent, then we have a phone interview with potential candidates, then we ask anyone who passes that to come in for a pairing interview. I should also add that we have a fairly focused hiring process; we tend to hire people recommended to us by employees, or people outside the company we trust, or recruitment agents we work with. We're never in the situation of having a hundred applicants to sift through.
    – Tom Anderson
    Oct 26, 2010 at 15:36
  • 2
    @Wyatt: i wonder if it might be usable even in non-pairing companies. Sit the guy down to solve a problem, acting as his guide, explaining the background, giving him support. Even just having a conversation about how to solve a concrete problem (i imagine you do do this with colleagues, even if you don't pair) could be useful.
    – Tom Anderson
    Oct 26, 2010 at 15:38
5

I haven't done it, but I would. If a developer thought it didn't look like something he wanted to work on, this could be a chance to find something out about the candidate's mentality: why doesn't he like it? What would he change? Would he enjoy being in a position where he could make such a change? If so, why did he originally say he didn't want to work on it?

I've seen sentiment on the daily WTF that people think if an interviewer shows you real code, she is trying to get the candidate to fix her problems for free. This is paranoid, IMO. The interviewer is trying to find out how well you can solve real world problems in a real world codebase. And you get to find out more about the project you'll be working on.

Improve this answer
1

Yes, if the code in question didn't belong to a client.

Last time I interviewed someone, the person rocked up and felt completely overwhelmed at the size of the codebase, and soon left.

If the code belonged to a client, it wouldn't (in my opinion) be ethical to show the source, because your client's code is your client's, not yours. (Of course, if you asked your client for permission, and you got it, then there's no problem.)

Improve this answer
1

as long as your not violating those NDA's I think it would be a Good Thing(TM). This way you get to size up the candidate and the candidate gets to size up you.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.