3 ms·
> ...should be absolutely riddled with errors. Same applies to code in an interview; it should have syntax, efficiency, correctness errors and more.
by emmelaich 7y ago
> ...should be absolutely riddled with errors.
Same applies to code in an interview; it should have syntax, efficiency, correctness errors and more.
- analog31 7y agoYou should use your own production code. This will kill two birds with one stone: Does the candidate know how to read code? Is your production code readable?
- nocturnial 7y agoI very strongly disagree with this approach. Suppose a candidate identifies a crucial flaw in your production code but for some reason the hiring negotiations breaks down and can't hire them. What happens next? Do you compensate the candidate for the time and effort to improve your code base? The interview process shouldn't be a free code review. I like your idea of testing if they could work with your code base. I just think there are better ways to test for this without getting into potential predatory actions. The only way I see how this could work is that you say: "You'll either get hired or we pay you a bug bounty of X amount". I might be too cynical but good luck on convincing the higher ups there's a small chance they need to pay candidates if they did extremely well in the interview process because it's "only fair and they did the work".