Hacker News Reader

Comment by josh2600 | Hacker News Reader

Just to add some thoughts here: I’ve interviewed people who were google L7+ (IC) a couple of times who weren’t very good engineers, at least on the work sample stuff.

I’ve found that the highest correlation to performance in senior engineers is raw algorithmic skill and willingness to say “I don’t know” when you don’t know.

This is not true of hiring devops or sre’s. For those positions, you want the gopher archetype. This is the person who loves hunting down weird behavior and doesn’t give up when debugging. Let’s be real, debugging is you versus the machine and you’re eventually going to win if you can just be honest and patient.

Hiring senior engineers is really hard, I wish everyone luck.

View on HN

If you're asking questions related to "raw algorithmic skill" you're filtering for people who either: 1) Have had a computer science education and happen to remember the algorithm at hand. This is also a function of recency so senior engineers are less likely to remember any given algorithm. 2) Study algorithms so they can do well at job interviews.

Neither one is something you want to be selecting for. Some of the best engineers I've worked with haven't had a proper CS education. I've known extremely strong engineers with Neuroscience, Mathematics, Physics and Public Policy degrees. I've got a business degree.

Unless you're working in certain extremely hard (and extremely rare) areas you do _not_ need to filter for algorithmic skill. Most ML doesn't count. Neither does Data Science. In 99% of engineering jobs it's more important to be diligent, rigorous, and organized. (Of course, filtering for those is another issue altogether)

Spot on. The reasons are exactly right too; seniority and "ability to recall obscure minutia from college years" are inversely correlated, for obvious reasons.

Companies need to understand that not only are they mis-selecting, but they're broadcasting that they're doing so to all the candidates that go through that process.

Approaching candidates with textbook-style algo or data structure questions merely informs that they're going to be working with an educated but overall somewhat junior lot. That's not necessarily always a deal killer, but it's probably not the image that these interviews are hoping to project.

For well-qualified candidates not applying at an industry headliner like AppAmaGooBookSoft, the interview process quickly inverts itself, and it becomes more about the company selling the candidate on their offer than the candidate selling the company on their skillset. Tread carefully.

The only people that say that a CS education doesn't make you a better programmer are people without a CS education.

CS is not programming just like 99% of musicians don't have music theory degree.

It's probably a great analogy because the best musicians all know basic music theory, whether they learned it in school or on the bandstand. As for the advanced theory that they teach in graduate programs, it isn't even applicable to most genres of music.

> the best musicians all know basic music theory

Do you have any evidence for such a bold claim or is this just speculation?

They might know it instinctually but Funk brothers / James Jamerson (the bass player on a lot of Motown) didn't go to uni to study music.

Interesting analogy.

I bet there's scope to twist it beyond all sensible bounds, and compare the ability of the 99% to the 1%.

I suspect there's top level classical, jazz, and session musicians - who're the industry equivalent of 10x programmers. (And all the other stereotypes probably exist too, I bet there are occasional untrained but gifted musicians who can produce 10x output, but who're amazingly difficult to collaborate with compared to degree level music theory trained musicians... And I bet there are "10 year" musicians with one years experience repeated ten times over.)

The other interesting point there is that probably 99% (or more for, five, perhaps six nines) of "programming" doesn't actually require that much hard-core CS theory. You can get paid well playing covers in bars with a good ear and not being able to read a single note from a chart, just by listening to the originals and copying them over and over in your bedroom. Same as you can make a decent living building basic CRUD websites/apps without having written your own compiler that can compile itself or defended a phd that advances humanities start of the art understanding of something fundamental.

The only problem at that level of musician ship you lose the fun and can end up with some very sterile music that's only of interest to other people who have degrees in music theory.

Btw years ago I did work with a top session guitarist (top 10 hits) who after an accident taught himself to program from his hospital bed.

Good thing parent didn't say that then.

> If you're asking questions related to "raw algorithmic skill" you're filtering for people who either: 1) Have had a computer science education and happen to remember the algorithm at hand.

Probably true. But perhaps that could be accounted for in the assessment process. After all graduates from Neuroscience, Maths and Physics degrees have got to be some to smartest people around.

Agree. A lot of coding is simply banging your head against the wall, search SO over and over, changing things around, until it does what you want.

Raw algo quizzing skill isn't necessarily the same thing, though you'd think it was somewhat related because when you're learning to code up "find longest continuous run" you also need to change things around for a bit.

Difference is in real life there's never an end. The algo quiz leaves you at some optimum eventually due to being quite a small thing.

Coding is the easiest part. Understanding the actual problem and solving it is the hard part.

> A lot of coding is simply banging your head against the wall, search SO over and over, changing things around, until it does what you want.

It doesn't look like programming to me. Yes, sometimes we miss something, so our code doesn't do exactly what we want it to do, but when we realize it we just fix the code. This view of coding resembles an improved way to write Shakespeare with monkeys.

> A lot of coding is simply banging your head against the wall, search SO over and over, changing things around, until it does what you want.

I don't find myself in these situations nearly as often as I did back when I was a junior engineer. But damn, I'm sure I looked busier (and more stressed out) back then.

I was mostly through that phase of my career before any of those things were available. Toward the end of it, stack overflow had just launched. I mostly relied on printed books for help with languages and frameworks I was using.

the ability to prepare for an interview is likely correlated to the ability to do the required work, so that point is moot.

It's not correlated at all. I can ask you questions about implementing a b-tree and then give you a job to fix CSS. Which is the case in most jobs and job interviews.

if you were able to prepare for the btree stuff, the css stuff will be a joke to learn. that is my point.

Algorithmic ability has no correlation to the ability to write maintainable code, though. Most time at work is not spent demonstrating ability to regurgitate algorithms.

> Algorithmic ability has no correlation to the ability to write maintainable code, though.

This is not true in my experience. I usually see a strong correlation between algorithmic ability and writing maintainable code. At various organizations I have worked for, I have seen that the ones with strong algorithm skills also happen to be critical thinkers who put a lot of emphasis on simple, elegant, and robust design and code.

So I am very surprised to know that this correlation I observe may not be true in general. How did you come to this conclusion?

I don't have data but my impression is that there is an inverse correlation. My guess as to why is that people with ability to manage a lot of algorithmic complexity don't seem to suffer when code is complex so they see no need to simplify things.

I'm afraid I can also only offer anecdata. Mine is based on hiring and then working with dozens of SW engs since 2008 (my first tech lead role), plus our student Incubator and open source projects (dozens of more junior devs).

The correlation between emphasis on simple, elegant design and code and algorithmic chops is indeed uncanny.

And I'd add "clarity of articulation" to that -- being able to express your thoughts and the problem/solution structure clearly and succinctly is a great indicator as well. Huge overlap with both code maintainability and algo quality.

I haven't seen this ever. Algorithmic skills have never been correlating with productivity or maintainable code in any of those 7 companies I worked in.

No causation, I'd believe any day. But correlation? I'd want to see a statistically rigorous test done before I'd believe that. Correlations are everywhere and pretty much all good traits are correlated with each other. Hell, even vocabulary size and reflex speed is correlated. And this is probably why even terrible methods for selection usually kind of work.

Unfortunately, often (and maybe more so because I live in Europe) it's also the other way round:

> raw algorithmic skill

It's been ages that I've been asked anything remotely algorithmic. My interviews are mostly about frameworks, how you fit in a team and whether you know / can be "agile".

Not even a Fizzbuzz, much less so quicksort or more special algorithms.

> and willingness to say “I don’t know”

That never got me anything in any interview/company. To be fair, I found a few smart and cool friends because of this, but they themselves don't look as if they've found a good job either.

Being hired (valued?) as a senior engineer is really hard.

It really depends on your domain. If you're into low level hacking and distributed systems, there is a lot more algorithmic work. There is demand for software that's cheap to scale and/or low latency. Some fields are bottlenecked by hardware (machine learning, realtime rendering, etc.) and so benefit from better software. Some production systems still need a large amount of optimization to satisfy economic and product constraints.

I don't think the number of jobs requiring fairly deep systems or algorithmic knowledge has gone down, but the ratio has.

I’ve had trouble finding those systems or algorithmic jobs too, like the grandparent, where some kind of engineering quality matters, be it performance or correctness or something. Everyone wants to hire a “full-stack engineer” to write application code that a junior dev could write, but they want someone senior anyway.

I once had a FizzBuzz question in an interview, The interviewer started, I interrupted him, "We are not talking about FizzBuzz, are we?". He apologized afterwards by saying that there was actually on applicant some time ago, writing 100 printfs.

Why doesn't the gopher archetype also apply to development roles? Persistence pays off if you measure your own results. Knowing how to divide a problem is really important, even if you're great at algorithms.

While persistence is good, it has to be applied correctly. It can become the opposite problem as stubbornness, spending too much time in a small thing that is not actually that relevant because the person really wants to get it done.

More important than persistence IMHO is to know when to be persistent and when not, and those two qualities by OP seem to be quite related to it: "raw algorithmic skill" (to know whether something is optimizable or not) and willingness to say “I don’t know” when you don’t know" (seek help, get the right person for the job, etc).

Edit: I know because I was like that in the beginning; it was okay to learn e.g. micro optimizations when learning programming for fun at university, but it'd have been a big issue if I had not been able to correct it.

I can’t overemphatize how much persistence really paid off in past jobs I had. Coworkers that had persistence were such a delight to work with because they didnt give up the first time they got stuck. They did the nitty gritty work of tailing/grepping logs, using a debugger, endless Googling, print statements, and anything to find out the root cause of a bug... or even to understand a legacy codebase.

It's probably such a delight in part because bright kids are frequently not persistent. They are used to things coming easily. If it doesn't come easily, many are quick to throw in the towel.

Someone who is both bright and persistent can move mountains. But it often has a big social downside. People don't like change. Being bright, persistent and also socially savvy enough to sidestep drama is practically a unicorn.

I've done that sort of work. Eventually you realize that nobody notices the guy who tracked down and killed that vexatious heisenbug in the legacy code base. You need to be working on the new, shiny, high-visibility projects or your career is going to stagnate.

Or change the culture.

Friday demo day (to sales and cust success and everyone else): "hey everyone, know that thing customer X keep complaining about that we've never been able to solve? It's been super tricky. Just wanted to announce that James here figured it out and it's fixed forever. James you're a hero."

Guess what you need strongly depends on what you are hiring for.

Being good at alghorithms only is great if you work in a very isolated area.

Saying “I don’t know” is also very important for devops people, but for slightly different reasons; we’re likely to have a little bit of knowledge about everything, and it’s import for us to be explicit about where our expertise dries up.

I say a lot of things in the form “I’m a little out of my depth in this subject, but my best understanding is that the behavior should be such-and-such; does that sound right to you?”

i dunno. the machine has beaten me more more times than i care to admit. some problems are hard.

i’m L7.

Honestly speaking, since it's an anonymous forum, what's the difference between L5 and L7? Like if I was asked the same question - the difference between L3 and L5 - I'd say that it's just experience with a few interesting known projects that's paid so much better, while the cognitive ability is the same.

Could you give a short explanation of what this L3/L5/L7 thing is?

I'm assuming you're not talking about spinal cord problems, which is the main search result.

I think [1] gives an explanation of it.

[1] https://levelsfyi.com/google-levels-salary/amp/

EDIT: found a better source

Hey I'm from www.Levels.fyi - this is exactly what our site was built for. The link above is a copycat site and you can see the latest leveling info / compare with other companies on ours.

Bound to happen when you call yourself techslave ;)

There’s a reason google doesn’t hire into L7, it’s because their hiring process for algorithms is garbage and provides lots of false positives and negatives when you are looking for real skills.

If saying “I don’t know” and being good at algorithms was enough, you could hire straight to L7 easily or could promote to in a year. Neither of these things happen.

Reply on news.ycombinator.com