[dantheman]

You can offer a coding test - give them a computer, a piece of paper, etc. Let them sit a room by themselves, give them up to an hour to do a 15 minute problem. There are lots of ways to destress the coding interview, but the ability to code has to be tested.

[beat]

What if the job doesn't really involve coding? That's true of rather a lot of senior/lead level software engineering jobs. Security analysts, devops engineers, architects, and others may never write code at all as part of their jobs.

As a senior devops engineer, I write a lot of trivial Groovy code for Jenkins pipelines. But the interesting part isn't the code, which for the most part a monkey could do. It's redesigning the release process. The rest is just implementation details.

Thinking coding is important is a failure mode.

[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.

[suzzer99]

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.

[beat]

> It also takes a good architect to interview an architect

And that's the underlying problem behind this coding-test nonsense. You don't ask an architect candidate to implement a binary tree in an interview because it's relevant - you ask that question because you don't know how to ask questions that are relevant. For anything but actual low/mid level coders, these coding tests are just evidence of a failure to interview effectively.

As an aside, I don't find most architects to be "flim-flam men". They are usually quite hardworking and competent, although their job is frought with risk. They're often asked to do the impossible, and they have to do the best they can with it.

[hellisothers]

Why is this getting downvoted?

[beat]

Because I keep calling the coding test mentality "nonsense".

[rhinoceraptor]

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.

[suzzer99]

Yeah but then inevitably the company starts grading on a curve. Did the dev nail every single possible mistake or bug? Did they add any extra flourishes? So you're not just testing for basic competence anymore. You're testing for devs who are really good at timed coding challenges - just like with challenges where it's tough to get the right answer in the allotted time.

Companies don't get excited about a dev who just passes. Even though that dev might be by far the best candidate - they just need a few days to chew on various architectures - or they take the test literally and don't add bells and whistles. Etc.

Companies get excited about a dev who aces it with flying colors.

[HillaryBriss]

> 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

[raincom]

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