Why do you need arbitrary (and very short) deadlines, and for someone to stand up at a whiteboard while simultaneously trying to solve a problem and "walk you through their thought process" to filter out people who can't write code on the job?

The short deadlines are because neither the company nor the candidate wants to spend a month on an extended interview. Solving a problem and walking through the thought process are because that's what "coding" is.

> neither the company nor the candidate wants to spend a month on an extended interview.

So says the companies that insist on multi-round, multi-week interview loops.

I don't know about you, but I've never had to live code a PR and explain to my reviewer what I was thinking while writing the code. By "deadlines" I'm referring to the length of the interview. Take home problems theoretically solve both these issues, but they need to be properly scoped and specified to be valid assessments.

I sit down with juniors and sketch out designs or code for them while talking through the thought process at least once a week, and even when solo coding, I expect everyone produces work that explains itself. For particularly complex/nuanced changes, people do hop on a call to talk through it.

Like I said the deadlines work for both sides. If a company wants to give homework instead of having their own senior engineers spend time talking to me, that tells me what I need to know about how they value my time.

> I sit down with juniors and sketch out designs or code for them while talking through the thought process at least once a week, and even when solo coding, I expect everyone produces work that explains itself. For particularly complex/nuanced changes, people do hop on a call to talk through it.

That's not equivalent to what I said, nor is it live coding.

Again, those deadlines are artificially short compared to real world scenarios, and completely arbitrary. They are so short, in fact, that they render the interview an invalid test of real working ability. A work sample has been proven time and again to be the most valid measure of whether a candidate can actually perform the job, but the conditions under which a live coded "work sample" is performed in an interview render it invalid.

It's not artificial: the company has a day of my time. I have a day of their time. We both want me to meet several people on the team to see if it's a good fit. Because of the constraint, we keep it to relatively simple discussions around toy problems that can be solved in an hour.

Yes, it is artificial. Everything about a live coding interview is artificial. Code doesn't get written in 1 hour blocks while someone's watching over one's shoulder, all the while asking questions to interrupt one's thought process, in any company I've ever worked for.

Like I said, this is literally a thing I do all the time. I have standing 1 hour blocks for each of my team members every week and it's not uncommon for us to build out the skeleton of a problem solution together. I literally did what you said on Wednesday for someone for a gitlab change because I don't expect they know how secret injection works, but I want them to know. And absolutely I've encouraged them to ask questions, and I ask them questions to check their understanding.

Like I said, that's not the same. It's not comparable in terms of stakes, or expected outputs. You're not addressing the issue.

[dead]

[deleted]

In most of the western world, firing employees is a high risk, high cost task. Ideally companies would hire quickly and fire poor matches just as quickly once they've been evaluated in the real world environment of the company. For this to work, on the employee side there needs to be knowledge that this is the company's process, financial depth to deal with the job not being stable, and a savviness to not relocate into a job that's risky. On the employer side, there needs to be a legal and social environment that doesn't punish removing non-productive employees.

The legal environment is what it is and unlikely to change. The social environment is fickle and trend driven. Workers can't always fully evaluate their odds of success or the entirety of risk of leaving a job that's valuable for the employee and employer for one that might end up as a poor match, even if both sides have been transparent and honest. It's a difficult matchmaking problem with lots of external factors imposed and short term thinking on all sides.

Ideally young workers would have an early career period that involves a small number of short lived jobs, followed up by a good match that lasts decades, providing value to both the employee and employer. Much like finding a spouse used to be a period of dating followed by making a choice and sticking with it so a life could be built together, employment ideally should result in both sides making the other better. Today however everyone seems focused on maximizing an assortment of short term gains in search for the best local timescale deal at the expense of the long term. It's interesting how the broken job market and broken family formation process in the western world mirror each other so much.

I suspect the similarity is just a coincidence.

There was a lot of social pressure in the past for permanent marriages. That doesn't mean they were happy marriages. With the social changes in the west in the 1960s, divorce became more socially acceptable. Legal changes meant women had the ability to join the workforce and support themselves. People in unhappy marriages had options to seek happiness elsewhere. Those options didn't exist before.

For job retention, the problem is that changing jobs is often the only way to advance. I lost my best worker because the suits wouldn't give him a raise. He now makes more than I do at a different company. He liked his job with us, but he tripled his pay by leaving. My coworkers all tell the same story. I'm one of the lucky ones that managed to move up in the company, and that's only because I had the boss over a barrel.