Identifying that you need to use some variation of that algorithm and then writing flawless and optimal code that handles all corner cases in a 20 minute job interview, is an entirely different thing.
Perhaps one approach is to allow the interviewee some time to think it over themselves.
It is much more stressful than a real work situation, true, but people work much harder to appear nice and helpful in an interview setting as well so having a harsher test than real world situations to test soft skills seems appropriate.
The "niceness" of the interviewers is irrelevant. The power differential at stake sparks a survival instinct that leads to stress. (e.g. they literally hold power over your future meal prospects.) Though perhaps in others, it invigorates them with a sense of purpose, cool, and collectedness. Perhaps that is truly the 10x engineer.
My Google interviews was basically me coding up a solution in 10 minutes and explaining what I did and proving it works with runtime etc. Then we spent the rest of the time talking about engineering problems, testing, what I did at previous jobs etc. I am rustier now many years later, but It is still good enough that I don't fail, it might take 20 minutes instead of 10 but there is still room to spare. So the limit is that you are maybe half as fast as I am when I'm rusty, doesn't seem like an overly high bar to me.
Not every great engineer can be good at this stuff to do well in international level competitions, by definition that's a very small group.
I assume you're not on the same level as William Lin or tourist, so it would be like them wondering why you struggle on a particular problem when they can do every one easily.
> I assume you're not on the same level as William Lin or tourist, so it would be like them wondering why you struggle on a particular problem when they can do every one easily.
Those have spent more than 10x as much time as me on that though. I got to my level in about 6 months that I spent to pivot from math to programming, that isn't unreasonable effort for anyone, most computer science grads have spent more time learning algorithms than I had.
If you had realized that
* in 90+% of job openings, whiteboard leetcode interviews optimize for the wrong thing, and neither the candidate nor the interviewer should be honored for its inclusion in the process
* live coding exercises are just as much an exercise in psychology - your willingness to submit to unreasonable demands and their willingness to subject you to them
* negative discrimination (i.e. weed out requirements) create biases in your hiring process and ultimately skill gaps in your personnel base
You would potentially be self-aware enough not to post this cavalier and self-aggrandizing comment.
(According to one prominent speaker on the subject, Temple Grandin, this is an aspect of how autistic people tend to process things.)
I also had countless experiences where I ended up either rewriting from scratch or massively refactoring code that was written by computer scientists that dumped all their algorithm ideas into code without understanding a thing about performance, the underlying infrastructure or how to trace it.
Your sorting algorithm will mean jackshit when you spend all your time doing I/O reading files in and out of memory for example. Your super cool distributed algorithm means nothing if you don't understand CPU P-States(I guess that's irrelevant nowadays) or NUMA and didn't setup the machine properly.
I for one have opted out of this BS and will actively avoid mediocre programmers trying to boost their ego with cookiecutter algorithm questions.
I worked on low level machine learning infrastructure and distributed algorithms at Google. I know pretty well what challenging engineering problems looks like.
> No I don't. AT ALL.
You don't think your inability to visualize computation affect your ability to come up with solutions to problems at all?
Edit:
> Your sorting algorithm will mean jackshit when you spend all your time doing I/O reading files in and out of memory for example. Your super cool distributed algorithm means nothing if you don't understand CPU P-States(I guess that's irrelevant nowadays) or NUMA and didn't setup the machine properly.
I understand those things well, it isn't hard to learn, we run benchmarks using proper prod setups and see what works faster and we know about CPU caches, memory overhead, file reading speed etc. The only difference is that I am fluent in algorithms and you aren't. I'm not sure why you'd think that I wouldn't know those thinks just because I know algorithms, it takes like a few months to master algorithms, there is still plenty of time to learn the other things.
Quicksort - pivot - i <= hi mergesort - merge - auxiliary array
When I started practicing DSA, I would code these algorithms from scratch ever week, to try and memorize them. Then as I did more general leetcoding, I realized that these are just solutions to problems, and there's no need to memorize the code exactly, just knowing the key idea is enough.
People dump on leetcode because they think it's memorizing solutions to problems, but it's not practical to do that. It's more like memorizing one sentence per problem, than memorizing a page of code. And when you see a new problem, you just adapt one of the "sentences" you memorized for a similar problem.
But if you've never looked at an efficient algorithm for dependency resolution, it's going to be impossible to come up with a good solution for a related problem in an interview.
Right, my pictures are what the code is supposed to do, not the code that is executing it. Then I can just take pieces of it and compose it with other things, you need some kind of intuition to do that, for me that intuition takes the form of pictures.
But yeah, the trick to solve leetcode properly is to not solve leetcode, but to learn to get better than leetcode, that way leetcode problems will feel trivial for the rest of your life.
You don't have to implement, you just need to know the theory of why it works. Then you just code it up based on that theory, it isn't hard to do at all.
For example, merge sort explains itself, you partition and merge. That is all you need to remember. Hashmap is the same, you use a deterministic function to label objects and then put those into buckets, then you find them in the bucket with the same label later. These are like the basics of the basics.