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