[agentultra]

> The employer wants to gauge your unscripted in the moment programming knowledge.

I see the appeal of knowing this but I think I'd take a submission from the OP as-is in place of a "coding test."

My thinking here is that I can't recall an instance where I needed to write code at a job with a timer ticking down and someone reviewing my work as I went. I usually have the luxury of doing some research and taking a few attempts at a problem before I understand it and write a decent solution.

I'm not sure what we expect from candidates when we force them into these situations. Am I supposed to be impressed by their solution? I can't think of how I would be. The code I'm most proud of writing took me several attempts to write. Often over a long period of time. Am I supposed to gain some insight into the way they think about problems? I already know how most people tend to solve problems. It's a well understood area of research. What else is left?

All I expect candidates to prove is that they've practiced a problem set and can recall a large number of solutions to trivial problems. Useful but it doesn't give me an indication about how they'll perform. Three months into the job and they'll probably forget 60% of the problem sets they practiced anyway.

Do I want to hire programmers who have an intuition of complexity and know when to use a binary tree or a linked list? Definitely! But I'd rather talk to them about real experiences they've had when they had to make such choices and find out why they made the trade-offs they did. It's hard to do that with trivial problems.

[renegadesensei]

I'm a little biased as a devops guy and former SRE. When you're on call dealing with strict SLA's, your ability to make intelligent technical decisions quickly is important. I expect the guy I hire to not have to Google how to check CPU load or how to pipe tail output from log files into a grep function. At the very least a timed coding exercise tests their nerve.

For other development jobs I generally agree with you. The coding screen will not tell you much. Particularly for a mid-level or senior role. In those cases I am way more interested in their portfolio and in having a long casual technical discussion.

[agentultra]

The SRE team is infamous! I tried the interview for the SRE team to see what it was like. At the final interview I was asked to implement a K-NN algorithm, which I did, and then optimize it for k dimensions.

When it was over I asked the interviewer if there was ever a time when he had to implement such an algorithm on the job during a production outage event and his answer: No.

In my experience working within devops teams maintaining and developing public cloud infrastructure I don't think I've ever had the pleasure either.

In retrospect I don't think it was a bad experience. I think there are roles which exist in software that do require a higher level of rigor than others. I'm often amazed how easily many developers will dismiss performance concerns (premature optimization!) for example. I would expect a hiring process to be upfront and honest about such requirements and candidates should be aware of their own skills and background before applying.

But most software development jobs at ABC Corp are not the SRE Team at Google and they hire as if they were.

I think that's the risk we take with standardizing and automating hiring processes.

update: just markup.