Live data from Hacker News

Why I Don’t Talk to Google Recruiters

yegor256.com

101–110 of 674 posts

Re: Why I Don’t Talk to Google Recruiters

#101

Unlike most of HN (it seems), I like hearing from recruiters, because despite the very low signal-to-noise ratio, there's always that remote chance that one of them could be able to set me up with a "dream job". It's zero cost to me to politely reply to a recruiter and ask for more info, and I try to at least respond to everyone. What I've found is that they must have a lot of candidates they're juggling because fall…

I make it a point to reply to recruiters. But there's many different types of recruiting email. I completely ignore (and sometimes even filter straight to the trash) blatantly shotgunned form emails.

If the email shows any effort whatsoever, mentioning a project I worked on, mentioning my current job, pointing out the role in question would fit my skills and it actually does, basically anything at all that suggests it's not just a form email sent to hundreds of people, then I will reply.

However, there's a third type of recruiting email that shows the person on the other side really is directly targeting you. It usually comes from the person who would be your manager, or at least someone who has a direct stake in the company (say the CTO or CEO at a small company). These emails I take seriously and appreciate. One of these led me to my current job.

Oh and I don't appreciate recruiting emails that have tracking links in them. Usually I will politely respond that I don't appreciate the tracking.

Re: Why I Don’t Talk to Google Recruiters

#102

Similar story: a few years back I was interested in applying to TopTal for side work. As a senior engineer working with well known companies, I thought the acceptance process wouldn't be as bad as claimed on their homepage. Passed the first personality interview. The second was a coding challenge. I said to the interviewer several times I have not studied algorithms, and that if the coding challenge involves them, I…

[deleted]

Re: Why I Don’t Talk to Google Recruiters

#103

Unlike most of HN (it seems), I like hearing from recruiters, because despite the very low signal-to-noise ratio, there's always that remote chance that one of them could be able to set me up with a "dream job". It's zero cost to me to politely reply to a recruiter and ask for more info, and I try to at least respond to everyone. What I've found is that they must have a lot of candidates they're juggling because fall…

I find these calls quite flattering. I haven't been on the market or done any computer consulting since 2013, but got a call from a recruiter just yesterday.

It's a little less flattering when they can't correctly pronounce my name or the state I live in.

Re: Why I Don’t Talk to Google Recruiters

#104

Earlier quoted context omitted.

You might not need to implement it, but you needed to know enough to know what an AVL tree is, why you might (or might not) need it, and to be able to do some basic validations on the library you selected to make sure that it does what you are hiring it to do.

agreed, but let's assume you don't know what an AVL tree is or what the trade-offs are between an AVL, red-black or other type of trees: how long does in this age to find that information if you know what you are doing? I mean, you could allow your interviewee access to a computer and based on the type of googling they do it should be fairly obvious if they know what they are talking about. In your day-to-day you hav…

> how long does in this age to find that information if you know what you are doing?

I think we're discussing fluency. If you are hiring someone to edit books written in English, do you want a person who has to look up the meaning of "present participle", or do you want someone who just _knows_ what it means? I am sure that most people can figure out what "present participle" means in a few minutes with a search engine but those aren't the people I want as the editor.

Re: Why I Don’t Talk to Google Recruiters

#105

Earlier quoted context omitted.

figuring out a cool algorithm is not the same as learning 1000 algorithms by rote to prepare for an interview. Just because doesn't feel like doing test prep for an interview, it doesn't mean they don't have the brain capacity to actually solve the business problem when it comes up. If in my day-to-day I need to use an AVL tree, I will get a library for it, I won't be reimplementing it from scratch every single time.

> If in my day-to-day I need to use an AVL tree, I will get a library for it, I won't be reimplementing it from scratch every single time. Completely agree. How will you know you need an AVL tree, versus, say, a Red-Black tree? What are the performance characteristics of each? Why pick one over the other? When I interview someone, I ask algorithm questions to find out how they reason about the algorithms, not so I ca…

OK, I'll bite: this is not something the vast majority of engineers ever need to know.

They are both balanced binary trees with the same big-O complexity. Constant factors are different, but if and when you care about that, they're both binary trees so it should be easy to switch one implementation for another. In practice you're unlikely to care because most of the time you won't be working on performance-critical code. All speculation about performance is hearsay unless you run some benchmarks.

Google search brings up this discussion: http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=s... There's plenty of interesting stuff there, but it rather reminds me of medieval theologians debating how many angels can dance on the head of a pin.

There's a much, much more important distinction: binary trees (of all kinds) versus sorted arrays. There are many cases where a std::vector will be a lot faster than a tree, due to cache coherency, and use much less memory too.

So, discussing AVL trees and red-black trees in an interview is a waste of time. All it tells you is whether somebody once studied them (and remembers their studies), or possibly just memorized them the night before. Knowing that somebody studied those algorithms (except you don't know, because they may just have crammed it) would be a positive signal but doesn't actually tell you whether their CS course covered useful up-to-date topics, like cache-friendly algorithms and data structures.

Re: Why I Don’t Talk to Google Recruiters

#106

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

Why do they try to "recruit" him in the first place, then, and "waste" recruiter time and phone-screen time on him and people like him? Remember: this isn't people applying to Google out of the blue: this is people Google has actively courted to apply . I did a couple rounds of their interviews a while back just to see if they really were as bad as people said they were (yup!). And that was in response to a very pers…

> It does include a lot of arcana about how web application stacks work, the network and gateway protocols they use,...

This was my second phone screen at Google, for what it's worth.

Re: Why I Don’t Talk to Google Recruiters

#107
post #71

> 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. They are just looking for smart people. If you ever looked it up it's 5 lines of code. That's the whole point they're not forcing you to learn something: A) so esoteric you will never encounter in your programming career B) so complicated that you'd have to spend days practicing…

They can definitely ask brain teasers, they decided to stop because it proved useless.

Some questions are fair, but there's a reason most candidates spend weeks/months practicing. Good luck pulling off something like a topological sort if you haven't studied the algorithm recently.

Re: Why I Don’t Talk to Google Recruiters

#108

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.

I understand the perfomance characteristics of red/black trees very well. I couldn't implement one in 30 minutes on a whiteboard.

After preparing and studying the interview questions on data structure, algorithms etc. with the help of guide books like https://books.google.com/books/about/Cracking_the_Coding_Int... You definitely can!

Re: Why I Don’t Talk to Google Recruiters

#109
post #60

Earlier quoted context omitted.

> They're not looking to fill any particular role. They're just looking for smart people I've found this to be decidedly not true, from many recruiter contacts. They have a role in mind they're trying to fill and if you point out that it's far more junior than what you're looking for, the conversation's over. Think about how must companies hire. The hiring manager fights internally and finally gets a req for a very s…

Nobody does that because being smart is of no guarantee that this person can be of any use to a business.

Are you entirely excluding university recruiting from this? Because consulting firms and investment banks routinely recruit smart people without any demonstrable experience doing what those companies plan to train them to do.

Re: Why I Don’t Talk to Google Recruiters

#110

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

I'd be interested in hearing from people who work at Google, and get to figure out a cool algorithm for solving an interesting puzzle-problem more an about once a year. I bet there aren't very many. In my experience, the stuff you do in this kind of interview has very little relation with the stuff you do in the actual job. (I wish it did! I love those algorithmic puzzles.)

My problem is that I forget things very quickly. I've implemented optimized k-d trees and VP trees from scratch, but I forget the complexity of searching, rebalancing, etc. Even though I've implemented it before. I normally just Google something simple like that when I need to "re-remember". I suppose interview performance at those types of companies is kind of like high school and college — just cram all that stuff into memory beforehand and forget it right after the test.

My most recent interview was very well done and not like an "algorithm quiz" at all. I had to bring my laptop and give a short overview of a project I had recently worked on. I think this really plays to the candidate's strengths.

Post reply on HN