Live data from Hacker News

Why I Don’t Talk to Google Recruiters

yegor256.com

601–610 of 674 posts

Re: Why I Don’t Talk to Google Recruiters

#601
post #472

Earlier quoted context omitted.

Have you ever actually got a job that you accepted through this method? Also, what wizardry did you use to get 200+ recruiter E-mails a month? Do you just have a highly optimized resume out there on all the job sites or something?

I get between 30 and 50 a month and all I really did was setup a linked in profile.

can you send me the link to your profile, i'd like to increase the interest on mine

Re: Why I Don’t Talk to Google Recruiters

#602

Earlier quoted context omitted.

> I don't think Google's hiring people thing that that's what a good developer is, as much as they think it positively correlates to good developers. I agree. However, I think they are wrong... I'll expand below. > This is also a valid concern, but Google is much more concerned about false positives than false negatives. Missing out on a good candidate is a bummer. Hiring a bad one can be a nightmare. So the process…

> That is, I'd conjecture that the good developers who can (or want to) memorize algorithms and regurgitate basic CS knowledge are one kind of capable dev, and the good developers who rely on tools to a greater degree are another kind of dev. Call them types A and B. I really dislike this characterization. I'm a googler. I've never tried to, or needed to, memorize algorithms. I don't know if this characterization com…

We have something interesting here, in that I'm looking at this from the perspective of someone the Google system rejected (and who later decided/rationalized/realized participating wasn't really worthwhile) and you're looking at it from the perspective of somebody it embraced.

Naturally, it wouldn't boil down so easily in practice to these two types, even if they are the correct ones. Everybody is a mix of both (and plenty of other things); plus, we have to assume that, like you say, occasionally somebody incompetent or strongly type B "cheats" the system and gets hired.

But I guess the question is: How, to you, does "selecting for people who can solve unfamiliar, complex, problems by applying first principles" not seem to jive with my definition of category A?

Re: Why I Don’t Talk to Google Recruiters

#604
Another data point of ridiculousness:

I fairly often receive emails from recruiters who have 'read my profile' and found me to be 'a great fit' for some 'senior ...' role.

Had they actually read my profile, they'd have found me to be a student, who's only relevant experience is as an intern, and has accepted an offer for a graduate position.

Certainly not a fit for senior anything, but it makes me wonder how far it would go if I replied OK - do companies using these recruiters get hopelessly underqualified candidates to interview on a regular basis, and still stick with them?

Re: Why I Don’t Talk to Google Recruiters

#605
post #479

Earlier quoted context omitted.

You must mean "some software projects" and not "frequently." In the 2000's and prior, it was common knowledge that the majority of software projects failed. Even if they succeeded on paper and shipped, they weren't actually used. By some estimates, it was something like 75% of software projects. If you look at the contents of "ecosystems" like Steam and the the various app stores, you'll see much the same. Most of th…

Do you have a citation supporting the claim that those failures were due to poor performance and not far more significant problems like failing to correctly model the actual business problem or handle changes? That era was dominated by waterfall development which is notoriously prone to failure due to the slow feedback loop. This is highly relevant because one not uncommon problem with highly-tuned algorithms is the…

> Do you have a citation supporting the claim that those failures were due to poor performance and not far more significant problems like failing to correctly model the actual business problem or handle changes?

"Poor performance" isn't the only negative result of using an insufficiently experienced developer, or a developer who doesn't have a full grounding in algorithms and data structures.

Someone without a full CS background (and without the ability to remember much of that background) is likely to know a few patterns and apply them all like a hammer to a screw. This leads to profoundly terrible designs, not only when you take performance into account, but finding the best model for the actual business problem, handling changes, permuting data in necessary ways, and other issues.

> That era was dominated by waterfall development which is notoriously prone to failure due to the slow feedback loop.

Extreme programming was the first formalized "agile" approach, and the very first agile project to utilize it was a failure. [1] A big problem was performance, in fact:

> "The plan was to roll out the system to different payroll 'populations' in stages, but C3 never managed to make another release despite two more years' development. The C3 system only paid 10,000 people. Performance was something of a problem; during development it looked like it would take 1000 hours to run the payroll, but profiling activities reduced this to around 40 hours; another month's effort reduced this to 18 hours and by the time the system was launched the figure was 12 hours. During the first year of production the performance was improved to 9 hours."

Nine hours to run payroll for 10,000 people. We're not talking about computers in the '70s with magnetic tapes. This was 1999 on minicomputers and/or mainframes. If that wasn't a key algorithmic and/or architectural problem, then I would be amazed.

When you're designing a system using agile, it often ends up with an ad hoc architecture. Anything complicated really needs BOTH agile and waterfall approaches to succeed. You need to have a good sense of the architecture and data flow to begin with, and you need to be able to change individual approaches or even the architecture in an agile manner as you come across new requirements that you didn't know up front.

> This is highly relevant because one not uncommon problem with highly-tuned algorithms is the greater cost of writing that faster code and then having to change it when you realize the design needs to be different

I'm going to say [citation needed] for this claim.

I gave an example in another thread of having improved the speed of a game development level compiler tool by a factor of about 1000, with no major architectural changes, and it took me about an hour.

At the same time I performed a minor refactor that made the code easier to read.

Bad design == Bad design. That's it. Good design can include an optimized algorithm. A good design tends to be easy to extend or modify.

Very rarely it makes sense to highly hand-tune an inner loop. The core LuaJIT interpreter is written in hand-tuned assembly for x86, x64, ARM, and maybe other targets. It's about 3x faster than the C interpreter in PUC Lua, without any JIT acceleration. That is a place where it makes sense to hand-tune.

> pride + [sunk] cost[s] leads to trying to duct tape the desired feature on top of the wrong foundation

That's another orthogonal error. It makes me sad sometimes to throw away code that's no longer useful, but I'll ditch a thousand lines of code if it makes sense in a project.

Every line of code I delete is a line of code I no longer need to maintain. I'm confident enough in writing new code that I don't feel any worry about deleting old code and writing new. This is as it should be. Sad for the wasted effort, yes. But I know that the new code will be better.

[1] https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compens...

Re: Why I Don’t Talk to Google Recruiters

#606

Earlier quoted context omitted.

one does not need to know how to write an algorithm on a white board to understand it. Seems like it would better to ask what a red-black tree is, what's it's time complexity, and what would be a good situation to use one. In fact, I would argue that one could know how to write one and have no idea of the practical use of it.

It pretty much has no practical use, that a different data structure couldn't do more efficiently.

What in the world are you talking about, RB trees are incredibly useful.

Re: Why I Don’t Talk to Google Recruiters

#608

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…

I agree. Personally, I'm a bit horrified at the idea that someone who wants to be an "expert at object oriented design" would turn up their noses at "binary-tree-traversing questions". It sounds like a formula for aspiring Architecture Astronauts. It's also not realistic, given the wheat-to-chaff ratio out there, for a manager to interview all the candidates directly without an elaborate screening process, although t…

This sort of invites the question of what you WOULD be interested in working on (and what size team you've been leading) if you were to consider leaving.

Asking as a Googler who occasionally gets to dream up a neat trick here or there (and leads a team of pretty clever people, too!).

Re: Why I Don’t Talk to Google Recruiters

#609

Earlier quoted context omitted.

The problem is that what interests you now may not be economically valuable next year. They want you there past one project, because the future is too murky to guarantee your current role will continue to be needed. Google et. al. are hiring generalists because they want people of a mindset such that when the entire special-purpose they hired them for dissolves, they're willing and eager to ramp up on a new project a…

You are taking a much too narrow view of "specialization". If project foo is really the only project at Google that uses the skills I like and know best, I am probably not going to apply there. I get that there are people who don't care (much) what kind of code they are working on. If those are the people Google exclusively wants, that's fine. I just won't have a place there. I do not think this is a generally-advisa…

The funny part is that for all the work Google has done building a hiring process that searches for talented generalists, the actual work they have to offer is really boringly specialized. Most of what's going on in there is just stacks upon stacks of web-service middleware, endlessly slinging RPCs back and forth at each other. If that's your bag, then yay, Google is a great place to work! - but for me it was really discouraging to realize, four months in, that no more than ten per cent of Google was doing anything I was ever likely to care about. I didn't last long, and wouldn't go back (not that they'd be likely to want me).

Re: Why I Don’t Talk to Google Recruiters

#610

Earlier quoted context omitted.

My experience hiring at (YouTube.. at the google campus), was similar to the original post. 3 phone screens (which I must have done ok on), and then they flew me out to CA. I went through the interview process.. got tripped up on the 'puzzle' questions (which I thought was bullshit for a Python programming job.. but whatever), and then didn't get the job. I actually agree with what was said in the original post: this…

> However, I can tell you what definitely was a complete turn-off, > was the odd obsession of seemingly everyone there with where I/(you) > went to school. Ugh, that's really frustrating. I'd like to think they were just searching for common ground, but jeez. Candidates should be judged based on what they know, not where they happened to have acquired that knowledge. I am a college dropout and I had no idea what a ra…

"It's a weird bubble."

So you imply they're doing a bubble sort on candidates?

Post reply on HN