As a younger developer I was part of a 3 person team that was interviewing people at a telecom. I mostly kept quiet and observed since it was the first time I'd done this but we had one member of the team who was bent on trying to show how smart he was.

My absolute favorite interview of the group, a guy who ended up getting hired elsewhere, was the most calm and professional developer I'd ever been around. Sitting in the room, I felt like he was interviewing us rather than the other way around. It was just in the way that he carried himself, answered questions.

And then the guy on our team started asking questions. The gentleman we were interviewing, rather than answer, kept calmly asking more questions of him instead.

- Can you describe the situation where this would be used?

No

- Have you ever run into an issue like this before that could be an example?

No

- How do I know that by solving this problem we would be addressing the business or customer problem?

We don't

- Then shouldn't I be solving questions related to the work?

...

I loved that guy. Wish we could have hired him because I really wanted to work with him.

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.

Good call on the dice roll. Spent months prepping for the FB interview and got an engineer who seemed to be having a bad day or was just bored. I knew both problems but they derailed me on whether you can uniquely identify objects in JS with no additional id assigned. I told them you can’t as there’s no pointers or memory addresses in JS. They didn’t believe me and literally spent multiple minutes googling things to prove me wrong. And then rejected me after I still finished the second problem in the 7 minutes remaining. Nevermind they were looking at their phone multiple times during the interview lol

Demoralizing as all hell. Thankfully I had multiple mocks with FB engineers who told me I did great so I know it really was just bad luck that the real phone screen was a dud.

Ugh, that's terrible. I had a similar situation when I started interviewing after my startup failed. It was with a major energy company for an Angular developer role. The interviews were going really well until the final interview when they asked me to do some live coding. This led to a 15 minute discussion about 5 minutes into the session about whether JS had while loops. The developer testing me was absolutely convinced that JS had no while or do/while loops and refused to move on from that point. Their loss.

People who interview like that should be fired. The damage to the company in missing a good hire and blighting the company's reputation is cause.

It amazes me more people don't see this. Virgin in the UK looked into the data and found a bad candidate experience was significantly impacting their bottom line, just in actual candidates cancelling their service within 30 days of a bad candidate experience.

They didn't even need to look at word of mouth impact to see a material hit on their customer retention, in a sector where churn is costly. They went on a crusade to improve, and now find candidates for jobs are net promoters, and their customer acquisition cost via candidates is lower than normal advertising(!)

I think some of the big tech companies simply don't care about their reputation at either micro or macro level, and nobody wants to call out that kind of toxic behaviour as they're all "part of the club".

This is actually a big thing we invest in at my current company: candidate experience and consequently a high Glassdoor rating. After focusing on it for years the company has one of the top ratings on Glassdoor (top 100 or 200 I forget). It’s a big differentiator when you’re not a big company and not a recognized brand. I think for FAANG companies they can get away with it because despite a poor experience, the actual job and pay/perks they offer are extremely desirable. Sad because, like you say, it’s not hard to see and make an impact on improving.

In my experience Glassdoor doesn’t mean shit. The single most dysfunctional, toxic work environment I’ve ever been in had - and still has - a high (>4) rating on Glassdoor. I won’t get into details but I was miserable and left after two months. They said all the right things during the interview but the reality was vastly different. The non-disparagement clause I had to sign on my way out was the icing on the cake. No wonder they have such a high rating if you’re not allowed to be honest about your experience.

At an employer prior to that, I saw first hand how companies were able to get negative but true reviews taken down almost as soon as they were posted. There was high turnover at that place and a lot of people were truthful in their reviews of the company. The Glassdoor rating was far higher than they deserved until they went under.

Im short, I’m sure you think you’ve got a great work environment, but I’ve been burned by bullshit Glassdoor reviews and I doubt I’m the only one.

That’s fair. It’s a metric so it doesn’t surprise me that it’s game-able like others. I guess as a candidate you have to use it as one data point. It’s tough because even interviewing as a candidate and asking lots of culture questions you only get, what, like 20 mns of questions answered? Before you commit to 40 hours a week? Sorry to hear you got burned. Toxic work environments are such a drain on life.

Well on the opposite side of the table are the people who start arguing with me during the interview (and twice even after the interview).

I generally try to help everyone as much as I can during interviews, because honestly this is taking time away from my other work and I'd nothing better than to hire you, but sometimes it's just to much.

Sometimes interviews are just part of “following the process” when someone who knows someone is going to get the job anyway, but still they have to follow the process so everything looks normal. These things are not so cut and dry and objective as you would like to believe. I wouldn’t sweat it.

That's a bugger :/ Regarding uniquely identifying objects, if we can compare objects by reference, doesn't it count as unique identifying? E.g. let a = { }; let a2 = a; let b = { }; a === a2, but b !== a2 .

In this case it was a problem about creating a deep copy of nodes in a graph. My “easy” approach involved using a map with the key being a reference to the original A and the value being the copy A* OR adding matching ids to A and A* and use a map to go from A to A*. They said no mutations to the original objects (ids are out the window) and then that led to the quibbling over addresses because you can’t use an object reference as a key in a map in JS (it’ll just stringify it in the map).

(I’m half hoping that after typing this out someone will reply with some data structure I’m unaware of that would allow you to uniquely map the reference of an object to an arbitrary value.)

My beef with the leetcode interviews is that, IMO, they're in no way reflective of what you're actually going to do, and yet the interviewer often acts like it's a perfect barometer. One misstep or quibble and you're out.

I remember when a former colleague wanted my input on his interview question which was basically, "Write the algorithm for product recommendations." (eg, like Netflix's movie recommender.) Despite repeated warnings, he went ahead with that question only to come back and admit, "Yeah, that wasn't at all good." Imagine what the poor guy or gal on the other side of the table had to go through.

I don't know what the right answer is to interviewing, but my take is that I would prefer to work with someone who I can get along with, have real human conversations, and become good collaborators -- even if they're not ace coders. That measurement seems glaringly missing from too many interviews.

I've consulted with quite a few companies on their interview process. Almost all of them had adopted Leetcode style interviews. My first question to the team always is: what exactly are you evaluating when you interview someone?

And I rarely get an answer that makes sense. Instead I get mostly rationalizations for Leetcode. The thing is I recognize those rationalizations because I was certainly guilty of it in the past ("We're evaluating intellectual curiosity" is one I cringe at now).

The real problem from my perspective is that most teams have never taken the time to really think about and identify the underlying principles about how they want to work. We go through a process of defining those principles and all of a sudden the interview gets a lot clearer. Do you value the highest quality code? Do you value getting things into the world quickly and then iterate towards the final solution? Is security always at the front of your mind?

Getting really specific about what exactly being "excellent" means to a team is really critical.

Because then you can design an interview process that actually selects for those things. I've never had a team define "the ability to solve leetcode problems under pressure quickly" as an endpoint they actually care about. Some teams continue to use leetcode, but only as a small part of the process with problems that ARE actually directed at what they care about. Having been through a bunch of interviews in my 25 year career I instantly know when a team has actually done the work to design a good interview process (which has been far too rare in my experience).

My company has an incredibly detailed rubric for what is meant to be evaluated. It still sucks.

It’s hard to admit that they don’t actually know how to evaluate people well and instead implement an absurd level of inefficient gatekeeping. The same reason some jobs only hire people with degrees even if it’s not necessary or the degree is irrelevant.

It's not just that they don't know how to evaluate: often they don't even know what they are looking for.

Yes! This is exactly it. Very few teams that I've worked with had actually defined what is even important to them.

Leetcode interviews don't test if you're a good software developer, they test whether you're capable of becoming a good developer. The skills required to succeed at leetcode basically come down to 1. willing to spend 100 hours studying/practicing 2. Baseline critical thinking skills. Throw in some behavioral to make sure they can communicate and those are basically the skills needed to become a decent developer.

That actually sounds like quite an interesting and fun interview question, why did it go so badly?

Wasn't there also an issue with companies trying to interview people and asking them questions like that, not as a way to hire anyone but as a free way to get smart people to solve some of their software problems?

or trying to glean proprietary information out of others?

> Wasn't there also an issue with companies trying to interview people and asking them questions like that, not as a way to hire anyone but as a free way to get smart people to solve some of their software problems?

It's a struggle between fitting the interview to real-world situations vs making it seem like the candidate is doing work for the company.

I feel like a good situation might be actual problems previously encountered with the technology being assessed during the interview that would've required you to have collaborated with someone who is also experienced in that technology to help you solve them.

Maybe the best way to do this is when the situation is proposed to the candidate, make it clear that the answer is already known and put it in an envelope (physical or digital), which will be referred to when it's solved or the candidate hits a dead-end.

I don't think anyone cares if you can actually solve the problem. They are looking to see how you perform under pressure (not because the job is necessarily stressful, but because we can learn a lot about a person's true personality when they are under pressure), how good you are at problem solving, whether you actually know anything about coding or are just BSing, etc.

Different people will experience different levels of pressure. Interview pressure is not the same as deadline or project pressure

"but because we can learn a lot about a person's true personality when they are under pressure"

Do you have a source for this? I can't help but think about the person in this clip: https://www.youtube.com/watch?v=LlCEmPF4-V0. You think you can learn much about her from that interaction?

This is such a perfect distillation of the problem.

Just being IN the interview to begin with is likely to be higher pressure than any sane or sustainable working environment would be.

I've interviewed people who didn't know the answer to some of these tech questions, and honestly, I was more impressed by them calming saying "I'm not sure on this one, I would probably need to go look it up".

I used to be quite stressed-out by job interviews, until I realised a small crucial thing... If you're interviewing while employed (which, to be fair, is not a luxury everyone has), the absolute WORST outcome of that interview is "I am given an offer".

Why worst? If you're not given an offer, nothing changes. You've spent somewhere between 45 minutes and a day, got some interview practice and all is basically status quo. But, if you're given an offer, you are now faced with having to weigh the pros and cons of accepting it.

This is the ideal, and the original point of such questions (I was at a FAANG and interviewing candidates when they started becoming popular), but the inevitable result is that the test becomes interpreted more literally as it becomes more common.

While what you say is the ideal situation, I think being able to get the optimal solution and giving at least a halfway decent explanation about why it works is the #1 most important thing (along with just plain old not being a jerk).

I acknowledge there are some situations where you might pass the interview even without arriving at the optimal solution, but those are probably the exceptions.

But, why? I've never seen one of these questions that mimics an actual real world work problem.

When I'll be preparing for the next interview rounds in my career, I'll make note of some problems that are both short/easy to explain, and have really interesting optimisations that are almost impossible to come up with on the spot (unless you've done a lot of similar stuff or that exact problem before). Then, when the interview is (nearly) over and it's my time to ask the interviewers something, I'll drop one of those in their lap to see how they react, and if they can come up with something that's not laughably stupid/inefficient. My point being that, if they're not capable of solving problems like that under intense time pressure, they're not up to the task of interviewing someone else on them. If they do give a good response, kudos to them, I'll be impressed.

Though I think my expectation is that they'll get annoyed and stop the "interview".

If you did this to me during an interview, I would try as best as I could to give you an answer in the 5 or so minutes left of the interview. Then, in my feedback, I would strongly recommend not hiring you as a bad personality fit.

I also don't really ask "trick" questions (I try to select questions based on what the CV indicates would be a strong area for the specific candidate), the closest I get to that is probably when it comes to service monitoring (where the exact final answer is less interesting than the process of getting there).

> I also don't really ask "trick" questions

My reply was only intended for "trick" questions that have absolutely no relevance for the day to day job of 99% of Software Engineers. And that's exactly because those trick questions tend to be more about the "exact final answer" than about the process, so my point was about figuring out if the interviewer actually has a grasp of those sort of problems in general or if they memorised a good solution and are milking that for all it's worth.

And I do know that almost any interviewer would reject me based on that, but I think it's worth letting them feel the burn they try to inflict themselves.

Yup... it’s like asking your doctor to draw the Krebs cycle from memory.

Right, but you can't become a doctor without spending many thousands of hours and hundreds of thousands of dollars gaining credentials. But you can become a highly compensated software engineer by spending a miserable day answering pointless questions on a whiteboard. I would personally prefer the credentialing approach because at this point it would be easy for me to get the credentials. But the low barrier to entry also has advantages.

For that matter, I'm not sure that the way medical education is done is something to aspire to. Years and years of exhausting sleepless tedious grind, at the expense of any instruction on deductive thinking or bedside manner; if at the end of it all they can't even draw the Krebs cycle from memory, then what the hell is the point?

Ha! My hobby is pharmacology and I’m always having to refresh myself on various steps of Krebs. We need a Ninja Nerd[0] for CS I guess, I’ve found it incredible.

[0] https://youtu.be/rr7IRYLqleg

> interviews are hard in that they have absolutely nothing to do with your day-to-day job

I often wonder why this is legal, especially given the legal concept of disparate impact. It's basically just a disguised test of some combo of IQ + free time + willingness to grind dubiously useful information

I think it's only a matter of time until the extreme disparity between the candidates that pass this filter (mostly white and asian men below age 35) vs the applicant pool is used in a legal challenge about whether these tests are really looking for bona fide occupational requirements.

Because any software person will tell you these tests are extremely detached from the requirements of the job.

It seems like it would be an open and shut case if not for the army of lawyers employed by the likes of Google.

I think such a challenge would fail in any reasonable legal system. HN seems to be talking itself into a belief that these interviews have no relationship to actual programming work, but that's not the case and plenty of experienced engineers would step up to defend algorithmic questions if it ever moved beyond bellyaching in blog posts.

Of course the USA is ever more extreme and crazy when it comes to identity politics, so ago knows if the justice system is still reasonable in this regard. But I'd really enjoy watching people argue in front of a judge that working with tree structures is extremely irrelevant to programming.

There's some truth to this, but it's also true that when someone with many years of experience and a long history of top performance ratings and promotions has to take a week or two off to study in order to do the test, that it indicates the test is not well targeted to the job.

I find this interesting, because I feel every time I visit a Silicon Valley tech company’s office, I’m surprised by how diverse the employees working there are. Yes I know certain groups are still more represented than others.

But it’s still more diverse in contrast to the companies I’ve worked at (non-tech old school companies in finance, etc), where the tech employees tend to fall into a much narrower stereotype.

TBH, pointless questions in interviews is not exclusive to programmer interviews.

Pretty much any white collar job interview is an intellectual joust at best, and a mild hazing ritual at worst.

We actually have it good: you at least know what the broad contours of what we'll be subjected to.

> I often wonder why this is legal, especially given the legal concept of disparate impact

“Not yet challenged” and “legal” aren’t exactly the same thing. Straight up IQ tests are probably more defensoble than leetcode for lots of positions for which leetcode interviews are used. But people have heard the popular misrepresentation of Duke Energy (“it’s illegal to use IQ tests”) more than they’ve heard the actual disparate impact rule, and that seems to be true on both sides of thr interview table.

Regarding getting a "bad" interviewer - what makes this worse is you're rolling the dice multiple times.

I've had several interviews where everything seemed to go well, but one (out of say, 4/5) interviewer just seemed to be hostile from the moment they walk into the room.