Can't you expect a halfway decent coder to derive how to invert a binary tree from first principles? It's literally just swapping the left and the right field in each node...
The thing is when I’m the interviewer I’m not looking for coders. I’m looking for people who can understand the business, find a solution that is business oriented and produce (if needed) good enough code (we are not Google). So, if you cannot invert a binary tree from scratch but are good at the other skills I’ve mentioned above, I want to work with you.
What good is someone who can code the best algorithm but cannot understand the business? Unless you are working in the top 1% of the companies out there (where you may have the luxury to invent new ways of doing things), for the rest of us our main skill is: to solve business problems with zero or minimal good enough code.
We (99% of the tech companies) don’t need a Messi, just an average Joe.
This is the reality that most engineers that spend their lives online don’t seem to get.
We don’t need you to be the best engineer using the most cutting edge tools that a YouTuber told you about. We need you to be a good colleague who people can trust, can communicate with, and isn’t going to cause a ton of stress for others through maverick behaviour or major levels of incompetence.
Then don't ask this question if it's not relevant for your position? Presumably those who would ask it don't want to hire engineers that have never heard of recursion. It's a basic level CS concept, not rocket science.
What a team I worked in did, is we reminded the interviewee what a binary tree is. It's a pretty simple concept, much simpler than most businesses, so it makes a good test for basic general logical thinking skills.
We were hiring for a C++ role though. I can imagine people used to higher level languages might find the very need to deal with pointers confusing
Pointer vs reference: What's the difference? Practically, not much. All "higher level" languages (that I know ... er... except Perl) use references instead of pointers.
> I can imagine people used to higher level languages might find the very need to deal with pointers confusing
I'm confused by this remark. What do you mean? Is this meant to be condescending? What do you use pointers for in your C++ project that references cannot do in a higher level language?
My point is that in higher-level languages you might spend your entire career not thinking about how your data is laid out and what points to what, while in C++ you are exposed to this reality daily even if you are working on trivial problems.
That is my hypothesis on why some people might consider inverting a binary tree an unrealistically complex problem. If you are not able to solve this problem without thinking too much you are probably not being able to write working C++ at all, but might still be able to even solve real business issues with, say, Javascript.
Never worked in tech so I find this mindset really alien. Why no specialisation and separation of duties? Why not have someone really good on the business side and someone else who is really good at coding?
Finding good solutions often require simultaneously considering both the business side and the programming side.
The business-only guy won't see the limitations and possibilities of code, while the programming-only guy won't see where the business side is flexible or where it is rigid, thus the optimal solutions can take a long time to find.
The business side might also be prone to specifying X-Y problems, which can be very difficult to spot if you're not into the business side.
At least in my experience, having significant domain experience in our dev department has been a super power of sorts, allowing us to punch well above our weight.
edit: I didn't have any domain knowledge when I started, but I was willing to learn.
That's already the starting point. People who really understand the business, and developers who work with them. The point is that the developer also needs to understand the business well enough. You cannot separate that from coding if you want good results. A good technical business analyst that sits in between the business and the developers can really help, but that is no substitute for the developer having good knowledge of the business and what it is actually trying to accomplish.
Sometimes the business only has a high level goal in mind and it is up to the developer to invent a solution, keeping in mind how the end user will interact with the system in their day to day work, and foresee potential issues in how the changes would impact other systems and business rules and so on. The developer has low level visibility of systems that are not readily apparent to business people. It is necessary for us developers to hide some of that complexity from the business. Some backends are very complex webs of business rules.
The developer needs to have some bigger understanding of it all, otherwise they are reduced to a code monkey who implements spoon-fed acceptance criteria from Jira tickets, makes stupid mistakes that break other functionality and systems, and won't recognize various issues that were not apparent to the business person who originally wrote the AC's. Basically we need developers to collaborate with the business to design and develop solutions properly.
Why not both in the same person? It's cheaper to pay one really good person 50% more than paying two people. It is quite common in domain-heavy tech areas (financial markets, etc.).
What if they can't do it from first principles but you tell them the trick, and they bang out the code in 5 minutes? Does that count? They've shown they can code, right?
Why is the former so much more important than the latter, for 99.9% of programmer interviews?
(protip: it isn't, but I guarantee you will get a "no hire" far more often if you need a hint. It's just nerd in-group hazing, coupled with a big helping of cargo culting Google.)
I think it translates to solving day-to-day problems. I don't think I could trust someone who couldn't figure out the binary tree thing cold, to figure out that some Spring bean is not request scoped by looking at the object reference, or that openapi code generator is looking in the wrong folder, or a dozen other things that require some mental effort and can't be googled easily.
If I’m responsible for it then I should have some experience with it and understand the code already. I can call upon other resources outside my own brain.
It’s certainly not being forced to recall the implementation details of a trie within 30 minutes, when I haven’t seen one in 5 years, unable to reference any docs or knowledge base, or use Google, knowing that if I fail I will remain unemployed.
The context of this thread is a very basic question that any good programmer should be able to bang out in 15 minutes. It's much closer to something you "should have some experience with" than "implementation details of a trie"
If by "most" you mean people in this very thread who are claiming that binary trees is some crazy obscure thing that nobody can be expected to be familiar with, then sure.
Maybe. But you don't ask someone to "figure out a binary tree cold"...you ask them to do it while talking and coding on a video call (sigh).
Go solve a hard puzzle while talking on the phone. Does it make you better or worse? I'm just saying...if someone needs a hint for the trick, but then, post-reveal, bangs out the code under the same circumstances, isn't that telling you something interesting?
Just wait until the OP freezes during a "easy programming problem" as an interviewee. I have been interviewed more times in my life that anyone I know. I have failed sooooooo many different ways -- all unique. Some days, you get lucky and can solve a brutally hard algo problem. The next day, you fail trying to reverse a string, or something equally as embarassing. Tech interviewing is a numbers game; that's it. I do it enough until I have a very good day and someone gives me an offer that I like.
It is prep game. You train all common interview questions, do mock interviews with friends, prepare answers for common culture fit questions, research company interview process online, tailor cover latter and ask people for recommendations from previous jobs.
What people do instead is spray and pray CVs and hope that hiring manger uncover their brilliance under surface level incompetence.
If the winning candidate has to "train all the common interview questions" (of which there are thousands), then what are you actually learning by asking the questions to the winning candidates?
I think the main issue is that people would much rather spend their free time learning or building something useful, rather than the "prep game." A more skilled, knowledgeable workforce would benefit the corporate overlords as well, but we can't have that due to the broken interview system.
You change job every few years, spend majority of walking hours in job and your financials directly depends on job. Why would you not spend time on prep.
I have no sympathy for people posting "jobless for months and reject coding test interview" in one sentence.
Dealing with binary trees is covered in introductory data structures courses in the sophomore year of college. One would hope that the average senior developer is more capable at coding than a college sophomore.
So are red-black trees, but almost no one has the rotation/rebalance algos memorized. Hell, even look at binary search: There are so many ways to go wrong. There is a famous blog post from Josh Bloch about it.
What will you say when you fail an interview over an "introductory data structures" problem?
so much this, I applied recently to a tech company which gave me 2 questions to complete within an hour.
I knew the solution to the first was the min-cut algorithm, but no way I could code it straight up and down let alone in ~30min.
Plus these leetcode-esque questions always come with millions of test cases making the need to be 100% exact and double check the constraints.
I even had my data structures/algo book nearby on the shelf that I could've used to cheat this but that would've been a new low for me, especially considering this was for a "mid"-level position working on APIs/JS/SQL.
I can understand if you want me to be an algorithm specialist but for web development for what im assuming would be a run of the mil SaaS application... this is absurd.
Sorry for interview experience. It is definitely a buyer's market in US tech right now, so companies can wait as long as necessary to find their unicorn to write CRUD apps for less than 100K USD!
The real question: If the tables were turned, could the interviewers pass their own tests? Probably not.
Yeah, you're making the exactly point of the parent comments: remembering sophomore-year CS courses != being a good developer.
You might as well be quizzing people on Calculus. That's another thing you study in a freshman-year CS course, so you must remember it, right?
(I'll say this: I've had far more practical occasion to use Calculus than binary tree manipulation in the 20+ years of my professional coding career. Particularly with AI.)
To give you a vignette in my job - I am right now debugging a piece of open source code that had some auth changes at sometime in the last several months with no changes in the docs to suggest a config change is needed. I have to figure out how 3-4 different frameworks are resulting in this not working.
If my boss messaged me right now and handed me something that required a similar data structure change, I'd stumble on it for about an hour or two until I understood that actual problem.
I'm sure I could "invert" a binary tree if I had to but it'd probably take a far more than reasonable time as that just isn't something I'm dealing with nor most rank and file devs.
Not necessarily. There are a lot of really good, self-taught engineers out there who have never had to do that before and likely don't even know what "invert a binary tree" means.
In my experience, it's much better to give them a problem to solve and have them walk you through the thought process as they try to figure it out. Even if they fail to solve it, the actual process gives you insight into how they think and how they'll perform on the actual job.
Unless your job regularly involves inverting binary trees, that's not a great question because it's basically asking if you've encountered something before. If you have encountered it, you likely know one a half dozen ways to solve it and everyone will give you roughly the same answer. If you've never encountered it, then you just fail even if are a good fit for the job. It doesn't reveal anything except you know one specific thing. In most cases, engineering jobs are problem solving for unique instances that arise day-to-day; a good interview should reflect that day-to-day reality more.
But you don't ask them "swap the left and right field in each node". You ask them to "invert a binary tree".
Why. The Fuck. Does "invert a binary tree" mean "swapping the left and right fields"?
To me, it means inverting the relationship so child points to parent, which would end up badly-defined, there would be no way to uniquely specify a root. But if you don't know that knowledge, of what the jargon means, you're screwed. So that's what you're testing for.
Are you imagining a scenario where the interviewer writes "invert a binary tree" on the whiteboard, refuses to elaborate and leaves the room for half an hour?
In real life they would either give you an example so you can better understand the requirements or expect you to come up with an example yourself and ask clarifying questions until you're on the same page as to what "invert" means.
Sure, in that case it may be a bit unfair. I was looking at the leetcode thingy where they just give you an existing data structure, some sample in- and outputs, and just ask you to write the inversion algorithm. I assume it would be like that in most job interviews.
That's a high bar - in my experience (New Zealand) 1/3 of candidates can't even write any form of code to retrieve a random element from an array. 1/3 have to be nudged along and asked some leading questions, and 1/3 are "what the heck are you asking me that for, I can do that in my sleep, that better not be indicative of the quality of coders... "
There is just so much misrepresentation out there it's insane.
I hear these complaints a lot - and feel like the unspoken problem is your HR or recruiters are non-technical and shovel garbage candidates at devs to sort out. Whenever I've had (technical) engineering managers involved with reaching out and reviewing candidates, we rarely have misrepresentation or fakers.
Graphs and recursion are fundamental CS concepts, a candidate that doesn't understand them would be a pretty bad fit for a lot of software engineering jobs.
They would be a bad fit for a few software engineering jobs. I don’t deny that those concepts are fundamental, but the vast
majority of software engineering jobs out there are about: designing apis, calling apis, writing sql queries, fixing perf. issues, writing yaml config files, etc.
You can spend years working for companies in which you would never touch the topic of graphs, for example. That doesn’t mean one doesn’t need to be aware of the concept of graphs in case you need to deal with them. Another story is whether you need to know from first principles (or from memory) how to traverse a graph in different ways.
I think the most underrated skill is to know what you don’t know. To know your limits. I know that graphs exist and that they are useful in certain circumstances. I don’t know how to implement the associated algorithms. Same goes for almost any other important topic like virtual memory management , security, performance, etc.
I actually did that last week (parse a json object from an http response). But I used a well known library for the language we use around here. I mean, I also rely on automatic GCs and compilers… and while I saw the theoretical side of such topics years ago in the university, I cannot implement a single algorithm related to them (because I don’t do that on daily basis)
We don't even know what defines a "good engineer" come yearly performance review time, but claiming that it's the knowledge of graphs and recursion seems rather suspect.
Inb4 "obviously there's so much more to being a great engineer," but then why are we not testing for that iceberg, instead just scratching the surface of "CS fundamentals?" And in fact, how many times does a great engineer need to prove that they understand fundamentals? Forcing engineers to go through that every time they want to switch jobs is inefficient and, frankly, disrespectful.
In 2024, the list of X and Y are fucking HUGE. I would like to see OP sweat in an interview on some "fundamental CS concepts" they have not used in the last 5-10 years. The lack of humility in some of these comment is simply stunning.
I worked with a guy who was absolutely a first class engineer. Very well paid; I guess about 300K USD. He had almost no experience in C++ for more than 20 years (mostly Java and C# for last 10 years). During a discussion, I mentioned that the original C++ std::map used a red-black tree. He was well-surprised that lookup was not O(1); instead: O(log2(n)). (My point: He knows about red-black trees, but was surprised the original C++ foundation library did not include a hash map with O(1) lookup!) Really: He would have failed an interview from this person based upon "fundamental CS concepts". Any software engineer, no matter how smart or experienced, has some weak spots in their fundamentals.
This is a strawman. Implementation details of a specific language library are not "fundamental CS concepts", unlike the specific topics I was talking about.
If you're hiring a C++ expert, then yes, not knowing the difference between map and unordered_map would likely be a disqualifying condition. We are not talking about C++ expert interview though.
> why are we not testing for that iceberg, instead just scratching the surface
Typical interview loop includes more than 1 question.
> how many times does a great engineer need to prove that they understand fundamentals?
This is a logical fallacy. The interviewer doesn't know if the interviewee is a great engineer or not, that's the whole point of doing an interview in the first place.
