3 ms·

Try walking in the employer's shoes: "can this person learn what we need them to learn?" is notoriously difficult to assess. While the risk of making a bad hire

by Radim 8y ago

Try walking in the employer's shoes: "can this person learn what we need them to learn?" is notoriously difficult to assess. While the risk of making a bad hire is tremendous (deadly for smaller companies), the upside's lukewarm (hypothetical loyalty). The only safe way to see if a person can do the job, is for them to do the job, pretty much. I'm speaking from painful experience: we also used to hire based on potential. Bad idea (or we just couldn't make it work). Our hiring process is now very close to the actual job, whether the position is junior or senior, and although it can take weeks (a test project), "I could learn this later" doesn't cut it. Too many scars, not enough resources.

Humdeee 8y ago
A multiple week long project as part of your interview process for assessing candidates? Genuinely curious, what makes this a better process than others? I don't have a solution, but I imagine the majority top half of applicants will not even bother applying.
nikofeyn 8y ago
i am not advocating hiring purely on potential. and of course i view it from the employer's point of view as well. you simply can't hire well if you ask what amounts to puzzle questions in interviews. it doesn't address what a person does know. so in my opinion, an interview should be about finding out what a person knows, and in the event that it doesn't overlap with what the employer true needs, then some extrapolation or further digging is needed. however, even when a person's skills do overlap with the needs (whether the employer knows or it or not), it is my opinion that much of the overlap is often ignored (architecture, organization, perspective, personality, design skills, api philosophy) in favor of the more "hardcore" stuff (algorithms, data structures). we all know that even in the with the most efficient algorithms, software can be a mess if employees lack the former qualities. but software that is well designed can get away with less efficient algorithms except in extreme cases and niche contexts. tbe problems faced in a software company are rarely of the form "tell me the big-O behavior of this algorithm". rather, it's much more about how to manage large amounts of complexity, reducing complexity, designing flexible architectures, well-defined APIs, etc.

by Radim 8y ago

Humdeee 8y ago

A multiple week long project as part of your interview process for assessing candidates? Genuinely curious, what makes this a better process than others? I don't have a solution, but I imagine the majority top half of applicants will not even bother applying.

nikofeyn 8y ago

i am not advocating hiring purely on potential. and of course i view it from the employer's point of view as well. you simply can't hire well if you ask what amounts to puzzle questions in interviews. it doesn't address what a person does know. so in my opinion, an interview should be about finding out what a person knows, and in the event that it doesn't overlap with what the employer true needs, then some extrapolation or further digging is needed. however, even when a person's skills do overlap with the needs (whether the employer knows or it or not), it is my opinion that much of the overlap is often ignored (architecture, organization, perspective, personality, design skills, api philosophy) in favor of the more "hardcore" stuff (algorithms, data structures). we all know that even in the with the most efficient algorithms, software can be a mess if employees lack the former qualities. but software that is well designed can get away with less efficient algorithms except in extreme cases and niche contexts. tbe problems faced in a software company are rarely of the form "tell me the big-O behavior of this algorithm". rather, it's much more about how to manage large amounts of complexity, reducing complexity, designing flexible architectures, well-defined APIs, etc.