4 ms·

This is a tricky problem. Here are some things I've found helpful on the other side of the table: - Pick a real world task (e.g. text munging). - Suggest in a

This is a tricky problem. Here are some things I've found helpful on the other side of the table: - Pick a real world task (e.g. text munging). - Suggest in advance that they bring a laptop with their preferred work environment. Allow any reasonable language if you're willing to train them on your stack. - Write the problem down ahead of time. Have someone else at your company read it. - Do the problem yourself. Ballpark your estimate for a great candidate at 3x the time it took you. - Tell them there is no penalty for using stack overflow over the language docs. - After you give them the problem, give them a few minutes in peace (leave the room) while they think it over. Talk about their approach out loud before they begin working. - Ask them to spend 5-10 minutes re-factoring their code once it's working.

spectre256 11y ago
That 3x to do it yourself time seems excessive, but we once did exactly the same thing at a previous company. We chose problems we knew, worked with tools we knew, in a comfortable environment. Even if you aren't intentionally trying to do the opposite, which unfortunately many interview techniques, like whiteboard coding effectively do, conducting interviews where a candidate is comfortable and at their best is ridiculously hard.
- stevepike 11y ago
  Agreed, but it's worth trying to do well. You get a lot of information out of how someone handles programming live vs. what you get in a homework assignment.
UnoriginalGuy 11y ago
I love your list. Full of great ideas for productive interviewing. I'd further expand this one: - Write the problem down ahead of time. Have someone else at your company read it. You also need to have someone else (not you) at the company complete the problem. Ideally have a "model employee" do it. If they are unable to "pass" your interview question (under near-interview conditions) then maybe the question is a bad indicator. Keep in mind that asking a co-worker to complete it is much lower stress/easier for them than a candidate, as they likely have near nothing on the line (maybe reputation). So if they find it hard, an interviewee will likely find it near impossible.
danieltillett 11y ago
This is a great list as you are using one of the proven interviewing processes that work - testing a candidates ability to preform the work they will be hired to do, not some proxy. The only difficulty I can see with letting the candidate use any language they like is some languages are inherently easier and faster than other languages to solve certain problem classes. This may make it hard to compare candidates.

spectre256 11y ago

That 3x to do it yourself time seems excessive, but we once did exactly the same thing at a previous company. We chose problems we knew, worked with tools we knew, in a comfortable environment. Even if you aren't intentionally trying to do the opposite, which unfortunately many interview techniques, like whiteboard coding effectively do, conducting interviews where a candidate is comfortable and at their best is ridiculously hard.

stevepike 11y ago
Agreed, but it's worth trying to do well. You get a lot of information out of how someone handles programming live vs. what you get in a homework assignment.

UnoriginalGuy 11y ago

I love your list. Full of great ideas for productive interviewing. I'd further expand this one: - Write the problem down ahead of time. Have someone else at your company read it. You also need to have someone else (not you) at the company complete the problem. Ideally have a "model employee" do it. If they are unable to "pass" your interview question (under near-interview conditions) then maybe the question is a bad indicator. Keep in mind that asking a co-worker to complete it is much lower stress/easier for them than a candidate, as they likely have near nothing on the line (maybe reputation). So if they find it hard, an interviewee will likely find it near impossible.

danieltillett 11y ago

This is a great list as you are using one of the proven interviewing processes that work - testing a candidates ability to preform the work they will be hired to do, not some proxy. The only difficulty I can see with letting the candidate use any language they like is some languages are inherently easier and faster than other languages to solve certain problem classes. This may make it hard to compare candidates.