[baron_harkonnen]

There's also a lot of senior devs who think they are a false negative who are not.

I speak from personal experience. I failed my first FAANG style interview both because I had not prepared nor understood how white board interviews really work and because a huge subset of my skill had gotten rusty over the years. But when I first failed I was really upset and very quickly wrote off the entire process as a ridiculous test. Looking back I was a true negative and needed to brush up on a range of skills.

When I was a junior dev I spent nearly all my time studying programming, CS and software. But as I got more senior I definitely relaxed a bit on all of that and coasted more on the inertia of past successes than I should have. Yes I was good at my current job, and the ones before it, but those only represent a small subset of the skills a senior engineer should have. What made me a great engineer in one specific company allowed me to let other skills that I wasn't using decline a bit.

By being a bit more honest with myself I spent a long time getting back into the things that I used to love and also learned how to practice whiteboards. All my white board interviews after that were a success.

I think a huge push back by senior devs against these interviews is that they don't want to admit that, while they have gained a ton of valuable experience, they might not be as strong of a software engineer as they once were.

[munchbunny]

I don't think any good senior devs are under the illusion (privately) that they're rusty at whiteboard interviews. I'm certain my college grad self fresh out of practicing for the ACM contests could have run circles around my recent job search self when it comes to algorithm stuff. I had to practice and then pass a ton of whiteboard rounds to get my current senior developer job, so I'm not saying this out of bitterness.

However, and I think this is the crux of the problem, you're not paying senior developers for that. I've never had to actually do any algorithm slinging on this job. The fanciest it usually gets is chaining some maps and filters.

On the other hand, I have had to do "rocket surgery" on critical path legacy code, write business logic in a maximally predictable and readable way, figure out how to land a non-backwards compatible change with no downtime, convince other teams to help with an initiative my team is leading, design an internal API, etc.

Doing that stuff requires experience, rigor, resourcefulness, and I'm sure you can come up with more "senior" traits. My personal complaint about whiteboard interviews, even systems design interviews, is that they only indirectly measure those traits.

[josephg]

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.

[d1zzy]

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.

[munchbunny]

I don't think I understand your point. I was talking about how algorithms interviews map badly to the skills required by the job description. That's only tangentially related to whether you'll have to do things outside the strict job description.

[suzzer99]

For sure I wasn't the software developer I once was when I was interviewing. I'd been in an architect role at a gargantuan company and mostly POCing things for a few years. Then I went on a 7 month road trip where the majority of my brain was dedicated to learning Spanish.

However I can confidently say that it only took a few weeks of being thrown back in the mix to shake the rust off and get going again.

If I was an employer and could extend contracts at fairly low risk, I'd give devs with a strong resume and a demonstrable open-source library a chance - despite them being a bit shaky on the whiteboard.

[suzzer99]

FWIW - I'm not talking about no demonstration of coding ability at all. I'm just saying don't always assume the person who aces the coding challenge with time to spare is going to be a much better candidate for the job vs. say a dev with an interesting resume and orally demonstrated problem-solving skills - who just passed the coding challenge.

[malvosenior]

This is such a great response and I've had similar experiences. As you become more senior you also get more managerial responsibilities which can eat into your time/energy budget to stay up to date on tech not directly related to your job. You may also get more life responsibilities as you age (family...) that further erode your technical edge.

Good on you for having the introspective skills and awareness to identify the problem and do something about it.

[wuliwong]

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.

[malvosenior]

A lot of time people will move to a new job for a more senior position than their current job. Being a Sr. Engineer at a Series A funded startup can be very different than being a Sr. Engineer at Facebook (not always, but often). I would expect a higher bar at a larger engineering organization.

If someone is effectively testing for these more difficult subject matters then it's quite possible that they themselves and other co-workers are competent in them (as they passed the same test).

[wuliwong]

Your argument basically boils down to that you think your experience is the norm and OP's is the outlier.