I try to use problems that I encountered and solved during my daily work in my interviews, and generally the experience is better for both me and the candidate when the problem is more relevant.

Many interviewers don't do this because it's often difficult to distill the most interesting problems down to something that would fit within the time allotted for the interview, and also there are candidates who prefer abstract textbook-style problems.

Yeah all my most interesting problems are solved by carefully reading logs and the code that wrote them, stepping through code in a debugger, working on small repros, and eventually hitting some eureka, often after a couple days of dedicated effort. This would be a poor interview technique, though it would have great signal.

A web startup I joined years ago hired this way. The "main" technical interview was pairing with one of the devs to fix a toy broken service. In my case, this went fullstack from client bugs to backend bugs to sql/orm bugs as well as "make a page to show a list of things". They weren't so formal as to have a coded up modular interview system or anything, but I always enjoyed that one the most because it was closest to the job.

Amazon calls that the STAR method, Situation, Task, Action, Result. Combined with real world experience / examples can be powerful during interviews. Especially during interviews with people not knowing this method.

So he was a no hire? "Poor cultural fit", I'm guessing?

I stopped an interview once. I told the guy I didn't think I'd be a good fit for the organization, and maybe we should save ourselves some time.

> I stopped an interview once. I told the guy I didn't think I'd be a good fit for the organization, and maybe we should save ourselves some time.

I've done this a few times, each time from a startup that reached out to me asking me if I'd come in to talk to them, and then would throw me into their coding challenges immediately. Like whoa hold on there, I don't even know what you do, why are you asking me to do a coding challenge before we've even figured out if there is a fit for me technically and I figure out what it is you're trying to solve.

I once passed some take-home test from a small startup. They then requested a further take-home which a) would be monitored (it was a remote position) and b) would require some six to eight hours and c) would have to be done over the weekend. There had been no contact with anyone at that point other than passing the initial test, and no discussion of salary, benefits, etc.

I've rarely used unprofessional language in job application emails, but on that occasion I pretty much told them to take their no-name little company and shove it.

This seems to be another example of the trend to AI based hiring, where the candidate interacts with zero humans until they have invested a huge amount of time and energy[0]. Good on you for telling them off.

[0] https://www.asktheheadhunter.com/15129/before-you-risk-your-...

Oh no, he was our top choice by the end of it but already had something else by the time we got the offer out.

I asked some of my interviewers, who had been around their companies for a while, if the interviews were as tough when they got hired, I think a few said said no it was easier, and iirc one said when they got hired they just shot the shit for a while and got hired right away, but he joined before the company was acquired by a FANG.