I'm all in favor of getting rid of the leetcode interviews, but it's not an either-or one, coding competency is still the primary concern, security a secondary one.

And I don't think an individual developer would have prevented this; this is an issue with the general security and monitoring policies at Parler. I mean how could they create millions of admin accounts and extract 70 TB of data without any alarm bells, flood control and circuit breakers engaging?

When I interview candidates and their solution encounters an unexpected condition I typically park the original question to temporarily discuss how to handle this exception.

This and more generally their thoughts on how to handle other types of unexpected scenarios is an important part of delivering real world solutions. I'm shocked by the amount of engineers that don't have any thoughts on this topic.

The popular way of quizing developers during the interview has more about throwaway leetcode than experience.

What you're digging for is about their experience. To me, what you're finding comes at no shock. The industry has been punishing people with experience and willing to show it for years.

I think it depends on level you're interviewing at. New college hires rarely have much a clue about this but engineers and senior engineers should be able to have a conversation about it. To be fair because of time constraint, I don't have candidates code this but do want to entertain the discussion. For example, what happens if i pass "illegalValue" to your method, or what do you think your solution should do when the service dependency you call fails to return.

The sentiment is important because it shows how a candidate ties the requirements to the customer use case that it is serving. Not being able to connect these two is a concern in my mind especially for those who are not new college hires with little real world experiemnce.

It is an important part of delivering real world solutions. How often is it a part of being hired to deliver real world solutions?

I'm not sure I understand the question. In my mind, if you cannot reason through how to handle non-expected things in your code, I'm going to think twice about hiring you. Code being able to account for erroneous situations is as important as your golden path because as we know software should be predictable but regularly is not. Especially so in the world of micro-services where so many integration paths are changing and in flux.

Are you suggesting we should only interview candidates to code the happy case and not consider how they will reason through what to do when the input isn't what they expected or a dependency fails to produce results?

I think you should hire for that skill.

In practice, I do not think candidates are hired for that skill. I have never been asked about error handling in an interview.

Generalizing things because you've never experienced them on an individual level seems like a bit of a stretch. Anyway, it may not be asked in interviews but I've interviewed ~300 engineers for a FAANG company and its something I cover in interviews for the reasons described.

I saw a tweet regarding it that the IP rate limiting fell over due to X-forwarded-for header not being correctly handled allowing the bypass of that circuit breaker.

I am certain most software engineers would abysmally fail the Security+ exam, which is the entry level for security practice.

But a far more expedient process is to just give candidates an essay exam to see if they are functionally literate in their profession.

My go to question for interviewing candidates is "What trends do you see in web development now or you see being important in the next few years?". There's no right answer there, I'm just looking for something relevant that shows they've got some knowledge of the field outside of being able to bash out code to order. For juniors I don't really expect much while seniors should at least be able to talk a bit about a couple of things, but having interviewed prospective head of development candidates I was amazed that two out of four just tanked on the question, one just couldn't answer at all.

Candidates who know there are things they don't know about I don't mind, but candidates who are unaware of these things at all are typically uninterested in broadening their knowledge, and not someone I'd like on my team.

Can you outline what you might expect in an essay exam for a software engineer position?

Would it take the form of a standard interview question:

"Write a few paragraphs on what happens when you press a key on the keyboard"

Or would it use the medium to ask a question less appropriate in an oral interview process?

Genuinely curious what you envision with this format.

The goal is to assess a candidate’s ability to communicate technical matters quickly with structure, organization, and planning. Secondary considerations include the ability to follow simple instructions, command of written language, and accurate descriptions of technical subjects.

Replace fizz buzz with spotting SQL injection issues.

There is plenty of use for coders who can't spot SQL injection issues. I can't think of much use for a coder who can't do fizzbuzz.

How?

Sql injection is so basic, that if you can't spot it, you probably can't do fizzbuzz.

It more likely means that you just aren't familiar with SQL.