>It sounds like you might not be quite getting the concept behind this sort of interview. Although some code is written, this is (usually) a test of how you talk about code.

Assuming everything the GP said is true, what you're saying is completely contradicted by the fact that they were dinged for not using a null coalescing operator.

Well, yeah. But it may be that, when talking to a co-worker about something, they point out some programming syntax you weren't aware of, just as a way of trying to be helpful. What's a good way to handle it?

You could thank them for pointing it out, say you're not sure you want to use it (if you don't think it's better) and then get the conversation back on track. And, hopefully they'll think you handled it smoothly and won't take off points, but you'll never know how important it is to them that you're fluent in Swift. Maybe not at all, it's just an aside?

Which is to say, usually you can't tell in an interview what they're really grading you on. It's nerve-racking, but you just have to try to seem reasonable and hope that works.

Why not both. They want to hear you talk through the solution. And they have unhelpful biases about what they want to see in the solution.

Well... sure, why not? I was responding to this though

>It sounds like you might not be quite getting the concept behind this sort of interview. Although some code is written, this is (usually) a test of how you talk about code. You want to show that, if a co-worker asks for your advice on how to solve a tricky problem, you will be able to help them figure it out.

Yep, this is exactly what happened. The OP didn't stop to consider the purpose of the exercise or what the interviewer was trying to get out of it.

The details of the exercise aren't the point...and I'm sure the reason the interviewer likely gave off mixed signals about the extensive documentation is because time is limited and a good interviewer makes sure to keep the candidate on track so that there's enough time.

A binary tree is plausibly something a candidate would know, or could figure out without communicating at all. Apple picked possibly the worst problem if what you are describing was their goal, the ideal problem would be something that is unlikely to be known by any candidate. If their goal was to determine if the candidate could actually code, a binary tree probably asks too much (the ideal real-world solution is likely to just import a package).

Common data structures have no place in any type of interview.

I’ve seen this before. Very recently I saw a candidate rejected based only on the fact that they were rattled by a word-search problem (find words in a letter grid) on a whiteboarding test. It was frustrating to me, as I had seen this person’s production code at a previous job and witnessed them successfully working problems.

“I just can’t hire someone who fails this sort of problem”.

Given that this person was applying for a general backend position building foundational, framework derived features (mostly CRUD and some light analytics) it was confusing to me. There is literally zero application for graph traversal in their work. They will absolutely never encounter this sort of problem in the course of developing our software...which is b2b, targeted at industry experts: we build software that generates reports. Not even complex aggregates...just moving window averages and the like.

At this point in my career, after building more than one team/business I’ve learned that the shape of your technical interview loop informs not just the codebase you generate...but also your engineering culture.

I disagree. Expecting people to invent novel data structures on the fly, under stress, is unreasonable. Usually the idea is to ask a question they haven't actually seen, but is still somehow solvable using basic data structures most people learned in school, maybe with a minor tweak for the problem.

Otherwise, it's unlikely that most people will be able to solve it in 45 minutes, even with hints, and then you don't learn anything other than that they failed at an unreasonably hard problem.

So, one of the problem's solutions being a binary tree isn't itself necessarily a problem. The interview could be done well or badly depending on execution, and we can't judge that from afar. All we really know is that a binary tree was somehow involved.

---

At least, that's the idea. Interviewing is still terrible. It's pretty random to base a hiring decision on a few (extended) questions, and I think interviewers are left on their own too much to come up with good questions. How do we even know what's a good question or not?

Sometimes I wonder if it wouldn't be better to choose twice as many candidates as you need and pick half of them at random, just so everybody is clear that there's a lot of luck involved and they don't take either success or failure some kind of precise indicator of someone's worth.

> Expecting people to invent novel data structures on the fly, under stress, is unreasonable.

If that's the metric being measured, then sure, it's a bad idea.