| > How would you go about checking if somebody is qualified in an interview? It depends on the job, but for coding I've had great luck asking them to bring some code they were proud of in to the interview. Language doesn't matter, subject doesn't matter. And then in the interview I ask them to teach me how it works. It becomes apparent in no time if they don't know what they're doing (or stole it). And if they can tell me about it, I learn how well they understand their own system--do they only understand it well enough to code it, or do they understand it well enough to teach it? I also learn if they're a good communicator. And if they're a good culture fit. And if they're enthusiastic about coding. I can also ask probing questions about design decisions and shortcomings. That covers the "how well do they code" part, but falls a little short on the problem-solving part. But I can come up with on-the-fly questions (often about the code they brought in) that exercise those muscles. "What would you do if this data weren't available?" "What if you needed more guaranteed uptime?" "What if you needed to process 1000x more data in the same timeframe?" These are more relevant questions. I'm after someone who learns fast. I'll take someone who knows a little and learns fast over someone who knows a lot and learns slow 9/10 times. (Once I had someone bring in a device driver written in C for a JavaScript gig. They were hired. Another time we hired a dev with zero experience in the platform, language, or framework. Worked out great.) If they ace leetcode-style challenges, I know they're good at _that_, but I don't trust it as a proxy for the other things I want to know, above. |