3 ms·

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 whe

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.

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.