I’m on the opposite end of the spectrum. I work for small companies mostly and I’ve conducted interviews for small companies. We have a limited budget for a limited number of positions. One developer can be working on a project that can individually move the needle. We need to hire “engineers” in the truest sense of the word not “coders”.

For instance, currently my title is “senior software engineer”. But I am the “Directly Responsible Individual” for a project that one of our clients is paying for. It will be added to our core product.

This means that I’m expected to interact with the client and BA to come up with the SOW, work with the product manager/UX person to design the interface, do some of the web work, write the backend using one of our approved languages (C#, Javascript, Python) , design the database schema, do all of the CI/CD setup and to know the AWS fiddly bits and know which services are appropriate for the asynchronous processing requirements.

I’m no special snowflake, this is life in small companies since my first job 20 years ago.

I don’t interview candidates for algorithms. I interview them to know whether they can hit the ground running on as much of our (industry standard) technology stack as possible, will they make good architectural decisions, can they ship a feature across the finish line, how fast they pick up new frameworks and will they embarrass us with customers and senior management.

LeetCode ability does us no good. I want to know whether you can translate real world business requirements into a working system - including knowing which questions to ask when customers/product managers come to you with “XY Problems”.

I don't know your scale for small, but my current org is tiny compared to AWS (my previous).

So yes - we have to do all those things. I am directly responsible for ALL of data analytics infrastructure in snapchat. Pretty much most senior engineers have a similar scope.

We might be talking over one another though: I am not saying any of that is useless: I am saying they're hard to measure. We still do it though. We also do the coding round as something that gives a more definitive datapoint.

My definition of small is less than 50 people in total including salespeople, managers, implementations managers, and a few QA people.

It’s really not that hard to ask a few technical questions based on what they purport to know, the soft skill behavioral questions, some design questions, and ask them about previous projects. The hands on part is the part where they fix the code to make the unit tests pass.

I wasn’t asked a single technical coding question for my current job. I was given real world questions about issues they are having with process and how I would go about (re)architecting some processes.

Now that I think about, my job before that when I was interviewing for the dev lead position I was only asked about process, system design, and a lot of high level theory - both jobs were hands on coding positions. Both of the managers were highly technical with current programming experience.

But, I’m not completely disagreeing with you, if you are solving hard problems(tm) at scale you need people who understand algorithms and you may not be able to use off the shelf solutions - I would say Snapchat qualifies for “at scale”.

But, for you typical yet another software as a service CRUD app or your typical dark matter corporate developer - and those positions are a lot more numerous than HN seems to realize - the complications aren’t in the complexity of the code, it’s in translating the business needs to code and shipping software that the company needs.

As strange as it sounds, the “coding” side of software engineering has gotten a lot simpler 20 years into my career than it was when I started (C, C++, and a little x86 assembly). The “engineering” side has gotten a lot more complex and requires me to know a lot more technology.

I don’t think it’s because I am better “coder” now either. When I got my first job, I had already been a hobbyist for a decade doing assembly.

Ummm... weren't you claiming in a comment the other day that you use FizzBuzz to interview candidates?

No, I was defending the use of FizzBuzz as a “Bozo filter”. But FizzBuzz is so commonplace that it is meaningless.

I have been able to weed out candidates by asking them to do an isOdd() function as part of a pair programming exercise. It was still the Bozo filter before I gave them harder problems. Similar in complexity. But even that, I’ve done with an IDE with a skeletal class and failing corresponding unit tests.