[fernandopj]

> If she would have started her email with "We're looking for an algorithm expert," we would never have gotten any further and would not have wasted our time. Clearly, I'm not an expert in algorithms.

This phrase precedes the one you mentioned. He's saying the process he has been through completely ignored his background and field.

[rpdillon]

The notion that traversing a binary tree requires expertise in algorithms seems questionable to me. I view basic tree traversal as table stakes for a developer with more than a year or two of experience (IIRC, it's discussed in Intro to Algorithms in most CS curricula).

OP says that his field is object-oriented design, which links to a page where he announces that "We've started work on a new programming language". The idea that a computer scientist/software engineer would embark on building a new programming language but also state that they don't know how to solve tree traversal problems and "will never be interested in learning them" seems strangely incongruous, given that building a language almost certainly involves working with ASTs.

Specifically, OP pushed a commit in late 2016 that contains code working with stacks, linked lists, and an AST class for the EO language.

https://github.com/yegor256/eo/commit/6df2281d8b0163b9f9e1b8...

I guess I just don't believe that interview questions about trees are ignoring the author's background and field.

[lostcolony]

But optimizing for them? I've been out of school over 7 years; I'm currently a tech lead. I can guarantee you that, while I can likely solve most binary tree related questions you'd care to throw at me, it will take a lot more work, thought, and likely mistakes on my part now than it would have when I first got out of school. It's not an area I've spent -any- part of my development career on, nor is it an area I find particularly interesting. Whereas when I left school, I had actively been dealing with such problems within the past couple years, -and- had boned up on them specifically to prep for interviews, since I had nothing else in my favor.

Hiring a junior with such criteria might make sense; hiring a more seasoned person, probably not so much. Because the seasoned person will just not be as compelling as the more junior person, due to having spent the past few years working on other things.

[enraged_camel]

Funny you bring up the CS curricula.

In response to not knowing the speed of sound as included in the Edison Test, Albert Einstein replied:

"[I do not] carry such information in my mind since it is readily available in books. ...The value of a college education is not the learning of many facts but the training of the mind to think."

This is even more true today with the vast trove of easily searchable called the Internet. A competent programmer should have high-level knowledge of different algorithm types, but should not strive to memorize their implementation (e.g. for interviews), since it is trivial to look that up.

[RandomOpinion]

That story about Einstein doesn't illustrate what you think it does. Einstein was a theoretical physicist, not an experimental physicist; there's no reason for him to have known the precise value. However, you can bet that Einstein knew the theory quite thoroughly (review his writings if you believe otherwise) and would have been rather less than impressed by anyone calling themselves a physicist who did not.

And aside from that, let's face it, none of us here are Einsteins.

[enraged_camel]

I'm not sure I buy that distinction. Do you believe that experimental physicists know every single formula and can recite it off the top of their head? Because unless they use those formulas constantly in their work, they end up having to look them up.

Same thing with algorithms like tree traversal. You should know the theory behind them, but unless you regularly implement them, there is zero reason to commit their implementation to memory to the extent that you can casually write them on the white board during an interview.

>>And aside from that, let's face it, none of us here are Einsteins.

Even more reason to not try to memorize something unless you use it constantly.

[hashseed]

But imagine Einstein having to look up how to derive x^2. I'd say that's a pretty close equivalent to knowing tree traversal in CS. It should just come naturally.

[coldpie]

I've been working in the programming industry for ten years and have never had to implement tree traversal. I could probably scrape together a naive implementation in a relatively short amount of time, but it's certainly not something I've memorized. But then, I'm a programmer, not a computer scientist.

[enraged_camel]

If one is a computer scientist, yes. If one is a programmer, not at all.

[yawaramin]

Sounds like Einstein was a Sherlock Holmes fan.

[petelevinea]

I agree, especially when designing programming languages that it's a bit weird to not know how to traverse a tree.

There is one thing I want to point out though. Before starting my algorithms course I knew how to solve problems recursively. I had done project euler tasks and what not. I just never knew the words abstract syntax tree or binary search tree. I could guess what they were prior to the course but I didn't know what they were off the top of my head.

Do you think that it's possible that a self taught engineer would know how to solve these problems given time and enough questions to the interviewer? Maybe get frustrated with "How do you balance a search tree?" questions under pressure?

[rpdillon]

> Do you think that it's possible that a self taught engineer would know how to solve these problems given time and enough questions to the interviewer?

It's very easy for new interviewers to come up with problems that are easy for them (because they know the subject), but very difficult for the interviewee. Avoiding that is a priority for me, but I still strive to evaluate how the candidate approaches problems.

My strategy is to keep my questions as close to first-principles as possible, making the problem more about programming approach than algorithmic recollection. I had a Google interview once where they asked me to implement pivot tables, and I had to sheepishly ask: "What's a pivot table?" That set me back somewhat, and I try to avoid that in my own questions.

[krzyk]

> I view basic tree traversal as table stakes for a developer with more than a year or two of experience (IIRC, it's discussed in Intro to Algorithms in most CS curricula).

You mix two completely irrelevant things: education and experience.

You will be taught binary trees in CS, but not every programmer is studying that.

If you learn binary trees in CS, you will forget it after few years of experience, because skills that are not used are forgotten.

So yeah, Amazon/Googles of the world are looking mostly at recent CS graduates (most of the set of programmers that know many algos) and the very small set of programmers that deal with algos every day.

[GFischer]

And a third category: people that train specifically to pass the Amazon and Google exam.

I know several people that did, taking several months off to prepare (and got in), and yes, you have to re-learn all the CS algorithms which will probably be irrelevant again after you pass the interview.

[lossolo]

> Specifically, OP pushed a commit in late 2016 that contains code working with stacks, linked lists, and an AST class for the EO language.

Most people can work with Vectors/DynamicArrays, linked lists etc. but they don't know how to implement one or even how it works in detail under the hood.

[zeroxfe]

I don't think traversing binary trees satisfies the criteria for "algorithms expert."

It would have been different if he was asked questions that only algorithms experts could answer, but really these are really basic questions.