Thanks for writing and posting this article. Technical interviews are one of the more essential topics in our field right now, and I do think 1) they're badly handled, and 2) difficult to get right.<p>A couple of thoughts on two points raised here:<p>1) Pressure to accept an offer. I may have lost out on an offer from a promising company by asking for a decision too quickly, and I did this because I was under pressure to accept a different offer. I believe the company's policy is that 1) they'll never rush their own decision to make an offer and 2) they'll never rush a candidate to accept. They figure that if they want to hire you, that won't change a month from now.<p>This position has a lot of integrity, but it does come from a position of great stability. Small companies may have only enough funding for one position, and they're terrified that by waiting for a strong candidate who is unlikely to accept, they'll lose out on another excellent candidate. The company I applied to was well established and well funded enough that they could hire anyone they felt was an excellent candidate. They were, in short, always recruiting, never desperately. The scenario I can't really respect is the company that takes weeks or longer about getting to an offer and then wants an answer in 3 days. I suspect that it's always usually best to pass on a company that is so desperate it needs to do this.<p>2) Not enough clarity about your role, and underprepared interviewers.<p>I think this can result from the "always recruiting" mentality. When it's tough to hire, and you have the money to hire, it really becomes about finding people when you find them. Companies are less concerned about exactly how to use a new hire, they're more concerned about finding someone they believe can make a strong contribution. As a result, they don't really hire for a specific role. Now, this is understandable as a motivation, but it leads to interview that are bewildering to a candidate. I've had full day whiteboard interviews covering data structures, SQL, and math, but without having read the company's website in advance, I'd be damned if I knew what they did, at all. That just can't happen. It shouldn't be possible for a candidate to go through an entire day of draining exam style interviews and not have the faintest idea what the company does. Even my interview at Google, which was very whiteboard-examish, the interviewers still took the time to explain what they work on before saying "so, suppose the search space were no longer rectangular or convex, how would you modify your code to find all matrices with positive determinants".<p>They aren't thinking about a role, they're thinking that if you can solve difficult code/math problems at the whiteboard, present and explain your ideas clearly, and seem professional in your interactions with people, they'll find something worthwhile for you to do (or, perhaps, they have confidence you'll find something worthwhile to do). It does make a certain amount of sense, but it leaves the candidate in the dark, and I don't want to join a company where my only interactions have been algorithm and data science questions at a whiteboard.