3 ms·

So that said how do you vet talent? Ask them to tell you stories about maintaining systems, debugging, etc?

rm999 10y ago
Personally, yes - I like asking about high-level run-downs of a project on their resume. I then choose points to stop them (either randomly or if I know a lot about the subtopic) and dig deeper and see where their comfort level lies. There are a lot of benefits to this approach: 1. Keeps the topic on something they are presumably comfortable with. 2. Gauges their seniority level: more senior folks can talk deeply about a wider variety of topics. 3. Tests their communication and explanation skills, again about a topic they should be comfortable with. Some potential pitfalls: 1. Makes it harder to objectively compare candidates. I think this is impossible anyway, so I don't consider it a big deal. 2. Some candidates, especially junior ones, simply don't have many projects on their resume to talk about. In this case I'll often ask them to explain a skill or technology they are experienced with. 3. It's harder to conduct these interviews. Giving a problem and passively watching and helping as needed is a lot easier than keeping up an active dynamic conversation.
twic 10y ago
I've seen (from both sides) two things that seem to work. Firstly, write actual code to solve a simple but real, or at least realistic, problem. That could be a take-home exercise, or it could be on-site pair programming, or some other format. Memorable examples: a stock exchange (submit orders, get trades); a Tetris engine (submit blocks, get rows filled); an auction house (submit bids, get winners); an uploader for the Azure blobstore (submit blocks, get files); an online metric summarizer (submit samples, get summaries). This tests someone's ability to actually write code. Secondly, suggest an algorithm for a real, or realistic, problem that doesn't have a well-known good solution. Memorable examples: subset-sum, but on an ordered set, where the solution must be contiguous; placing primers for PCR [1]; online k-anonymisation [2]. This tests someone's ability to think on their feet, and synthesize facts they've learnt into something new. I'm a bit dubious about the "tell me about something you worked on" question. Firstly, because it requires the candidate to have worked on something chewy, and there are lots of capable people out there who are unfortunate enough to have had crummy jobs where they don't get to do that. Secondly, because it attempts to evaluate the judgement of an individual by looking at the work of a team. Too often, as a candidate, i've had to answer "why did you do it that way?" with "because the client specifically asked for it" or "because my colleagues who were working on it at the time decided so", which isn't useful for me or the interviewer. [1] http://wiki.c2.com/?StridingAcrossSteppingStones http://wiki.c2.com/?StridingAcrossSteppingStones [2] https://en.wikipedia.org/wiki/K-anonymity https://en.wikipedia.org/wiki/K-anonymity
- prirun 10y ago
  But an easy comeback from the interviewer would have been "What other ways could you have done it? What are the advantages and/or disadvantages compared to the way the client or your colleagues mandated?"
  - twic 10y ago
    True. But now you're talking about ideas, rather than about experience, so you're testing something a bit different.

rm999 10y ago

Personally, yes - I like asking about high-level run-downs of a project on their resume. I then choose points to stop them (either randomly or if I know a lot about the subtopic) and dig deeper and see where their comfort level lies. There are a lot of benefits to this approach: 1. Keeps the topic on something they are presumably comfortable with. 2. Gauges their seniority level: more senior folks can talk deeply about a wider variety of topics. 3. Tests their communication and explanation skills, again about a topic they should be comfortable with. Some potential pitfalls: 1. Makes it harder to objectively compare candidates. I think this is impossible anyway, so I don't consider it a big deal. 2. Some candidates, especially junior ones, simply don't have many projects on their resume to talk about. In this case I'll often ask them to explain a skill or technology they are experienced with. 3. It's harder to conduct these interviews. Giving a problem and passively watching and helping as needed is a lot easier than keeping up an active dynamic conversation.

twic 10y ago

I've seen (from both sides) two things that seem to work. Firstly, write actual code to solve a simple but real, or at least realistic, problem. That could be a take-home exercise, or it could be on-site pair programming, or some other format. Memorable examples: a stock exchange (submit orders, get trades); a Tetris engine (submit blocks, get rows filled); an auction house (submit bids, get winners); an uploader for the Azure blobstore (submit blocks, get files); an online metric summarizer (submit samples, get summaries). This tests someone's ability to actually write code. Secondly, suggest an algorithm for a real, or realistic, problem that doesn't have a well-known good solution. Memorable examples: subset-sum, but on an ordered set, where the solution must be contiguous; placing primers for PCR [1]; online k-anonymisation [2]. This tests someone's ability to think on their feet, and synthesize facts they've learnt into something new. I'm a bit dubious about the "tell me about something you worked on" question. Firstly, because it requires the candidate to have worked on something chewy, and there are lots of capable people out there who are unfortunate enough to have had crummy jobs where they don't get to do that. Secondly, because it attempts to evaluate the judgement of an individual by looking at the work of a team. Too often, as a candidate, i've had to answer "why did you do it that way?" with "because the client specifically asked for it" or "because my colleagues who were working on it at the time decided so", which isn't useful for me or the interviewer. [1] http://wiki.c2.com/?StridingAcrossSteppingStones http://wiki.c2.com/?StridingAcrossSteppingStones [2] https://en.wikipedia.org/wiki/K-anonymity https://en.wikipedia.org/wiki/K-anonymity

prirun 10y ago
But an easy comeback from the interviewer would have been "What other ways could you have done it? What are the advantages and/or disadvantages compared to the way the client or your colleagues mandated?"
- twic 10y ago
  True. But now you're talking about ideas, rather than about experience, so you're testing something a bit different.