|
|
|
|
|
by garyjlin
1565 days ago
|
|
I wouldn't necessarily put it that way, primarily because some of our interviews require less than 20 lines of code! It's a bit more about selecting candidates with the right fundamentals. You don't need to write too much code, but the code that you do write, is it clean? Are you following best practices? Is it efficient? Have you thought about how your new service affects the rest of the system, and what the implications are? I do agree though that some of our frontend interviews are a bit heavier on code + css and less on systems design thinking. Btw just to clarify, we have a policy where we won't host any interviews that are just open dev tickets to build a feature that will be used in production. Like, we DO NOT tolerate companies using interviews to get free labor. |
|
What does that change from a candidate perspective? In both cases the candidate wastes their time. I'd offer a better solution: the company pays market rate for the time needed for the test, and can then ask for anything they want - in which case an actual ticket is the best solution as it will evaluate the candidate's performance on the kinds of problems they'd actually be working day-to-day.