Hacker News Reader

No I don't. AT ALL. It sounds to me like you've never encountered actual challenging engineering problems. If you have had anything to do with 3GPP all the algorithms used in there are a lot more complex than these silly compsci interview algorithms. You don't really spend that much time thinking about things that should be considered basic vocabulary.

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.

> It sounds to me like you've never encountered actual challenging engineering problems

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.

It's one thing to visualize, another to recall at will. Your friend is someone whom you've spent sufficient time with on at least a semi-regular basis to form emotional and mental bonds with, deep memories. How many times does a CS undergraduate re-implement sort algorithms? Not that most interviews actually ask one to regurgitate that from one's memory.

> How many times does a CS undergraduate re-implement sort algorithms

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.

Describing or visualizing the algorithm is one thing.

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.

But being able to code up a bug free solution to a well defined problem seems very relevant to me when you apply to a software engineering job. If you can't do that then what can you do?

Sure, but the time limit and pressure of people looking over your shoulder are additional artificial challenges, unnatural stresses.

Perhaps one approach is to allow the interviewee some time to think it over themselves.

I think that part is to test soft skills, being able to work under stress and talk to a person is a part of being a good team mate. Straining both at the same time is a feature, since it is much easier to fake soft skills when you aren't distracted by a technical problem.

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.

There was a study conducted some time ago within the past year or so (it had a long discussion thread here, naturally) where it was discovered that when allowed to solve a whiteboard puzzle in a room alone, candidates performed far better. Now obviously communications soft skills must be tested. But perhaps the format can be tweaked so the candidate has some time to crack at a problem on their own prior to be asked to explain it.

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.

Looks like you haven't been through an interview loop lately.

I have. I just overdid the practice the first time and got good enough to place well in international competitions, so to me all these interview problems are really easy, I've never struggled with an interview problem since then (of course since I always pass there isn't much need to do many interviews so I have less data than some others). I know most people wont do that, but you don't need to be nearly as good at this to pass interviews so it should be possible to get good enough to never practice again with modest effort.

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.

So if you're good enough to do well in international competitions, why are you even participating in this discussion? You're clearly an outlier who finds this easy, so you're not in a place to understand the challenges for most people.

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.

But it takes like half a year to get that good, if you just practice a bit in college you get there. I'm not sure why people complain so much. People just need to stop memorizing and start practicing how to understand problems instead.

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

Your leetcode may be A grade but your empathy, self-reflection, and frankly critical thinking skills need a ton of work.

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.

As the person who replied to you says, you have a lot to learn about being a good, empathetic and kind human. I suggest for your own life you take some time to work on that if your technical skills are already good.

For better or worse, not everyone is autistic.

(According to one prominent speaker on the subject, Temple Grandin, this is an aspect of how autistic people tend to process things.)

I think it's easier to recall the "idea" of each algorithm, than visualizing the flow of the code. There's normally also some key implementation detail that's helpful to remember.

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.

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

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.