[Retric]

Normal interviews are mostly a scripted performance where people largely regurgitate answers to predictable questions.

So the issue isn’t that it’s a stand up performance it’s that you need to split your attention between the performance and solving some trivial problem. Becoming really good at programming requires being able to focus on an actually difficult problem not work through a simplified example while entertaining an audience.

There might be a correlation between solving trivial problems quickly and being able to figure out a heisenbug from some multithreaded monstrosity, but it’s not strong enough for minor differences in performance to be meaningful.

[Ancapistani]

> Becoming really good at programming requires being able to focus on an actually difficult problem not work through a simplified example while entertaining an audience

There are multiple ways to "become really good at programming".

A company of any size needs people who can churn through well-defined problems quickly, and most live coding tests are relatively well-suited to selecting for that. They also need people who do other things well:

* tackle large, ill-defined problems, alone or in a small team * identify, triage, and (if necessary) solve problems as they emerge * refactor existing implementations that have outgrown their initial architecture * identify trends and estimate when they will lead to scaling issues in the future * communicate complex problems to people without the necessary context * break down complex solutions into discrete, well-defined steps that can be tracked to completion

They also need people who can accurately estimate how long all of the above will take... unfortunately, as we all know, such people do not exist.

If you're hiring someone to churn through well-defined problems, live coding interviews are likely a good fit out of the box. If you're hiring someone to reinforce a weakness in your organization's ability to do any of the other things above, live coding exercises are at best a loose framework that we're all familiar with to try to get at whether or not they have those skills.

[hnfong]

I'd even argue it's a prerequisite.

If one doesn't even know how to complete well-defined tasks reasonably quickly, I can't imagine how they would be able to break down complex tasks to these smaller, well-defined tasks, and accurately estimate the expected effort needed.

This sounds almost Dilbert-esque. It seems like a lot of people here want to be a pointy-haired boss (or pointy-haired tech lead)!

[Ancapistani]

> I'd even argue it's a prerequisite.

You can know how to do something without being able to consistently do it.

Maintaining velocity is something that I've never been very good at. I always struggled as a junior and mid-level developer with having periods of very high productivity followed by periods of very low. I've been fired for it.

On the other hand, if you measure my output on a monthly or quarter time horizon, I'm very consistently at the top of the class.

My strong suits are around helping others get through tough problems, quickly switching between levels of abstraction (including within a single conversation), understanding how a part of a process fits into the whole, and in guiding/limiting architectural discussions by managing the scope of the problem space under consideration.

This fits very well with my current "staff level" role, but was a real struggle getting to this point.

> This sounds almost Dilbert-esque. It seems like a lot of people here want to be a pointy-haired boss (or pointy-haired tech lead)!

I can see why you'd say that, but I think there's a big difference: PHB was incompetent in addition to having a different role from his team. I've found a sweet spot for myself where I can fill the parts of the "PHB role" well that actually do help the team, but I'm also more than capable of switching contexts and knocking out some tickets when there's a crunch. When I'm especially "in the flow" I work on that sort of stuff and do well. When I'm not, I run interference and keep my team from having to deal with the organizational stuff that doesn't directly help them get their jobs done.

The best functioning teams I've experienced all have one thing in common: they set people up for success by allowing them to do play to their strengths. As a team grows, you can find gaps in those strengths. I see hiring as an opportunity to find someone who is strong in the areas the team is weak. Let the new person come in and do the things they like to do and are good at!

[Retric]

Coming up with your own tasks means understanding the problem implicitly. Solving other peoples trivial problems means searching for the interviewer’s hidden gotchas and unspoken requirements.

Ie if someone asks you to find the median value of an array the number of elements and how to handle nulls isn’t obvious, but when you want the median value in an array the context is clear.

[hnfong]

> Normal interviews are mostly a scripted performance where people largely regurgitate answers to predictable questions.

Ah, so you prefer being asked "where do you see yourself in 5 years?", and regurgitating the text generated by ChatGPT instead?

Alternatively, as I replied in the sibling thread, do you prefer to be handed a difficult take home task that is expected to take 2 weeks to complete?

I think I can live with the first, but I'd be insane to work 80 hours on a task just for a small chance to get a job.

[Retric]

“Where do you see yourself in 5 years?” is asking a perfectly reasonable question about what if anything you’re working towards. If you think regurgitating something from ChatGPT is appropriate, I can see why you might prefer more limited interviews.