[koala_man]

What's the pain point? The stress of being observed? Getting started? The difficulty of the problems themselves?

How long would it take you to merge two sorted arrays on a computer without internet access and no one looking?

[raarts]

The pain point is multi faceted:

- the interview questions are invariably things that have already been solved and abstracted away.

- as an experienced programmer it's not your job to solve problems like that. The work you do is more complex and requires sleeping on it, doing research, trying stuff out, talking to people. THAT'S the stuff you're good at, and what you are hired for.

- as a result of doing that increasingly complex work you get out of touch with the simple problems, even worse you develop an instinctive internal block against doing it, you develop a 'spider-sense' for what NOT to waste your time on.

- this gets into my way when doing coding interviews.

- it also makes it harder for me to spend time practicing. I have a family, other stuff to do outside of work, do I need to spend many evenings to practice on things I will only need during coding interviews and will never need afterwards?

The process for hiring experienced engineers is completely broken.

[evoneutron]

It would probably take me less time due to not having the pressure of someone looking, but it might still take me ~ 30min.

I think the general problem is that I don't deal with such low-level problems on a daily basis.

I can write multi-threaded Kafka consumer app that processes thousands events per second and applies some basic ETL on them, add end-to-end integration test for it in <8 hours.

But it may take me ~1/8th of that time to write a low-level (quick) sort algorithm.

[mlthoughts2018]

Interviewers are very bad at accounting for this.

For example, there is almost no engineering question on the planet that people straightforwardly solve from first principles in 30 minutes, unless it’s totally shallow based on memorization or childish rote practice — and has virtually zero relationship to how they would ever solve any problem at work.

But there are all kinds of insanely hard problems that people can give you beautiful solutions for in 10-20 hours, and involve an entirely different way of working than anything possibly representable in 30 minutes.

Engineering and math questions just require burn-in and rumination, tinkering, stop & get a cup of tea, take a walk, tinker more. They just do.

Seeing “how someone thinks” in an artificial 30-60 minute session only tests a completely separate and mostly unnecessary skill set for passing tests and memorizing things.

[koala_man]

>Seeing “how someone thinks” in an artificial 30-60 minute session only tests a completely separate and mostly unnecessary skill set

Totally agree. However, what's a good alternative? A company can't hire everyone for a trial week, and a candidate can't work a trial week for every company. It's really hard to design a hiring process that is efficient for both parties plus resistant to abuse.

[mlthoughts2018]

They can ask probing technical questions about past work experience, projects and education. Pretty much like how every other industry interviews people.

You are right that interviewers won’t get much more than an hour to judge a candidate. So why waste it on information that fundamentally can’t be helpful (like whiteboard trivia)?

Instead, first jump right into a domain where the candidate should already be comfortable and technical — their past work projects — and go from there, probing for more technical depth.

The idea that it somehow makes more sense to use limited time by wholesale discounting & ignoring the person’s previous work history in favor of having them write a sorting algorithm in CoderPad is totally indefensible.