[joshuamorton]

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.

[beat]

When I'm interviewing experienced people, I usually gauge technical skill by picking something out of their resume and digging into it with questions. If they don't really understand what happened technically, it's immediately apparent (this is also how you catch inflated resumes). And if they do, I can just keep asking more questions to get a better sense of it.

This is far more real-world than a coding test, imho. Coding happens on the micro level, but understanding happens on the macro level.

[suzzer99]

Yeah this is much better.

This guy has the right approach imo: https://www.karllhughes.com/posts/rethinking-hiring

[karlhughes]

Thanks for sharing! I read this post and thought the same thing.

I'm honestly nervous that next time I have to go out and interview, I'll be in the same shoes as OP. Despite many years of managing software for small companies, I have no desire to go back and re-learn Leetcode just to get a job.

[joshuamorton]

> This is far more real-world than a coding test, imho. Coding happens on the micro level, but understanding happens on the macro level.

But being able to map the macro to the micro is a vital part of being a competent SWE. This includes being an architect. If your plan only considers macro-issues, but is difficult to actually implement on a small scale, its not a good plan.

I want to gauge both, and a coding test is a good way to measure the micro.