> - relevent to your job

isn't necessarily met here.

I'm also self-taught. I couldn't reverse a binary tree in a tech interview (without looking up how to do it first) because it's never been relevant to my job. I could, however, stand up an API and deploy it to AWS in a similar period of time, because it is relevant to my job.

Like "easy", who defines that? Is it easy because it just takes time? By that logic most things in tech are easy right?

In reality it's time spent on stuff often not relevant to a job at all, it's being used as an artificial filter.

Remember this isn't just about knowing, it's about being able to regurgitate it from memory on demand in a timed high pressure test

> has nothing to do with your educational background

Yes it does? People learn this stuff literally because of their educational background.

You can do some pretty amazing things in tech never memorizing half the things you'd need to for Leetcode.

--

I'm self-taught, and I know my data structures and algorithms, but I don't know algorithms and their nuances by heart so I don't Leetcode nearly as well as my YOE implies.

I see it as a two way street though, I don't want to work at a place that will turn someone down for not running a hamster wheel...

The venn diagram of "positions that need you to know this without any time to look them up" and "positions that ask you to know them without looking them up during the interview" is practically two circles touching.

I have no problem for jobs that actually need that mind you, but so many jobs couldn't tell you where the practical application of their Leetcode questions would ever come up on the job if their lives depended on it

It's never been a blocker for me, my TC is easily as high as what it'd be at Google or FB and I work on cool things.

Surprise, I never needed to manually balance a binary tree for work, and mostly people don't. So I don't see how "it's easy and free to (re)learn" says anything when hardly any software developer who didn't just graduate a year ago remembers this stuff by heart.

Also I'd like to think I know enough about most data structures to recognize where they make sense and to get into implementing using them quickly. But quickly doesn't mean "all of them" or "during the interview" or even "preparing everything in the utmost detail as they would ask without reference material". Teachers also don't explain complicated stuff without preparation, unless it's the material they do every year for many years.

What do data scientists do?

"...I use an ORM, rarely do I need to write a query by hand...."

"I had been working as a consultant and/or starting companies for almost 10 years and found the b2b sales process is literally nothing like the hiring process for SV companies. In one we talked about project goals and solutions, in the other we talked about hypothetical word problems that I have no doubt are popular in CS programs."

And yet, one of the two failed while the other has job openings.

The title is very broad and it could mean a bunch of different things at different companies. But it almost always involves a solid understanding of statistics, hence the probability questions in the interviews.

So from the article, it seemed that the interviews were quite relevant to the jobs advertised, and that the applicant truly was not a good fit for them.

> about 20 of these in-person interviews going poorly ... it seemed like everyone I interviewed with was a caricature of narcissism and delusions of grandeur.

instead of reflecting over if maybe maths is actually on topic for a data science job.

It's also odd, I think, that the companies didn't ask some probability questions in a phone screen, saving time for him and themselves.

> - easy

> - freely available

> - relevent to your job

> then that's pretty much entirely your fault and it has nothing to do with your educational background.

Sure. But reversing a binary tree isn't relevant to most modern software engineers. And when it does become relevant then, like you said, it's easy to learn (on the job).

> It's not even anything that advanced or difficult either.

No but it is something that gets "memorized" for a test (and therefore immediately forgotten afterward).

Although I've never asked or been asked it in interview context, reversing a binary tree specifically is probably just checking you understand how to write recursive functions. Binary, because variable number of child nodes would make the code longer and more complex for no good reason. Reverse, because that's the simplest operation you can do at each node.

People in this thread are acting like tree processing is as exotic as theorem proving, and could never have anything imaginable to do with daily work, but every web page is literally a tree!

And it's not like you can't find out of the applicant knows recursion and what a tree is without bringing in memorization, there's just some weird obsession with a very specific type of problem which happens to often involve memorization

I’ve never been asked this question, so I haven’t “memorized” it as you say, but if you want to flip the order of all the nodes in a binary tree, you’ll need to at least reverse the left and right subtrees at some point. The understanding recursion part is knowing that reversing the subtrees is the same operation as reversing the main tree. In that way, it’s similar to the recursive solution to the Tower of Hanoi.