3 ms·
This is a pretty linkbaity oversimplification. It's designed to appeal to the belief that there's a "magic bullet" for everything. Hiring people via interviews
by jxf 13y ago
This is a pretty linkbaity oversimplification. It's designed to appeal to the belief that there's a "magic bullet" for everything.
Hiring people via interviews is hard, because evaluating people with limited time and context is hard. There's no such thing as a question that will tell you everything.
If you're really trying to get an accurate picture of a candidate, conduct an accurate simulation. Get away from interviews as the only means of evaluating someone, and use something that more closely approximates the actual conditions under which they'll be working.
Maybe that's a probationary period where you pay them at contractor rates, or maybe you pay them to make a bugfix to an open-source project that you depend on, or whatever. Asking questions can tell you a lot about how a person thinks and works, but it's never a substitute for the real thing.
- darkxanthos 13y agoI don't see an oversimplification here. If a programmer, business person, whoever cant answer that question well I can definitely see how they might not be the kind of person I want to work with.
- kelseyfrancis 13y agoAn answer to that question is necessary but not sufficient.
- AaronBBrown 13y agoI read this a lot here about probationary or trial periods and I agree that it's a great idea, in principle. However, the reality of the developer and system engineer ecosystem right now is that it's an employee's market. Good people are already employed and probably get a couple job leads every day via professional contacts, LinkedIn, or other channels. Those people aren't going to be willing to jump through these kinds of hoops, quit their day job, or generally want to deal with putting this much effort into an uncertain outcome when there are so many lower friction and equally rewarding positions. I realize that I'm generalizing and that you may be able to come up with a few anecdotes to make your point, but no one I know would deal with this. This might be a great way of hiring college interns or people trying to break into the technology field, but not practical for hiring established or senior positions. I like your idea about contributing to some open source project (paid), though even in that case, you will likely run into qualified people who are unwilling (or legally unable) to do this and as an interviewer, you need to be careful not to exclude those individuals.
- danielweber 13y agoNot everyone lives in a top 5 city where there are multiple job offers coming in every day. I used to think "what a big hassle" about those companies that would make you work a contract basis at first. But after several months of thought, I realized, "hey, if I were to suddenly lose my job, it would dramatically reduce my life-stress if I knew there were a few companies out there that the unemployed could excel at apply for, and that would provide me some income while I was looking for jobs."
- AaronBBrown 13y agoFor reference, I live in a small town along the Hudson River on the edge of the Adirondack Mountains in upstate NY, but have worked for Boston and NYC startups for some time now. So, not living near a top 5 city doesn't really have any bearing on the conversation. I agree that long-term contract-to-hire is a reasonable way to go for may employers and employees, particularly folks that already are already contractors, but the premise of "you've got a couple weeks to prove yourself" is a non-starter. I'm not going to quit my day job and risk my family's financial security for a company that is unwilling to take a similar risk on me. In an ideal world, it is the best way to evaluate a candidate. However, if it were practical, it would have already become an industry practice. The fact that it seems to be rare indicates to me that it does not work very well. As a Systems Engineer, a practice that I would like to see more of (and may try to implement at the company I work for) is a brief troubleshooting exercise with a shared tmux session. Set up a server with some problem and ask the candidate to identify the issue and try to resolve it.