Live data from Hacker News

Why I Don’t Talk to Google Recruiters

yegor256.com

261–270 of 674 posts

Re: Why I Don’t Talk to Google Recruiters

#261

There is no point in giving me binary-tree-traversing questions; I don't know those answers and will never be interested in learning them. Let's presume this is out of preference and not ability. It's a pretty basic concept. If your preference stops you from learning something as basic as this as a programmer, then it doesn't seem likely that you will be motivated to keep up with even more abstruse concepts. Nearly e…

Conjecture: the majority (by far, probably on the order of 75%-80% or more) of programming and engineering problems to be solved in a typical company or typical application will not see significant differences in performance by selecting a naive implementation.

For example, in your string concatenation example, the naive solution is good enough except in situations where large numbers of strings are to be concatenated in a given run, or the strings are huge, etc., relative to the compute environment. Does it really matter if one uses an O(n^2) solution when a few dozen (or even a few hundred) such operations are applied on "small enough" strings in a given execution on modern computer hardware? No, it just doesn't.

Select candidates who are keenly interested in and knowledgeable about algorithms for positions where it's important (i.e. part of the regular course of development), not because of that slight chance there is one edge case where one adjustment to a more efficient algorithm might possibly be useful at some indeterminate point in the future.

Re: Why I Don’t Talk to Google Recruiters

#262

There is no point in giving me binary-tree-traversing questions; I don't know those answers and will never be interested in learning them. Let's presume this is out of preference and not ability. It's a pretty basic concept. If your preference stops you from learning something as basic as this as a programmer, then it doesn't seem likely that you will be motivated to keep up with even more abstruse concepts. Nearly e…

>Let's presume this is out of preference and not ability. It's a pretty basic concept. If your preference stops you from learning something as basic as this as a programmer, then it doesn't seem likely that you will be motivated to keep up with even more abstruse concepts. This same exact argument could be used to require every interview candidate to know assembly. >and the person who likes to think about such things…

> This same exact argument could be used to require every interview candidate to know assembly.

Yes, and that argument could be used to require every interview candidate to know quantum physics.

At some point you draw a line, and Google/Amazon/Microsoft/etc. have very clear pictures of where their respective lines should be. It seems to work well for them.

Re: Why I Don’t Talk to Google Recruiters

#264
post #149

Earlier quoted context omitted.

I've been a developer for 30 years, helped start a half dozen companies. Since college I've never written a single tree traversing algorithm, and would need to Google red-black tree to know what it is. There is a whole world of development that is OS specific, UI specific, shipping commercial applications. Shipping quickly is always a higher priority than performance, because adequate performance is usually trivial t…

I'm not entirely sure adequate performance is good enough when you work at the scale of Google...

That's right. Adequate performance will keep 1000's of extra cores burning cycles 24 hours a day.

Re: Why I Don’t Talk to Google Recruiters

#265
post #241

There is no point in giving me binary-tree-traversing questions; I don't know those answers and will never be interested in learning them. Let's presume this is out of preference and not ability. It's a pretty basic concept. If your preference stops you from learning something as basic as this as a programmer, then it doesn't seem likely that you will be motivated to keep up with even more abstruse concepts. Nearly e…

In every single company I've been for the last 15 years, I haven't had any algorithmic problem to solve, most programmer jobs is just making software as quickly as possible and fix performance issues only when they appear. I really don't think that every programmer in Amazon or Google is faced with algorithm problems everyday, that's probably localized to some projects that deal with those, not the majority of progra…

I agree. Most companies SAY they want algorithm experts and API ninjas, and computer science wizards, because it sounds like the right kind of thing to say. But most of the actual work out there is either 1. plumbing some data from one layer in the stack to the other (typical CRUD app) or 2. writing glue code to integrate one vendor's middleware to another vendor's middleware, or 3. fixing bugs in some 10 year old legacy application, or if you're lucky, 4. getting an application to work barely well enough in order to ship it on time. An in-depth knowledge of traversing binary trees is not required for any of this stuff.

Re: Why I Don’t Talk to Google Recruiters

#266
I think the recruiting process is designed to minimize type II errors (false negatives), namely someone who passes the process but would later turn out to be a bad recruit. Inevitably, the type I error (false positives) grows, those who are good but rejected in the process.

I don't understand this risk averseness in the recruiting process by the employers. Especially, in countries with favorable dismissal laws for employers.

Glad to see that someone puts condition on the interview process and doesn't submit to their rules.

Re: Why I Don’t Talk to Google Recruiters

#267

Earlier quoted context omitted.

I've been a developer for 30 years, helped start a half dozen companies. Since college I've never written a single tree traversing algorithm, and would need to Google red-black tree to know what it is. There is a whole world of development that is OS specific, UI specific, shipping commercial applications. Shipping quickly is always a higher priority than performance, because adequate performance is usually trivial t…

>because adequate performance is usually trivial to implement with hash tables/arrays/linked lists Are you sure about that? What if your code has to work for billion plus people correctly 99.999% time who are on all different kind of connections?

Correct is orthogonal to performant.

I would also argue that make a very clever algorithm do correct stuff (and be maintained to do that in the future) is more difficult than do it using simpler method/algo.

Re: Why I Don’t Talk to Google Recruiters

#268
post #86

I like how every week one of these posts comes up. So many posts telling the world that they don't want to be the algorithm guy--the world doesn't care. Forgetting the Maxim: "Not everyone gets to be an astronaut when they grow up." https://cdn.shopify.com/s/files/1/0535/6917/products/potenti...

But an "algorithm guy" kind of IS the astronaut, no? Most work is line of business, CRUD, wiring up web forms, etc.

Re: Why I Don’t Talk to Google Recruiters

#269

Earlier quoted context omitted.

I think you're misquoting the article, and the "Dunning-Kruger" is uncalled for. Here's the full quote: > If she would have started her email with "We're looking for an algorithm expert," we would never have gotten any further and would not have wasted our time. Clearly, I'm not an expert in algorithms. There is no point in giving me binary-tree-traversing questions; I don't know those answers and will never be inter…

> We should avoid the notion that naive string concatenation is a problem that impedes our ability to deliver software, except for niche applications, this is not the case. The attitude that really basic Computer Science concepts like algorithms and algorithmic complexity are irrelevant is exactly why software projects are so frequently FUBAR. The Dunning-Kruger reference is spot on. The original author doesn't even…

Can you provide an example of an open source code base which is messed up due to ones inability to understand algorithms?

Re: Why I Don’t Talk to Google Recruiters

#270
post #76
post #9

I've turned down actual offers because even some medium-sized companies won't tell you which team you'll be working on when the offer is extended. I get that things can be fluid, but its such a meat machine.

That is when you know they just see you as another cog.

These perspectives are very negative. An alternative view is that there are tons of interesting problems and projects and applications to be worked on, and to some degree at least you get a say in which ones you work on.
Post reply on HN