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.
