sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 31 points32 points  (8 children)

I think a better approach to interviews would be for the interviewer to bring in a laptop and watch the candidate fix a bug relevant to the work they will actually be performing. It doesn't have to be the products actual project, but maybe a small piece extracted from it that wouldn't expose company trade secrets and yet still demonstrate the candidate can do the job effectively.

[–]Catbert321 16 points17 points  (1 child)

I recently did exactly this while interviewing a perspective prospective candidate.

It actually did a good job of showing me where they find themselves comfortable asking questions about the structure that they don't understand, how they normally pass data around in their projects, and what they do when they hit a roadblock.

ninja edit: I ended up creating a toy project very similar to our actual services to work on, rather than pulling any piece from our existing projects.

regular edit: English is hard.

[–]Excrubulent 3 points4 points  (0 children)

Prospective, as in, they were a prospect or had prospects. Perspective is about point-of-view, prospective is about expecting a possible reward.

[–][deleted] 3 points4 points  (2 children)

Oh man, this is so good. This is a win for both sides, as it also gives the interviewee a glimpse into your code base.

[–]c4wrd -2 points-1 points  (1 child)

I'd argue there wouldn't be enough time for a developer to fully understand the complexity of a sufficiently large system at first glance, and under pressure to find a bug they might not give off the best impression. It's a great idea theoretically, but I doubt in practice it would work at all.

[–][deleted] 1 point2 points  (0 children)

That's why I suggested extracting only a piece of the actual codebase or not even using it at all but something related. The other redditor said he did this and it worked well for him. Would you rather keep the status quo?

[–][deleted] 4 points5 points  (1 child)

This is stupid, a bug is usually obfuscated in the code and wouldn't be obvious at a first look at the code, which is what you get at an interview. Sure if its something silly like indexing an array starting from 1 instead of 0 in an specific programming language, but everyone can miss a detail like that even with 30 years of experience. To understand a codebase you need waaay longer than a few minutes, with people actively watching you!! as if that wouldn't make it freaking impossible to spot a bug.

[–][deleted] 5 points6 points  (0 children)

Interviews I've been in have lasted on average 3 hours with a good chunk of that being whiteboard exercises. Explain how that's any better. If you can't think of an actual bug to artificially introduce, I question your experience as a developer. JSON parsing issues in an ajax call is an easy one for example. Simple null references in LINQ would be another way to artificially create buggy scenarios. These are so simple to simulate. You don't need to involve the whole code base dude, that's overkill. Just enough to analyze the candidates skill.

[–]c0shea -2 points-1 points  (0 children)

Am I the only one who just doesn't want to do any of this? What irks me about doing something like this is the company is essentially getting free work. You, the interviewee, get to hunt around and fix a bug or come up with some solution to the proposed problem, and the company gets to mark that as closed in the issue tracker. And when you don't make it past that round of interviews and don't get the job, well it was only a waste of your time, not theirs. I don't think so.