My philosophy when hiring now is to be trying to answer the question of “how much responsibility could I give this candidate and feel confident they could flourish”. A junior engineer should be able to be given a clear spec and be able to implement it. A mid should be able to do the same thing with a poorly specified spec, in a domain they don’t necessarily have experience in. They should know how to learn. A good senior should be able to support a team to figure out what needs to be done, and move heaven and earth to get there. They should be able to fix (and anticipate) any and all problems that show up. Train people. And push back when they’re assigned a problem that doesn’t make sense, or given unreasonable deadlines. A good senior can be responsible for making sure a whole team delivers a working product.

From this perspective, a technical whiteboard interview is one of many tools. Interviews I give usually start with “so your boss asks you to solve problem X ... where do you start?”. Then I throw more and more problems at them (technical, organisational, etc) and see how they respond. “It’s in production and people start complaining that it’s slow. Where do you look first?”. “What problems do you foresee with this design down the line?”. “If you had $1m/yr budget to hire a team to scale this system, what would your ideal team look like? How would you spend the money?”. “An inexperienced team implements this and it’s buggy. What mistakes are you worried they might have made?”

Ultimately we get the traits we hire for. Being able to code (and debug!) is important. But I also want employees who I can delegate to, and trust that they’ll figure things out. I’ve been able to pass whiteboard interviews since second year uni. But I have not stopped learning, and the non technical skills I’ve gained since then are at least as important. Test for them.

Saying that "you're not payed for that" is risky. Yes, you're technically right but when you will be at your new fancy job you may need to do MANY things that you aren't technically being payed to do, so that you can deliver. That IMO is one of the essential skills a senior developer has, not that they can do things a junior developer can't, but that they have a breath of knowledge and skills that make them good junior developers at many things they aren't specialized for and are able to make use of them to get the job done. In that light, picking on "one little thing" such as the interview process using something you may not be used to or like or ever need to do when actually hired (whiteboard coding), seems wrong.

I don't understand how this is a problem? If OP is a Senior Dev and interviewing for another Senior Dev role, wouldn't you assume that this new role is probably going to require similar skills to perform similar managerial type responsibilities?

I mean, sure go ahead and prepare for interviewing, brush up on whatever you think will help. But if a company has a policy of consistently rejecting candidates based on testing of skills that are never used on the job, it sounds like there's a lot of room to improve that interview process.

FWIW, I'd refuse to work for a lead or architect who wasn't tested on their ability to write code (and in my current position, my manager, their manager, their manager, and their manager all have significant work as SWEs that I can see, or passed coding interviews).

The thing that I find when conducting interviews is that people who have trouble writing a concrete solution to a problem often have trouble formalizing any solution. They can handwave stuff that maybe makes sense, and given enough good faith is "correct", or at least not obviously incorrect, but at the same time it depends on a whole suite of libraries that don't exist, or a domain specific language that someone would need to come up with, or something.

And if you need to invent a DSL to parse a string, I'm worried about how complicated your actual solution would be when redesigning the release process. Because sure, any monkey can write some groovy code that does something. But I'm more worried about if that code will be well designed. Note, not the system, but the code itself. Because in reality the code defines the system, and a beautiful architecture implemented terribly is still terrible to work with.

To see the second thing, I need to see concrete code.

One problem I have is at my level it's really more about architecting than coding. Although coding is still important.

(And by the way I realize in a lot of companies, 'architect' is a completely bogus term for someone who's more of a flim-flam man than actual doer. So just substitute "staff engineer" or whatever you call it.)

But the main parts of my job I have to get right are picking the right approaches technology-wise, and setting up frameworks and patterns to make devs' lives easier in building out the actual features. You can't test that stuff on a whiteboard imo. You have to just talk it through and try to get a sense of how the potential architect/lead thinks about problems.

It also takes a good architect to interview an architect imo. There's plenty of great devs who just haven't acquired that level of scope yet - not of thinking not just about how easily it is for you to get something done - but how easily it will be to maintain as a team, within the greater ecosystem, over the life of the product.

I think the most valuable engineering leader would be someone who can remove code, or at least prevent unnecessary code from being written and maintained.

Code is a liability as much as it is an asset.

> inevitably the company starts grading on a curve

which explains the paradox of too many developers chasing too few jobs versus all these companies complaining that they cannot find enough good developers

That's what FB does these days: how fast can one code, how bug free, etc.

Absolutely. Then it's all about selling the team, the company and it's potential. If you can't sell your vision to your employees you probably won't be able to sell to your customers either.