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