Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I Don’t Talk to Google Recruiters

yegor256.com

Post reply on HN
Print view View original

571–580 of 674 posts

Re: Why I Don’t Talk to Google Recruiters

#571

Post by elliotec »

walshemj wrote: post #474
DonHopkins wrote: post #387

Earlier quoted context omitted.

Since Google is an advertising company that even hires their own chefs, I would not expect 100% of their employees to be software developers. It's more on the order of 20k developers, not 57k. https://www.quora.com/How-many-software-engineers-does-Googl... >Have you found any correlation between poor code and being able to pass Google's interview ? cough cough Angular 2

Back in the day I worked for a company that had in a single division more engineers that google has employees :-)

Who? IBM?

Re: Why I Don’t Talk to Google Recruiters

#572

Post by Trundle »

HarryHirsch wrote: post #465
joshuakarjala wrote: post #372

Earlier quoted context omitted.

Keep in mind - the CEO in question could be writing personal e-mails out from an ATS / Sourcing tool that helps keep track of communications. Tracking links are not always == shotgun approach

Tracking links are always extremely bad form, though. I'd be interested in hearing from the other side, though, why such behaviour would be considered acceptable.

I think of acceptable behaviour in terms of a blacklist rather than a whitelist. I don't have a problem with tracking links because I don't see a reason to have a problem with tracking links.

Re: Why I Don’t Talk to Google Recruiters

#573

Post by attractivechaos »

nulagrithom wrote: post #437
attractivechaos wrote: post #313

Earlier quoted context omitted.

Details do not matter until they show up. Still take string concatenation as an example. Suppose you want to highlight some particular words while a user is actively typing characters in a dialog. If you naively concatenate every character, the user may have responsiveness issues or at least wastes CPU cycles/battery unnecessarily. Small cases like this add up in a big project. My conjecture is that a big fraction of…

I tend to run in to more critical issues than performance, like shipping the product/feature at all, meeting deadlines, writing maintainable code, and writing documentation. In your highlighting example, instead of working with someone who will optimize, I'd much rather work with the guy who will realize we can just debounce the dialog, write a one line comment about the performance issue, and then move on to the nex…

> In your highlighting example, instead of working with someone who will optimize, I'd much rather work with the guy who will realize we can just debounce the dialog, write a one line comment about the performance issue, and then move on to the next thing.

As long as you are aware of the issue with naive string concatenation, you can use a string buffer or a mutable string – it is trivial to solve in a few more lines of code. What's more difficult involves deletion in the previous text. If this happens often, you will need rope or skip list, which is challenging if you implement from scratch. In the latter case, I would leave a comment without implementing the optimal solution and let the profiler decide later.

Re: Why I Don’t Talk to Google Recruiters

#574

Post by stcredzero »

mbrumlow wrote: post #121
stuckagain wrote: post #8

> 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. Interview process: complete success.

Maybe, or maybe they are missing out. Binary-tree traversing is a rote memory sort of thing. Somebody who can come in and play 20 questions about an algorithm and answer them perfectly shows me nothing other than they studied that algorithm and have a good memory. It does not show me any insight into how they solve problems which have not already been solved for them. It won't show me how they do under stress with a…

Binary-tree traversing is a rote memory sort of thing.

But the real value is in being able to analyze an application's performance and deal with concepts like recursion.

I also feel that anybody who has actually been productive on a large successful project does not have time to commit to learning things that can be looked up when needed.

Some important concepts aren't the kind of thing that you "look up" then read a one paragraph blurb for 3 seconds. The pitfalls of concurrency and the pitfalls that ACID transactions are supposed to protect against are two more examples.

Re: Why I Don’t Talk to Google Recruiters

#575

Post by [deleted] »

chadgeidel wrote: post #426
lwhalen wrote: post #407

Earlier quoted context omitted.

I take it one step further: the email address on my resume is a black hole. Its only purpose is to feed an autoresponder who kicks back a warm, generic, email thanking the recruiter for their time, acknowledging they have a difficult job, and lays out my requirements for any position: what I am and am not interested in doing, my salary/hourly/per-project requirements, my location requirements (100% remote), etc. At t…

I'd pay at least a few dollars per month / tens of dollars per year for this service. I'm not kidding. Dear HN reader, please steal this idea!

[deleted]

Re: Why I Don’t Talk to Google Recruiters

#576

Post by ryandrake »

yareally wrote: post #525
ryandrake wrote: post #513

Earlier quoted context omitted.

Incredible--would you mind sending me your LI profile (privately of course, email in my HN profile)? I'd love to see an example of a profile that generates that much interest, even if it's mostly low signal.

Maybe I am mistaken, but I thought that much recruiter interest on linked in is pretty typical. I live in the Mid Western United States and what was previously mentioned is also true here from my observations. Most of it comes down to having the right keywords and tags I believe. Having .net/java/mobile in your profile nets a lot of messages where I am. Words like Scala/Python/Node/Ruby/etc gets you a bit more. 80% o…

Interesting. I suppose if I were to ever get 20+ recruiter contacts per month I would retract my previous comment about replying to each of them being cheap time-wise.

Admittedly, I'm not in the market for a developer position, and I deliberately down-play my development experience in my profile, which probably reduces my contact count substantially. I should conduct an experiment wherein I stuff my resume and LinkedIn profile with programming languages and framework keywords for a month and record whether it has an effect on recruitment volume. I suspect it would.

Re: Why I Don’t Talk to Google Recruiters

#577

Post by zedadex »

pucado wrote: post #460
bluebomb wrote: post #439

Earlier quoted context omitted.

then we make them go through an animated slideshow and do a quiz to get to an email address

And when that gets rigged by some wicked OCR, then a Super Mario simulation where the princess is the realdeal@email.com, and every 10 coins or every level would get them an additional resume-info nugget to consume. Okay maybe I took it too far.

Turns out Bowser was just trying to hire a competent plumber.

Re: Why I Don’t Talk to Google Recruiters

#578

Post by stcredzero »

iamleppert wrote: post #328

I'd also like to add my own experience dealing with recruiters from Amazon, Facebook, Google, Netflix. They are liars. They most definitely will e-mail you whatever it takes to get you into the first part of the funnel. They'll tell you its a "special project" or try and make it seem like somehow you're exactly what they are looking for. It's not true; I've been down the route a few times and have easily been able to…

No, you don't need this knowledge (unless specifically required) to be effective at your job despite what others here are posting on about.

Pretty much like how the Asiana Airlines pilots didn't really need to know how to manually land a plane.

https://en.wikipedia.org/wiki/Asiana_Airlines_Flight_214

Re: Why I Don’t Talk to Google Recruiters

#579

Post by stcredzero »

alistproducer2 wrote: post #64
stuckagain wrote: post #37

Earlier quoted context omitted.

I don't know about the average but at Google I probably write a new call to std::set::find twice an hour, and it's important to know that std::set is a red-black tree, and how std::set::find is implemented and how much that costs and so forth. Fluency with data structures and algorithms is not some kind of brain candy. It's absolutely necessary to get the job done.

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.

Re: Why I Don’t Talk to Google Recruiters

#580

Post by ivraatiems »

munificent wrote: post #539
ivraatiems wrote: post #319

Earlier quoted context omitted.

Speaking as someone who's done these interviews (but was never, for the record, asked about anything other than coding/algorithms): I think the core premise is flawed. The idea that a good developer is somebody who can regurgitate knowledge they learned on Wikipedia in a few hours from memory is just not a good base for determining if the engineer is good. More importantly, a developer who cannot regurgitate the know…

> The idea that a good developer is somebody who can regurgitate knowledge they learned on Wikipedia 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 don't know to what degree that's true, but it's how I assume they arrived at the current interview process.) > More importantly, a developer who cannot regurgitate th…

> 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 is skewed to avoid the latter even if it costs the former.

This is an oft-repeated line about Google's hiring process, and in fairness, I think it's oft-repeated because insofar as it reflects Google's belief that their process results in good developer hires, it is true.

However, my suspicion is that the phenomena going on here is not "losing out on some, but not all good developers in order to weed out bad ones," rather, it's "losing out on a certain kind of good developer in order to weed out bad ones." 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 don't have the two segregated into neat categories - because this is just a suspicion, based on people I know who work at Google, and my own experiences - but I think it's roughly along this line: Developers in category A have an innate desire to learn about and understand computer science on a theoretical level, as much as or moreso than a practical level. Such a person may or may not enjoy building things as much as they enjoy learning about how to possibly build things. Developers in category B (I'd include myself in that group) don't care about theory as much as practice; they do what is necessary to get the job done. Now, neither group hates theory or practice, they just have preferences about which one to spend their time on.

For an organization to really be successful, I'd argue, you need a mix of types A and B (tending more towards one or the other depending on the type of entity). If Google is weeding out most or all of type B, they are doing themselves a disservice - and I would argue that insofar as many of the common complaints about Google (services created then abandoned, poor support, poor attention to bugs/issues, etc.) are true, if this theory is also true, it would help explain why. The practical-preference developer wants to make things work and keep them working; the theoretical-preference developer wants to discover new things and constantly expand her knowledge. Both aims are good, but you cannot have one to the exclusion of the other as an organization.

Post reply on HN