That doesn't make any sense whatsoever. You do not hire someone because he knows about a certain technology. You hire people because they will provide long term value to your company and are able to adapt a rapidly changing technology space.

Reversing a binary tree on a whiteboard is certainly a bad question to ask. But I would argue, for all intends and purposes still a miles better indicator about future potential than if someone knows how/why TLS work. Yeah you can read that in a book. I can google it. Useless for interviews.

If you are hiring for a position that requires you to implement TLS, sure go for it. But that is not the rule. And what are you going to do after he has implemented TLS? Will he be able to work on something completely different?

> 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?).

Are you someone who makes hiring decisions?

The vast majority of web developers will never touch things like TLS configurations. We have stuff like nginx and WSGI for a reason!

Meanwhile there's a decent chance of them running into a problem that looks like binary tree manipulation.

Despite all the handwringing about btree reversal, not being able to improvise a solution to that is a much more useful indicator than not being able to describe even the basics of TLS.

Security engineers don't actually recite trivia facts about TLS in their job. Their job is more like, know when you should use TLS and when you shouldn't and know what it does and does not protect against.

A security engineer is just as likely to derive a tls cipher config from first principles instead of googling/looking at ssllabs as a programmer is likely to reverse a binary tree from scratch instead of using a library or searching stack overflow.

Engineers (of any stripe) aren't hired to recite random knowledge, they're hired to know what knowledge is appropriate to apply to a particular situation.

I've been doing web development for a long time, and I've never had to do anything like btree reversal in a web development context.

It's probably not even that hard, but I doubt I'd be able to improvise a solution in an interview setting that's nothing like a real work environment. (Memories of trying to work out some kind of graph traversal while someone was basically just staring at me.)

It seems to me that people who are doing this kind of work behind the scenes of a web app aren't really doing web development.

uhh...setting SSL parameters is part of defining an HTTP block in nginx.

As someone in a public company with actual customers, we have to deal with TLS configuration all the time (as customers come with requirements and being public comes with compliance/security) and it's important to know what we're doing there...

I'm responsible for millions of dollars in infrastructure and the way that I got here was being a web developer who knows how the internet works. And in an engineering organization with hundreds of engineers, most of them tend to come to me first with questions.

I have never once in my career had to reverse a btree.