2 ms·

> Some people lie on their resumés. My point isn't that I want to only chat about my resume - just that the problem you give me should be something I may encou

> Some people lie on their resumés. My point isn't that I want to only chat about my resume - just that the problem you give me should be something I may encounter in the new job, ergo I do not need to prepare for that since my entire career prepared me for those (unless I want to reskill and the new job is different than the old one, then some preparation may be warranted). > If they're able to deliver working code of some kind under the pressure of a job interview, then they're almost certainly about to actually program at least a little, so you can trust me of what you see in their background and what they tell you about their achievements. Sure! But if the assignment is depending on stumbling upon a brilliant idea, instead of solving a problem that you may see in your day-to-day job, then I don't think it's useful. Think "trim a string" or "split a CSV" [1], not "find the longest increasing subsequence". And maybe also explicitly stick to ASCII encoding for string-based problems (but TBH, if a candidate asks about encoding, they probably know their stuff, or at least know where the gotchas are)... > I'm personally skeptical that leetcode really tests what most companies need in a programmer, but it's probably better than nothing. Agree that it's better than nothing. Disagree that we can't do better. :) Edit: [1] ... maybe w/o relying too much on standard library if those are built into the language you chose.

NateEag 4y ago
Yep, that all makes sense. FWIW, I agree we can do better than leetcode. I'm personally a fan of an approach I saw someone else describe here, where you literally have the candidate do a few-hours freelance gig for you, paid at a decent rate. Triage some of the low-priority bugs so when you're interviewing you have a little stack of relatively self-contained, well-defined tasks for candidates to pick from. Probably good to have someone pair with them, if the candidate is willing. You get to see them work in a real context, they get paid, you can learn about how they work, and it seems like a win-win to me. I also think it's good to be open to other options - if a candidate has a different way to show they'll be good at the job, let them do that. If burntsushi wanted to work on a company's CLI tools, I'd hope a link to the rg repo would satisfy everyone that he knows how to write a good CLI.

NateEag 4y ago

Yep, that all makes sense. FWIW, I agree we can do better than leetcode. I'm personally a fan of an approach I saw someone else describe here, where you literally have the candidate do a few-hours freelance gig for you, paid at a decent rate. Triage some of the low-priority bugs so when you're interviewing you have a little stack of relatively self-contained, well-defined tasks for candidates to pick from. Probably good to have someone pair with them, if the candidate is willing. You get to see them work in a real context, they get paid, you can learn about how they work, and it seems like a win-win to me. I also think it's good to be open to other options - if a candidate has a different way to show they'll be good at the job, let them do that. If burntsushi wanted to work on a company's CLI tools, I'd hope a link to the rg repo would satisfy everyone that he knows how to write a good CLI.