4 ms·

> Take-home projects or a trial period of some kind. This makes the most intuitive sense by far: having candidates do a representative slice of the job gives yo

> Take-home projects or a trial period of some kind. This makes the most intuitive sense by far: having candidates do a representative slice of the job gives you a solid idea of whether they'd be any good at it. Combining this with structured interviews was (before AI) considered a gold standard; you'd get a sense of who they are and how they work by talking, have a way to compare them pretty objectively to other candidates because of the structured and consistent nature of the interview process, and then you'd get a sense of how they apply their attributes practically to the job via the work exercise. Unfortunately a lot of companies have over the last several years been using this to get candidates to do a project for free for them. If it's going to take more than a few hours of my time, I don't take project style interviews seriously unless compensation is added (which some companies do offer and is a big green flag). Definitely been tricked into working for free a time or two.

OkayPhysicist 4mo ago
Best middle ground I ever had was an interview where they impose a strict 1 hour (maybe it was 90 minutes, idk) time limit between when I got the prompt and when I emailed them back. Then they spent some time looking over it, then I had an interview with an engineer who had read my code and we chatted about it. Why I had made certain decisions, what corners were cut because of the time limit, etc. Felt very fair. Not enough time to assign a valuable task, enough time and privacy that I wasn't under the gun like you are in a whiteboard interview, and it was pretty applicable to what I would be doing at the company. Solid interview. Didn't get the job, but respected the process.
- JohnMakin 4mo ago
  This style works for me too. I don’t necessarily think the live coding interview is always the best presentation of what I know and some types of interviewers try to apply pressure in those situations I don’t feel is entirely fair, plus you’re often forced to use a third party webapp where it’s entirely out of the normal workstation flow I’d be more comfortable in (I use mostly text editors with plugins when allowed). there has been a proliferation of “take home” exercises that are them just trying to pick your brain for problems they’re struggling with. I have had a “take home” project that led to a trial contract employment that required me doing a ton of work for free I knew they had used later, because I saw the trial API key I had set up for the project used much later on down the line. Never got paid, clearly work was stolen, not much you can do about it and there’s a real power imbalance there that’s difficult to really do much about. Was a tough lesson. When done right I think it’s the best way to screen for good candidates that may not be good live coding interviewers. I do take the position that like, I get why you may have a culture where live pair programming in high pressure situations may be valued. But in most orgs the async nature of -> get requirement -> implement asynchronously -> seek feedback and adjustments -> iterate is far more realistic, but when you deliver something, never hear back, get hit with the whole “we’re going with another candidate” feedback feels like you just got ripped off.

OkayPhysicist 4mo ago

Best middle ground I ever had was an interview where they impose a strict 1 hour (maybe it was 90 minutes, idk) time limit between when I got the prompt and when I emailed them back. Then they spent some time looking over it, then I had an interview with an engineer who had read my code and we chatted about it. Why I had made certain decisions, what corners were cut because of the time limit, etc. Felt very fair. Not enough time to assign a valuable task, enough time and privacy that I wasn't under the gun like you are in a whiteboard interview, and it was pretty applicable to what I would be doing at the company. Solid interview. Didn't get the job, but respected the process.

JohnMakin 4mo ago
This style works for me too. I don’t necessarily think the live coding interview is always the best presentation of what I know and some types of interviewers try to apply pressure in those situations I don’t feel is entirely fair, plus you’re often forced to use a third party webapp where it’s entirely out of the normal workstation flow I’d be more comfortable in (I use mostly text editors with plugins when allowed). there has been a proliferation of “take home” exercises that are them just trying to pick your brain for problems they’re struggling with. I have had a “take home” project that led to a trial contract employment that required me doing a ton of work for free I knew they had used later, because I saw the trial API key I had set up for the project used much later on down the line. Never got paid, clearly work was stolen, not much you can do about it and there’s a real power imbalance there that’s difficult to really do much about. Was a tough lesson. When done right I think it’s the best way to screen for good candidates that may not be good live coding interviewers. I do take the position that like, I get why you may have a culture where live pair programming in high pressure situations may be valued. But in most orgs the async nature of -> get requirement -> implement asynchronously -> seek feedback and adjustments -> iterate is far more realistic, but when you deliver something, never hear back, get hit with the whole “we’re going with another candidate” feedback feels like you just got ripped off.