3 ms·

> You can't know for sure that dad/friend/partner didn't write the assignment either. I don't follow what you're implying here, sorry? > How about a 4-5 hours

by newobj 8y ago

> You can't know for sure that dad/friend/partner didn't write the assignment either. I don't follow what you're implying here, sorry? > How about a 4-5 hours coding rush in the office, where you have to add a few functions or features to an existing codebase? I work at a company where we actively keep a small set of tasks groomed for new hires. It's extremely difficult to keep a set of meaningful actually-in-the-codebase problems groomed at all times and totally infeasible that the person will spend less than a day coming up to speed on the infrastructure etc. The overhead of doing that is really prohibitive from an interview perspective. I do think that for the most part, the coding problems need to be synthetic, then, not an active need in your codebase. I am definitely a believer in longer more open-ended coding challenges than 45 minute white board jams though.

trowawee 8y ago
The best option I've seen were recently-solved small problems. We would roll back a few commits, take that code into the room with the candidate, and pair-program a solution or partial solution in a fairly tightly-scoped time period, and then review the solution with another interviewer. That way, we've got an idea of what to work towards, usually still a pretty solid sense of where the problem exists in the context of the overall app, and we hit a couple of crucial skillsets - collaborating on a project, reviewing code. It wasn't perfect, but it worked reasonably well.
newobj 8y ago
to trowawee: if it works for you, by all means! my only objection would be if the company is benefiting from your work in some way.
- trowawee 8y ago
  I think that we "benefitted" in some sense, because interviewees sometimes came up with better ways to solve some of those problems. Generally, we extended offers to those people, tho. I think it's just a slightly easier approach than trying to develop useful synthetic challenges - I haven't really seen a synthetic challenge that felt like it accurately approximated what day-to-day life is like in a company, which as an interviewee I am most interested in.

by newobj 8y ago

trowawee 8y ago

The best option I've seen were recently-solved small problems. We would roll back a few commits, take that code into the room with the candidate, and pair-program a solution or partial solution in a fairly tightly-scoped time period, and then review the solution with another interviewer. That way, we've got an idea of what to work towards, usually still a pretty solid sense of where the problem exists in the context of the overall app, and we hit a couple of crucial skillsets - collaborating on a project, reviewing code. It wasn't perfect, but it worked reasonably well.

newobj 8y ago

to trowawee: if it works for you, by all means! my only objection would be if the company is benefiting from your work in some way.

trowawee 8y ago
I think that we "benefitted" in some sense, because interviewees sometimes came up with better ways to solve some of those problems. Generally, we extended offers to those people, tho. I think it's just a slightly easier approach than trying to develop useful synthetic challenges - I haven't really seen a synthetic challenge that felt like it accurately approximated what day-to-day life is like in a company, which as an interviewee I am most interested in.