This phrase precedes the one you mentioned. He's saying the process he has been through completely ignored his background and field.
This phrase precedes the one you mentioned. He's saying the process he has been through completely ignored his background and field.
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.
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.
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?
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.
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.
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.
And aside from that, let's face it, none of us here are Einsteins.
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.
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.
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.
It would have been different if he was asked questions that only algorithms experts could answer, but really these are really basic questions.