> Yeah you can read that in a book. I can google it. Useless for interviews.

So, in other words, exactly like algorithms then?

If you hire based on algorithms, there's a good chance you'll end up with a bunch of people who are good at algorithms, or at least willing to put in the effort to study the algorithms and be able to recite them back with some variance.

If you hire based on knowing how the the internet works (TLS, HTTP, BGP, whatever), then you'll be working with a bunch of people that understand how the internet works.

I know which team I'd rather join.

I guess the idea is that TLS is sufficiently complicated that you can take tangents during the interview and establish if the candidate can understand and communicate complex concepts

When I'm looking to hire a software developer, I would personally would rather hire someone who can write well-structured and maintainable code, can describe a system architecture they worked on in a way that is accessible to people not familiar with the domain space, and is able to say "I don't know that, but I know how to Google it".

Now, if I'm hiring a sysop / devop / security engineer, it's going to be differently focused to some extent, but the same principles apply - core knowledge, communication, humility, ability to research.

Amen - maybe for ecomerce webdev roles ask about use of canonical tags and hreflang and site structure.

These are not even close to equivalent. I agree the algos interview process is broken in many ways and can be gamed to some degree by grinding Leetcode or whatever, but implementing an algorithm is generally much more difficult than recalling a fact.

(Admittedly, candidates are likely to have memorized the algorithm for reversing a binary tree since that is such a common interview question)

> (Admittedly, candidates are likely to have memorized the algorithm for reversing a binary tree since that is such a common interview question)

Exactly my point. Testing for "how to implement a known algorithm" is much the same as recalling facts about TLS. You're testing recall only.

You're testing recall only when asking about TLS. You may be testing recall for "how to implement a known algorithm", but there's still plenty of room for testing actual problem solving too.

If you are the interviewer, even if you are asking a standard "how to invert a binary tree" type algorithm question, you hold the cards to keep pushing the bounds for problem solving by extending the question.

Well if you're willing to push boundries, you can certainly do the same with TLS. Ask why the TLS spec does X instead of Y, for various subtle design decisions. This is probably actually much easier to do than with a binary tree, as TLS is a lot more complex and a lot more subtle. It would certainly be an appropriate line of questioning if you were hiring a crypto engineer, not sure it would be relavent to a security engineer or software engineer.

You can ask algorithmic questions that are not easily googleable or standard problems (basically where they have to invent the solution themselves). Although it takes some effort to find the right difficulty problems (tip: the right difficulty is pretty low) so you don't end up wasting time on stuff nobody can solve or stuff everyone easily solves. You can ask people you know to take a stab at a problem to gauge its difficulty. Or you may even be able to eyeball it.

you clearly have no ideas how much algorithms, especially dumb ones, are powerful to discriminate people who think fast from the other

i though like you before doing interviews

Is fast really the goal? Or is it just that most engineers don't want to spend time interviewing so that's what we've optimized for?

Some of the absolute best engineers that I've worked with take their time to wrap their heads completely around a problem before diving in. They aren't slow thinkers, but they aren't people who excel at these kinds of interviews either.

I've been doing interviews for a long time now and I find it more effective to surface strong opinions about things they've worked on -- good and bad.

I'm not hiring into a feature factory -- I don't care about fast cogs. I'm hiring people who care about what they do and giving them an environment to thrive in.

I guess it depends but at the internship level an intern whos gast vs an intern whos slow is like 10x things done dometimes. I work in a math heavy environment tho.. so i can understand your point of view

I see yours also, but we definitely shouldn't be skewing hiring process to interns unless at your company you're mostly hiring interns (I'd think that's uncommon?).