It's like this person was inside my head. I agree basically word for word and do the same thing, cannot be bothered anymore, like he suggests, if they are telling him his profile is so great and 'impressive' why must they schedule a regular interview and on a whim reject him. Waste of time.
I was exempted and moved all the way to the last round of interviews. The compensation was even negotiated before hand. I am a regular engineer with three years experience.
I have a friend who would be level 7~8 at Google and he still gets generic emails from recruiters.
Not sure they actually do hire anyone straight to this kind of engineer levels though, I assume they'd give you the salary and responsibilities and make you earn the title through promotions?
Its the London Cabbie(1) method. They're not looking to fill any particular role. They're just looking for smart people (for the value of smart that fits their biases).
They just need as many warm bodies as possible to ram through their test so that a few trickle out the bottom of the funnel to keep the ranks from shrinking. If too many started getting hired, they'd add competitive basket weaving to the skillset if that's what it took to balance it.
> 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 specific role. They have to fill that role. Having a generally smart person would be great but they have this immediate need and they can only hire one person. And once that req is filled, no more hiring until you get another req.
I'd love to see a company literally just looking to snap up smart people and then have them come in and kind of define their own role, one where they can add the most value. Nobody does this!
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.
That's almost exclusively ivy. We need a Yale guy, any Yale guy, doesn't matter who, just need it for the list of accomplishments. Then we can use our new "ivy atmosphere" to get that specific guy from Stanford or whatever.
The only place hiring generic warm bodies at random state-U is Starbucks.
Consulting firms and investment banks recruit plenty out of my alma mater, UCLA (a public, state university that isn't considered part of the Ivy Plus). They did the same at University of Texas, where I went to graduate school, another public, state university.
Google is a little bit of both. At least from having gone through the process (and ultimately turning down an offer due to the ridiculousness of the process). There's a massive funnel where they're trying to bring in a bunch of smart people, then teams basically say "I have this position available, who has gone through the funnel that is a skills match for our specific teams".
> I'd love to see a company literally just looking to snap up smart people and then have them come in and kind of define their own role, one where they can add the most value. Nobody does this!
At least with hiring out of college, a lot of companies do the "Let's snap up smart people, then train them to do the specific job we need done". In my experience, this has been particularly prevalent among the big consulting firms.
I've seen the opposite, from close observation on both sides.
The recruiter may start out with a role that they are trying to fill, but they have plenty of other roles that they could be happy to put you in. And furthermore for the right candidate, they don't have to figure out the role up front.
When I was hired by Google, SRE poached me out of a pipeline to a different group. (Accepting that offer was a mistake on both sides, but it was a learning experience.) When I was hired by Amazon, I was contacted for a job in Seattle, then got hired in Orange County.
That said, plenty of candidates start the process by being too arrogant about what they can demand. Recruiters know to look for that and stop wasting their own time taking these people seriously. That's why pointing out that a proposed role is too junior for you is likely to result in being dropped.
Interesting, thanks for the insight. Funny how two people can look at the same recruiting environment in the same industry and have two totally different experiences.
> That said, plenty of candidates start the process by being too arrogant about what they can demand. Recruiters know to look for that and stop wasting their own time taking these people seriously.
Maybe, but I think it saves both sides time. If I'm shopping for a new sports car and a salesman approaches me with a great deal on a 10 year old pick-up truck, it's helpful for both of us if I make my expectations clear right away.
Most Recruiters: "I have this role you'll be great for! Let's see if it's a great match!"
Better Recruiter: "What are you looking for? I work with a lot of companies and probably have a great match!"
Yeah, I've seen those recruiters. And they tend to not be honest about who they are actually working for. So, for example, you'll get contacted by someone who is recruiting for a job at a big name company, from someone who isn't from that company and doesn't know what is actually available from there. They only know about the one role that they were told about.
These things are generally a mess if you start out that way. Waste of time and money on both sides.
SRE is a difficult role because you need someone with the mindset of a sysadmin and the skills of a programmer. So Google (at least used to) will hire one and hope to find the other half. As a result a large fraction of people hired into the position are not a fit. And Google had no mechanism to identify and rectify this common problem.
I am a programmer. I tend to dive into things in depth and context switching is unusually hard for me. A sysadmin needs to be able to operate on relatively limited knowledge and rapid context switching is par for the course. I was therefore a poor fit in that role.
After I left I was shocked at how many people I met who had known someone else whose story matched mine pretty closely. I would hope that Google has solved this organizational problem since. But rumor from those I know that are still there indicate that things have gotten worse over time, not better, so I don't think that it has.
However it was quite educational. I wish things had worked out differently but I definitely learned a lot that has served me well since.
I think it's tough hiring for an SRE role. Much tougher than a programming role. Although in Google's SRE book, they say the interview bar is lower than for their software engineers. Odd!
You're looking for the sort of person that could setup a startup from the data center up. On top of that, they need to be good coders so they can automate everything, and also understand the applications running on the things they build. It's generally a much more in-the-trenches job - relying on limited information, and much harder to test things in isolation since there are so many moving parts, and things you can't change or automate easily (network vendor appliances, and so on).
> I'd love to see a company literally just looking to snap up smart people and then have them come in and kind of define their own role, one where they can add the most value. Nobody does this!
I don't know about letting people "define their own role", but a lot of the biggest companies are constantly hiring without a specific role in mind. If you've got thousands of employees then your best strategy is just hire the smartest people you can find, and figure out how to use them effectively - you have enough roles available that you'll find something for anyone to do, and while not every role you need filled is someone's dream job, a combination of internal mobility between teams and great benefits and pay will attract a lot of good candidates.
The problem, from my perspective, is that I (as a candidate) have certain things I want to work on. You might have something I can do, but is it something I want to do? I don't want to be hired into a general pool; I want to be hired for one of the specialties I am interested in.
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 and new challenges instead of saying "Well, the foo project is closing down and foo's pretty much what I wanted to do, so I guess I'm going to quit (and take all the knowledge and skills Google spent time and money to train me up on with me)."
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-advisable strategy, though, as the GGP I was responding to indicated. In fact, I'd argue that well-crafted teams of specialists are superior to, but harder to staff than, teams of generalists.
Ah, I see what you mean and I think I agree; "well-crafted teams of specialists" are, hypothetically, one of the advantages of attempting to tackle a problem as a startup company as opposed to pulling the resources together within a large corporation to skunkworks the problem (though in terms of eventual success or failure, I don't know where to place that advantage relative to, say, having the luck / foresight to choose a problem that the market needs to solve and doesn't have a good solution already in the pipeline somewhere [and will need to solve long enough for a startup to reach minimum viable product] and the startup's capacity to trade equity for a staff that will work their bloody asses off).
I definitely don't think that the generalist hiring practice is the best for all purposes - just that it makes a lot of sense for the bulk of the hiring at a large company, and that most the big tech companies do it.
The big tech companies do also build well-crafted teams of specialists where appropriate (for instance, Google's Deep Mind team is all AI specialists). I don't know what sort of hiring process they use for those roles, but I would wager the process is a little more personalized, and also substantially more selective.
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).
I have seen this 'fungible bricklayer' approach at amazon & have to tell you it cant be any more misguided. It may work for generic web software where learning curve is not as steep but any point you are dealing with vertical technologies like wireless or multimedia it just falls flat on its face. And the byproduct is poorly thought out software full of band-aids. unfortunately this kind of nonsense often becomes pervasive where management itself is very non-technical (google may be an exception though).
And in theory it should totally be worth it as a candidate unless they are coasting on reputation. Otherwise the supply of candidates would dry up. In practice it wasn't for me, but I refused to tell them how much I made just to see what would happen.
If you interview at Google and they ask how much you make you should probably tell them or you might get a weak non-negotiable offer. Unless what you make is already far less than their "standard offer."
It would be a shame to waste all that effort by sticking to negotiation techniques that maybe don't work on Google for regular candidates.
I thought it was pretty well understood that you should never name a number, and if you're forced to, you should say 5 times the number you had in mind.
that's absurd. you should name the price you expect, and not go below your minimum.
would you hire a plumber that refuses to name his rate, and then when pushed, tells you a number 5 times higher than normal? why do you think any other employment negotiation is any different?
if you "never name a number", the person on the other end is going to know you're inexperienced and operating on cargo cult mythology, and will simply take advantage of you.
If you have a good idea of the price you expect, based on a clear understanding of what you can command, then this is an excellent idea.
The standard "don't name a number" advice is based on the assumption that most candidates don't have that. They know what they earn right now, but they don't know what they could be earning. In that situation, you want to sweat some information out of the recruiter by getting them to name the number.
There are other ways you can get a bit of edge.
In a previous round of job hunting, i let a recruiter persuade me to apply at Amazon, even though i was 85% sure i didn't want to work there. They made me an offer substantially higher than my salary at the time, because they're desperate to hire, because nobody wants to work there, because they're a shitshow. I could then take that offer to the other companies i applied to, where i actually did want to work, as a starting point in salary discussions.
In my most recent round, one recruiter said to me "Company X want to know how much you currently earn, because they can't offer above 130k for this position and they don't want to waste their time if you're on more than that". 130k may not sound like a lot to you over in the Valley, but it was getting on for twice what i was making at the time here in London. "Well,", i said in the most noncommital voice i could manage, "130k would probably be okay".
Yeah, I engaged a recruiter who seemed pretty decent at the onset. Then when I expressed interest in 2 positions, they demanded that I provide detailed salary for the last 3 jobs I have worked in.
I gave express disinterest in doing that, and had no issue with providing salary expectations. But I made it clear that this behavior was completely unprofessional and unbefitting of a recruiter.
I then told them in no uncertain terms that as long as they have this policy on their books, do not call back. If however, they change this, I would consider them again.
Habit mostly I guess. I always implicitly assume lying has the risk of getting caught and then becoming known as liar. I don't evaluate on a case by case basis whether I should lie.
Also the experience of being caught lying is emotionally and mentally draining for me so I stopped way way back. Like in childhood. I wouldn't say I'm completely fib free, but if you are even remotely entitled to the truth your going to get it. If I get caught lying I have to be OK with it and not care. That is a high bar.
I have been through what you describe. A recruiter reaches out and tries to get you in their funnel. For me, it's a no-go because of my college background. (Unsexy school, shitty grades.)
A family member was pursued by them very aggressively after making some presentations at significant conferences and getting praise in a book written by a high level business exec.
This family member was received borderline harassing levels of outreach from recruiters from Google. It's pretty obvious there is some sort of targeted hunting list and KPIs associated with it.
Yeah it kind of sucks, but from Google's perspective it's absolutely necessary. So many people talk the talk, run a blog, have a neat looking resume/website/GitHub and just cannot perform. Unless you're an undisputed rockstar in a specific area and they're hiring exactly for your expertise you can't expect anything else. It's a huge waste of time to custom tailor to each candidate when 90% won't receive an offer.
> 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.
Take an afternoon and skim Cracking the Coding Interview before applying. There's no reason a competent engineer shouldn't be able to solve questions like that. You know exactly what's expected of you, show some initiative.
> Take an afternoon and skim Cracking the Coding Interview before applying. There's no reason a competent engineer shouldn't be able to solve questions like that. You know exactly what's expected of you, show some initiative.
I think the core issue here is whether the prospective employee should have to show some initiative. My initial reaction is that of course they should, but when you're fielding job offers from numerous companies, some of which don't require you to go out of your way to pick up new knowledge specifically and only so that you can pass an interview, why not just dump Google and go somewhere else? A few years ago Google was probably the most desirable place anyone could work, I really don't think that's true any more.
Overall, it sounds like the system is working. Developers that don't much care for Google's methods won't go and work at Google. Those that are very passionate about working at Google for the sake of working at Google will jump through those hoops.
You can't figure out if anyone can perform, by asking algorithms questions. That's rather a waste of time. Instead, they can be given a task to write some real code to solve a certain task, and of course not in 2 hours, but within a day let's say. And then evaluate the result. That can show how people perform. And not puzzle questions about problems that people were breaking their heads for years to crack.
Those are not at all the questions asked. They don't ask you to prove A*, they ask you to filter a binary tree based on some predicate. It's much closer to real life than people on HN like to admit -- your coworker wrote some code using some datastructure and you have to figure it out and modify it.
> 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.
I'm with him up until "never be interested...", thats a piss poor attitude. I've never needed to know big-o complexities for work, and I've only scraped the surface of needing/using various data structures, so I get annoyed at some of the heap/tree trivia questions as well. But if I were in a situation at work where I needed a tree, of course I'd stop coding and read up on how binary trees work and use them for my benefit.
Disclaimer: I have interviewed-trained twice at Google but I don't like the process for interviews. Athough I work there, My opinions have nothing to do with Google, just my own.
I think the process selects well for new grads who have recently completed algorithm courses.
I think the process selects well for people who are comfortable with doing work on a whiteboard.
I think the process selects well for people who are motivated enough to work at Google that they read and study books like you mentioned for weeks, and do a bunch of practice self-study interviews before coming.
Whether that set of people overlaps significantly with what makes a company do well -- I don't know. I'm not sure.
But I am pretty sure that the reverse assumption, that people who don't pass those bars are not good canddates, is an arrogant position that only a company of Google's standing and size can/should get away with.
What I don't get is the trend of small companies, startups, and the like, copying this interview process. It is entirely not a match nor a way to find the kind of motivated, culture-fitting, creative people you need in a smaller company.
> Take an afternoon and skim Cracking the Coding Interview before applying.
First, I know this isn't a black or white issue but the problem I have with this is that I'm wondering if they are hiring people with the skills they want or are they hiring people with the skill to succeed in their test.
In theory, they should be the same. In practice... I don't know.
I'm convinced that they are. Sure, it's not perfect, but the set of qualities that impress me in a whiteboard are generally the same qualities that I look for in an engineer. Can you communicate well? How do you approach problems you've never seen before? Can you write readable code without thinking too hard about it?
I'm not really selecting for people who are really, really good with binary tries -- I'm selecting for people who display those qualities, the question is pretty much incidental.
"Cracking the Coding Interview" doesn't seem like a book you skim. It seems like a book you buy a gigantic whiteboard for and stay up until 3AM every night for 6 months with it.
If Amazon (or probably anyone for that matter) has some reason to believe you have a short timeline, you can expedite all this. Both times I interviewed with Amazon (I boomeranged and worked there in two separate stints), I had other loops/offers from other co's, and went from initial contact w/ Amazon to an offer in ~4 days.
May be not for many people here on HN but for very large number of engineers job opportunity Google/Amzn/MS/FB etc are once in a lifetime type. I have not met people in my circles who would balk at interview process there.
for very large number of engineers job opportunity Google/Amzn/MS/FB etc are once in a lifetime type
Meh. Being a developer is being a developer. Not to say that certain specific companies don't sometimes have specific challenges or perks that would be of unique interest to somebody, but by and large, there's no real reason to think if Google/Facebook/Amazon/$anybody_else as a "dream job."
I used to think that way, and after working at two of my "dream job" companies, I've realized that it's pretty never what it's cracked up to be.
Really, the world is SO much bigger than just GoogBookHooSoftCart... I'd encourage people to NOT put those companies on any kind of pedestal.
Your best opportunity as a young engineer is always with a startup with smart leadership. You'll get to do far more and learn far more. Google/Amazon/FB/MS etc are full of smart people and offer a more 9-5 type job, but you will find it much harder to do interesting things.
When I graduated, Google/Amazon/FB/MS, I knew people were smart and the job would be okay at the very least. How should I have gone about figuring out which ones are "a startup with smart leadership". I remember being overwhelmed by everyone, everyone came across as smart.
So I counter your advice by saying the best opportunity for a young engineer is likely a large company that is well-known for having generally smart people. At least I learned what I wanted and didn't in the rest of my career.
Interviews are a two way street. For most companies you should be able to talk to the hiring manager and other developers that you would be working with. Ask yourself whether as a junior developer if you will be able to learn from them. This includes technical skills, soft skills, and personality.
From my own experience I interviewed with a small company right out of school where I would have been the second or third developer (I forget now). One reason I did not pursue it is that I seemed to know more about development best practices than their existing developers; for example they did not use source control at all. While I would have had the opportunity to make a big impact on the product, I don't believe I would have grown much.
From my experience, either your profile is deemed interesting and you'll get contacted by these companies from time to time (Amazon being the most aggressive) or they'll never get back to you, even if you try pretty hard.
There isn't really a "once in a lifetime" email from a recruiter. Once you interviewed with them you'll have plenty of opportunities to interview again.
I remember doing a phone screen with a company who shall remain nameless, but it was a phone company that has a three letter name and two of those letters are the same :-). It went pretty well, and I predictably got not response back from them. A month or so later I accepted another job, moved my family across the country, and started on the new job. About 2 weeks into my new job, Three Letter Company's recruiter calls back and said the phone screen went great! Can I come in for a round of in-person interviews?
I LOLed over the phone, it was a riot.
EDIT: On the other extreme hand, it's a HUGE turn-off when a recruiter makes an incorrect assumption about my time availability in the initial contact. Stop me when you've seen this one: "Your background looks great! Please tell me what time slots today would work for you in order to discuss this role." Wow, really? You're assuming I have time to call you RIGHT NOW?
My last interview loop I got the feeling that some companies just say it's 'close' to get you to apply again in 6 months. Unless they give actionable, solid feedback (FB always does, at least with me), I consider it a binary.
Story time: At <X>, I knew after the culture fit round that I wasn't getting an offer. I had middling coding rounds and a terrible culture fit round with the hiring manager. The recruiter claimed that it was close and the team was arguing about the hire, while the person that referred me let me know that they were passing because the hiring manager vetoed everyone with a 'no hire' about 2 hours after I left their building. I had no qualms with the reject, I truly felt a misfit in the interview, but the recruiter play was funny. Someone reached out to me 4.5 months later asking if I wanted to interview :)
Depends what the job description is, surely. And if the developer isn't interested in working on these things, surely it's failure on Google's part to effectively target who they are approaching?
The job description is "Software Engineer at Google" They hire some special roles from time to time, but then they approach people differently (i.e. on a personal level) otherwise they hire people they ideally can move easily from project to project.
For a complete success they would have a way to filter out people without algorithm knowledge early on. A day of interviews already costs them some money, especially on the scale they are doing this.
Yeah maybe you are right on that point. At Google at least the filtering by stage seems to be: Recruiter phone interview: do you speak English? Technical phone interview: have you ever programmed a computer before? Technical on-site interview: do you know a few things about data structures and algorithms?
What's funny is that Google seems to think they're really good at interviewing -- for example, see this Washington Post puff piece: https://www.washingtonpost.com/business/capitalbusiness/an-i... Possibly they are, but it's hard to see solid evidence one way or the other. I guess they can't be really bad in the sense of hiring mostly bad candidates, as that would surely cause big problems before long. But they could be about the same as other big bay area companies.
> 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.
This phrase precedes the one you mentioned. He's saying the process he has been through completely ignored his background and field.
The notion that traversing a binary tree requires expertise in algorithms seems questionable to me. I view basic tree traversal as table stakes for a developer with more than a year or two of experience (IIRC, it's discussed in Intro to Algorithms in most CS curricula).
OP says that his field is object-oriented design, which links to a page where he announces that "We've started work on a new programming language". The idea that a computer scientist/software engineer would embark on building a new programming language but also state that they don't know how to solve tree traversal problems and "will never be interested in learning them" seems strangely incongruous, given that building a language almost certainly involves working with ASTs.
Specifically, OP pushed a commit in late 2016 that contains code working with stacks, linked lists, and an AST class for the EO language.
But optimizing for them? I've been out of school over 7 years; I'm currently a tech lead. I can guarantee you that, while I can likely solve most binary tree related questions you'd care to throw at me, it will take a lot more work, thought, and likely mistakes on my part now than it would have when I first got out of school. It's not an area I've spent -any- part of my development career on, nor is it an area I find particularly interesting. Whereas when I left school, I had actively been dealing with such problems within the past couple years, -and- had boned up on them specifically to prep for interviews, since I had nothing else in my favor.
Hiring a junior with such criteria might make sense; hiring a more seasoned person, probably not so much. Because the seasoned person will just not be as compelling as the more junior person, due to having spent the past few years working on other things.
I agree, especially when designing programming languages that it's a bit weird to not know how to traverse a tree.
There is one thing I want to point out though. Before starting my algorithms course I knew how to solve problems recursively. I had done project euler tasks and what not. I just never knew the words abstract syntax tree or binary search tree. I could guess what they were prior to the course but I didn't know what they were off the top of my head.
Do you think that it's possible that a self taught engineer would know how to solve these problems given time and enough questions to the interviewer? Maybe get frustrated with "How do you balance a search tree?" questions under pressure?
> Do you think that it's possible that a self taught engineer would know how to solve these problems given time and enough questions to the interviewer?
It's very easy for new interviewers to come up with problems that are easy for them (because they know the subject), but very difficult for the interviewee. Avoiding that is a priority for me, but I still strive to evaluate how the candidate approaches problems.
My strategy is to keep my questions as close to first-principles as possible, making the problem more about programming approach than algorithmic recollection. I had a Google interview once where they asked me to implement pivot tables, and I had to sheepishly ask: "What's a pivot table?" That set me back somewhat, and I try to avoid that in my own questions.
> Specifically, OP pushed a commit in late 2016 that contains code working with stacks, linked lists, and an AST class for the EO language.
Most people can work with Vectors/DynamicArrays, linked lists etc. but they don't know how to implement one or even how it works in detail under the hood.
In response to not knowing the speed of sound as included in the Edison Test, Albert Einstein replied:
"[I do not] carry such information in my mind since it is readily available in books. ...The value of a college education is not the learning of many facts but the training of the mind to think."
This is even more true today with the vast trove of easily searchable called the Internet. A competent programmer should have high-level knowledge of different algorithm types, but should not strive to memorize their implementation (e.g. for interviews), since it is trivial to look that up.
That story about Einstein doesn't illustrate what you think it does. Einstein was a theoretical physicist, not an experimental physicist; there's no reason for him to have known the precise value. However, you can bet that Einstein knew the theory quite thoroughly (review his writings if you believe otherwise) and would have been rather less than impressed by anyone calling themselves a physicist who did not.
And aside from that, let's face it, none of us here are Einsteins.
I'm not sure I buy that distinction. Do you believe that experimental physicists know every single formula and can recite it off the top of their head? Because unless they use those formulas constantly in their work, they end up having to look them up.
Same thing with algorithms like tree traversal. You should know the theory behind them, but unless you regularly implement them, there is zero reason to commit their implementation to memory to the extent that you can casually write them on the white board during an interview.
>>And aside from that, let's face it, none of us here are Einsteins.
Even more reason to not try to memorize something unless you use it constantly.
But imagine Einstein having to look up how to derive x^2. I'd say that's a pretty close equivalent to knowing tree traversal in CS. It should just come naturally.
I've been working in the programming industry for ten years and have never had to implement tree traversal. I could probably scrape together a naive implementation in a relatively short amount of time, but it's certainly not something I've memorized. But then, I'm a programmer, not a computer scientist.
> I view basic tree traversal as table stakes for a developer with more than a year or two of experience (IIRC, it's discussed in Intro to Algorithms in most CS curricula).
You mix two completely irrelevant things: education and experience.
You will be taught binary trees in CS, but not every programmer is studying that.
If you learn binary trees in CS, you will forget it after few years of experience, because skills that are not used are forgotten.
So yeah, Amazon/Googles of the world are looking mostly at recent CS graduates (most of the set of programmers that know many algos) and the very small set of programmers that deal with algos every day.
And a third category: people that train specifically to pass the Amazon and Google exam.
I know several people that did, taking several months off to prepare (and got in), and yes, you have to re-learn all the CS algorithms which will probably be irrelevant again after you pass the interview.
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.)
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.
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 have wikipedia, stackoverflow, hn and so on: software development hasn't qualitatively changed in the past decades to require multi-day interviews when 15 years ago a single 30-45 min interview was more than enough.
It would actually be interesting to compare the length of, say, a google interview a year after company inception compared to now. I am sure that despite the fact that nowadays the impact of a bad hire would be minuscule compared to back then, the interview process is way, way, way longer and more difficult.
> 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.
> 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 can watch them implement one.
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.
> 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.
this is also what is annoying me, the thought of so much ink being devoted to O complexity and so on when with modern processors in the end often "less optimal" algorithms are a lot faster based on how they work and often you end up writing the same thing 3 different ways so you can test and see which one is actually fastest given your language/compiler/toolchain/processor
In a book-level discussion whether a comparison in your algorithms evals to true or false in a predictable or unpredictable pattern doesn't make a difference in its performance, however write that out in code and the branch predictor of your CPU will be a LOT happier (and faster) if you make it so that all the "false" and "true" comparisons happen in streaks as opposed to randomly...
You don't have to memorize 1000 algorithms. Honestly you could have a really good understanding of when and how to use about 10 algorithms and probably do very well on most interviews.
You probably won't even get to use all 10 in your 1st two years of work. All the computer science you use in 99% of a typical programming career could be described in a single conference presentation. (Not that one would master all of it that fast, but it would describe what you need to know and know you don't know.)
The problem is each company will ask you a different set of algorithms, and you're not sure which they'll ask, so you effectively have to memorize a LOT more than 10 if you want to be prepared for whatever they throw at you (not literally 1000, but maybe 40 or 50, which will take considerable time to prepare for, in addition to all the other preparation or unrelated questions they could end up asking you (architecture, OS, process, design patterns, optimization, advanced language-specific quirks and gotchas, terminology, 3D math and graphics (if games), databases, networking, behavior questions, solving math problems you've never encountered before, questions about your past projects, etc, etc, etc).
When they passed on me after my Google interview, the HR person actually told me "You can try again in 18 months. There are quite a few people who study for it during those 18 months and get it the next time!"
Yeah, I don't want to study for 18 months to get a job at Google, sorry.
The other downside of that is: in 18 months they're going to hassle you for an interview again, whether you want one or not.
I have a friend who was interviewed at Google, rejected, then interviewed again a year later, rejected again, and then a year later a Google recruiter got in touch to see if they'd like another interview. They said it started to feel like a cruel joke.
Oh yeah, recruiters from Google have contacted me three times since then. Actually the most recent recruiter said I could contact her whenever I felt like having another interview.
I might eventually try going through the gauntlet again, but I wasn't quite willing to move to the west coast during that time (new relationship, new home, new puppy, work was going well, I didn't really need more big life changes at that point).
I'm starting to consider a job change but I'm still not sure I want to move to the west coast. I'd probably have to downshift my home quite a bit out there.
I'm not sure I understand your point -- possibly we're agreeing?
To clarify, it seems to me the interviews tend to focus on things like "what's a good data structure for the social network in a Facebook clone?" but that's only 1% of the actual job, 5% tops.
It's true that those technical design decisions are very important, but they're not decisions that every engineer needs to make on their own on a day-to-day basis. They come up fairly rarely in a typical project and usually multiple people will be involved.
I don't have any easy answers -- I don't know a good way to interview for the other 95%+ of useful skills, like communicating well within a team, testing, debugging, benchmarking, writing documentation, good source control practice, knowledge of standard tools, meta-knowledge of how to learn about standard tools, how to evaluate new tools, system administration, dealing with production panics, etc.
my point was more along the lines that even if you need to figure out cool algorithms as part of your job, interviews as they are now don't seem to be not testing for that, but more for "can you rote learn these specific algorithms".
I think some of this was why some time ago there was a way of interviews with "off the wall" questions, but those seemed to be fairly vilified so I guess that's why they aren't as common now, but personally I would get more of an understanding in how somebody thinks by giving them an unexpected question than by asking them something they could've studied for.
This is what has confused me for a long time, I interviewed at Flipkart an Indian ecommerce major (ex?) and their process was horrible. At the second round they asked us to implement a toc tac toe program, others didn't even have compilers, I had Python because it was a Linux machine, was rejected because "code contained bugs and didn't run", the third round was algorithms. I think these companies don't know how to hire that's why they are sticking to algorithms, in real life nobody is going to implement an algo from scratch, if I can learn Go in a week, learn how to write a webapp in 2-3 weeks when I have never written a webapp before why does it matter if I don't know how to implement some random algorithm?
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.
There's a well known analysis that shows they're asymptotically equivalent to B-trees. You can tune a B-tree to better exploit cache locality. Other kinds of ordered binary trees are far less complicated to code and have similar performance characteristics.
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 to implement with hash tables/arrays/linked lists.
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.
You don't generally need to write tree-traversal algorithms because other people have already done so and you can use their implementations. But you should still understand the tree traversal algorithm, so you know what the thing you're using is doing, what its complexity is, etc. And if you understand it, then you should be able to reimplement it yourself.
Yes but jeesus here we are discussing an algorithm that I first heard about in literally my first CS course on algorithms in my first year at the university, some 20 years ago. And I had to manipulate red black threes on the blackboard.
Haven't seen them since in my 20 years of work in the industry.
I you need to write so performance critical code that the choice of tree structures matters then this interview question sure as hell isn't going to find out if you are cut out for it.
I've interviewed many candidates for one of the big 4 & sat on the decision loops too. 'Attribute substitution'[1] one thing that does stands out in these interviews. essentially interviewers substitute answering the larger question of judging the candidate's suitability for the job at hand with a simpler but easier to judge (& defend!) problem of solve this particular coding problem that I have 'normalized' over many candidates. Also, deep domain knowledge is often hard to judge.
> 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.)
This is what confuses me. I tend to take the problems I get during an interview as representative of the work I would be doing, and then get turned off by the job immediately.
At least at the PhD level, you'd expect that the job would be using more of my unique expertise, I'm not a BST expert (though I can write one when I need to, it definitely isn't "warm" in my brain).
I used to enjoy giving interviews because it was fun coming up with these little problems, and discussing them with smart people. Because I didn't otherwise get to do that very often at work! But I felt guilty about giving a false impression to interviewees about what the work actually involved...
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.
I so totally agree! Forgetting stuff is as important as learning new one, because it forces you to learn/re-learn quickly.
I wrote millions and millions of lines of code in my 30 years career, I was once a top shot mac developer, and I was once a top shot computer geometry expert, and an OpenGL expert and all of that, and I've forgotten most of it... If someone asked me a trick question, I'd look like a fool.
Simply because I don't need it. My strength over all these years is my capacity at learning stuff quickly, and that doesn't come up in a trick-question interview.
So for these data structures questions: In 30 years I once had to implement a binary tree for any sort of problem I had in my job. Now it's not the same for hashes, lists, queues and many others, but trees? Quite frankly it's a CS toy. You know it's on the shelf in case it's needed, but it very rarely get a dusting.
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 persistent recruiter emailing me over and over and over again to apply, despite my knowing there was zero chance I'd be a fit for the job they asked me to apply to.
And more generally: I don't really care about binary trees. They're simply not relevant to the work I do. I suppose if someday the only way I can get a job is to buy a book with all the stock interview questions in it and memorize the answers, then that's what I'll do. But if somebody's hiring me, I want them to hire me for the things I know that aren't standard interview questions anyone can memorize.
The way I try to phrase this to people who don't get it is: my metaphorical working set in memory does not include basic algorithms (that's what libraries are for), and does not include brainteasers or riddles. It does include a lot of arcana about how web application stacks work, the network and gateway protocols they use, the points where security and reliability issues are most likely to happen and how to avoid those issues, the application and database architecture patterns most often needed, available libraries and frameworks which implement them, pros and cons of different approaches, etc., etc. I could, if so inclined, probably take the metaphor all the way and outline which things are in the equivalent of CPU cache vs. the equivalent of main memory.
So sure, I could page all that out to disk and forcibly cram a binary-tree answer into my brain's L1 or L2 cache, or load up one of the dynamic-programming questions Google loves (tip if you want to work for Google: memorize the Wikipedia article on longest common subsequence, even if it will never ever be relevant to anything you'll ever do, because they will have you do it in an interview). But that would be actively harming my own usefulness, and I'm not willing to do that for Google or for anyone else.
Which I guess raises the question: why do you apparently want me to harm my own usefulness just to try to get a status-symbol passing grade on a Google interview?
Here's the thing, nothing personal about you but a true fact about Google. Nobody at Google could possibly care less about your opinions on "application and database architecture" because Google does not have application and database architecture that even slightly resembles anything you have ever seen outside of the company. In fact the less you think you know about architecture the better it would be for all involved, if you were to go work at Google. Also all those things you know about makefiles and maven and ant and ansible and chef? Nobody cares. Google doesn't use those tools. Google has lots of famous engineers and while I believe their expertise and knowledge are valued, their outside experiences are generally not.
I'm not arguing that Google doesn't have a huge scale, but I'm pretty sure that Microsoft, Facebook, Amazon and most likely the NSA also have unique systems and challenges.
Google also increasingly has a reputation as a company that hires top-tier CS Ph.Ds and puts them to work building CRUD web apps.
They have this reputation because, it turns out, not every engineer at the company needs to be able to rebuild all of Google from first principles in order for it to keep running. And even at Google scale there's not enough interesting greenfield work to do to, or de novo problems to solve, to keep all those "famous engineers" busy all the time. The same is true at most companies -- you need a mix of talents and skillsets, and you need to match up people to roles based on that. The Google approach -- of putting people into drudge work and paying them enough to hope they won't quit -- is a grossly inefficient use of talent and knowledge. Which is another reason I wouldn't want to work there!
> In fact the less you think you know about architecture the better it would be for all involved, if you were to go work at Google. Also all those things you know about makefiles and maven and ant and ansible and chef? Nobody cares. Google doesn't use those tools. Google has lots of famous engineers and while I believe their expertise and knowledge are valued, their outside experiences are generally not.
What distinction are you making between "expertise", "knowledge", and "outside experiences?" The outside experiences are the basis of the expertise and knowledge. If you understood, used, and contributed to other existing build systems, you are then in a good position to understand, use, and contribute to Google's in-house build system, because you have useful knowledge about the problem domain of building software. And so on.
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 completely open ended question.
I don't work at google so I won't speak to their daily work, but very rarely should you be writing your own binary tree or traversal code. If you should find yourself on that task you hopefully won't be doing it from memory / without reference because unless that is the ONE thing you know like the back of your hand, even then you are likely going to make mistakes.
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. There has only been a few times that I have actually needed to implement any of these algorithms in the last 10 years. Of those they were very low level and implemented in a kernel driver where libraries are not so abundant. Can I remember all the fine details today? No. Did I make a system that runs on hundreds of thousands of linux systems across the world? Yes. If I were interviewed on the fine details of implementing some of these algorithms and data structures would I pass? Not likely. Does this make me a bad programmer? Depends who you ask. If you ask the guy interviewing me Yes. If you ask my boss and the many customers who use my product No.
Memorizing algorithms does not make you a good programmer. Knowing how to apply and when to apply them does. The hard part was done when the algorithm was created, not regurgitating an implementation.
Now you might say hey, they should at least know binary tree! Sure maybe they should have some knowledge of it, but there will always be some algorithm you don't know. I would feel completely different if Google said "Come ready to talk about these 5 algorithms and maybe implement one or two". That falls inline fairly well with the author of the article. At least then somebody can say, "Hey, I don't have time", or "Sorry, not interested". And both sides can have their expectations insync.
Now don't get me wrong. We are talking about Google and Amazon. So yeah, somebody there might need to know something about these algorithms. But I doubt they all do. The Few interviews I have been on at these organizations I was not even convinced that all the people interviewing me would be able to pass the round of 5 had they interviewed each other. I should note not all the people who interviewed me gave me that impression. I did meet some really nice people that I thought I would enjoy working with.
I also don't think that these companies don't take into account that some people just interview badly. There is a lot of stress involved. While I think people should be able to work unders stress, I think the type of stress these interviews cause is something entirely different. I live a fairly stress free and carefree life. But when I went to interview at Google my stress levels were so high that I felt sick and worn out for days after. What I am getting at is I am presented with hard problems and short deadlines daily at work. Not once did any of those challenges cause me any level of stress. On the other hand trying to figure out what the interviewer really was asking and cramming to memorize algorithms caused so much stress I did not sleep for days days before the interview. It's not that I was up studying, its that my mind was racing and I could not sleep if I wanted. I just lied there in bed staring at the ceiling. I think they call that anxiety.
> Interview process: complete success.
It was a failure because they wasted everybody's time. Had they been more upfront on what they were looking for then he coul...
I would feel completely different if Google said "Come ready to talk about these 5 algorithms and maybe implement one or two".
Very good point. The amount of memorization involved in the process is excessive. It'd be helpful if each candidate was told what subset of all possible problems they should focus on.
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.
> But the real value is in being able to analyze an application's performance and deal with concepts like recursion.
Implementing a delete on a binary search tree or traversing one has nothing to do with analyzing performance. If you want to ask questions that require recursion don't make them dependent on algorithms that require rote memorization. Or at least have a alternative recursion question if the candidate says - "Sorry, I don't remember all the rules for this algorithm". Or even be ready as a interviewer to go over how said algorithm works and see if the candidate picks up quickly. If you wanted to really talk about performance then you can talk about WHEN to use a given algorithm and WHY. You don't want to ask questions that there literally is ONE (maybe two) answer that are correct. You don't want to ask questions that when asked WHY the answer "is because that is how the algorithm dictates it." You want to ask questions that are open for interpretation that you then can ask the candidate why they chose that solution. This gives you much more information.
> 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.
Let's not conflate algorithm implementation from rote memory with not wanting to answer any technical questions. You can't just come in and start talking about ACID transactions and concurrency as if that is what people have been objecting to. Those are valid topics and I doubt most people would have any qualms talking about them. As those are concepts, not rote memorization. You have to have a good understanding of the problems to know where the pitfalls are and know how to spot them. Implementing a algorithm rally covers higher level concepts other than simply regurgitating something like "traverse the left subtree of the root node, accessing the node itself, then recursively traverse the right subtree of the node ....".
I think what most people are suggesting is that there is too high of a penalty on not being exposed to a given algorithm. It is not that these people incapable understanding the algorithm or even implementing one. They simply don't remember. I think this is because a large number of people working at google are fresh out of school. They literally have no experience other than the rote memory required to pass their classes (yes, I simplified that a bit).
I will say that I did find a correlation to the age of the interviewer and the type of question asked. The older 30+ and 50+ guys that interviewed me asked practical questions not related to a specific algorithm. The youngest interviewer I had was a complete hothead and started out the interview saying "he was not your normal interviewer so he was going to ask the hard questions" Then proceeded to ask me a rote memory question about a algorithm. Either I had knew it and memorize it or not. That is not a hard question. The hard question have nothing to do with a defined algorithm. They are often open ended and leave lots of rope for you to hang yourself.
If you want to ask questions that require recursion don't make them dependent on algorithms that require rote memorization.
Yes, surely! Have the algorithm explained, or even diagrammed for them with pseudocode.
Let's not conflate algorithm implementation from rote memory with not wanting to answer any technical questions. You can't just come in and start talking about ACID transactions and concurrency as if that is what people have been objecting to.
Let's not conflate the need for a good background with rote memory. I object to rote memory being rewarded by interview questions. I also object to programmers who maintain they don't need to know any of this stuff at all, because they can just Google it and spend a few seconds reading the Wikipedia article. Where in the Dickens did you get the idea I'm Captain Rote-man?
One purpose of training in a highly skilled field is to teach people how to avoid the egregious gotchas. Go ahead and read my other comments in this thread and on this site. I'm not the all conquering champion of rote memorization you seem to think I am.
If I read them in a different mindset then i can take them as a complement to what I said. That knowing how to analyze application performance and concepts like recursion are more important than rote memory. And that interviews should focus on things that can't be ""look up" then read a one paragraph blurb for 3 seconds". I can fully agree to that.
Once again, I am sorry I misread your reply and dumped a wall of text on you.
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.
Places like google give you a guide on how to prepare. So it consists of stuff like algorithms and data structures. I do wonder sometimes how much it is tailored to getting people who are fresh out of college rather than more experienced. My take is that you basically have to spend time preparing and studying so as to get past those types of questions then finally you talk one on one with the people you likely would work with and then it's smooth sailing for experienced people. But the entry bar can be pretty tough to get past with zero prep.
Why should skilled developers with extensive track-records in their field be forced to use their free time to cram for college-style exams? Other professions dealing with exact-sciences / engineering don't seem to have this problem..
While I agree with the sentiment, I wouldn't call it "college-style exams", to be honest. Colleges would be quite different if exams were conducted one-on-one, and instructor would have been willing to talk with you through the problem and cared more about your thought train and approach rather than the exact solution. In fact, I am pretty sure that if you just knew the correct solution and the answer to the coding interview and simply wrote it down silently on the whiteboard (which would be the best outcome on a college exam), you would be rejected instantaneously.
>simply wrote it down silently on the whiteboard (which would be the best outcome on a college exam), you would be rejected instantaneously.
No, jesus. Some people need to switch to a presentation mindset and out of a problem-solving mindset. This is completely normal in life.
I'm starting to think most interviewers are terrible only for not having a decent amount of social interaction with strangers. Let's just admit it's 90% hazing ritual at this point so we can get on with putting up guides to get through it.
Oral examinations used to be fairly common, back when the student/examiner ratio was low enough. There's a legend that the Cambridge "Tripos" examination gets its name from the tripod that candidates sat on during that examination:
Mostly false. Other areas have professional exams, but they're generally industry standards instead of given by the hiring company. This is more efficient if you're a candidate, since you only need to take the test once. (Or more if you don't pass the first time.) My house mate just got a professional engineer's certificate after being at work in the field for about five years.
Of course, if we had this in swe land, it would probably end up looking a lot like those silly certificate programs in soon-to-be-obsolete tech of yesteryear...
I agree. If you take the time to interview at Google or Facebook and you actually want the job it's 100% worth it to bone up on cracking the coding interview as well as the papers they have published about their systems.
Cracking the coding interview is damn near encyclopedic and many interview question you are asked that have a "trick" to them will probably have something you can adapt from the book. You go in knowing most of the tricks and it's a huge edge.
You probably didn't intend this, but your comment reads like you're trying to give advice to the author on how to pass the screening. The author explains how these initial mails set wrong expectations. They specifically mention having zero interest in learning the algorithmic skills tested for in the screening process.
It's a dishonest approach and the response laid out in the article works just fine to weed out shady recruiters doing this.
From what I see around me, there are only 2 ways to get hired by Google.
Either you are a fresh CS graduate, or you need to take 2-3 months off for fulltime study.
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 would prefer to drop out and not waste time for anyone involved. I was very happy to say that multiple times - I know what I don't know. The interviewer goaded me into taking the challenge anyway, saying I'll "definitely be fine and pass."
The next day I attend the timed coding challenge. Three algorithm puzzles that are in no way insignificant. I had Google at my disposal and still could not solve a single problem - although I came close on one involving permutations of chess pieces.
Unreal. At least Yegor had the good fortune of not being directly lied to by the recruiters!
Part of the problem is that these companies don't know who your direct manager will be, since they don't know where you'd best fit! Or worse, by the time you finish your notice period, they've re-orged and another team needs engineers more than the originally-intended team.
One of the skills they're looking for is adaptability/flexibility, to offset the terrible resource planning.
The message I really get from this post is that they'd be happier in a more structured, predictable environment, and there are plenty of places like that, old+new, small+large.
This also solves another problem. Many orgs have their recruiters slot a candidate into a particular role really early on in the process (possibly even before the first phone screen). So you're not applying for a job at FooCorp, you're applying to be a Level 2 Engineer on the WidgetSearch team. By the time the third interview finishes, it turns out you're a bad fit, and the process stops. This doesn't mean there's not a great role for you inside the company, just that the you were tagged for in their recruiting software wasn't it.
By having the future direct manager involved early, they can hopefully say "I need a algorithm person, not an OOP person. Go talk to Carla, she's been looking for someone like this" sooner.
Well, in their defense (Google/Amazon/Facebook etc), a team leader or any other particular person cannot interview 500 applicants, so either more people are interviewers or they are way more specific with initial resume (which can be fake to a big extend).
I don't like algorithm questions either but at least they optimize by time, the alternative is to have people in for a few days, or spend a day doing chat interviews and risk getting a bullshitter.
They don't need to interview 500 people for their generic jobs. Filter people early based on CV and some phone screens and then talk to a couple people and select someone reasonable.
> a team leader or any other particular person cannot interview 500 applicants
While, yes, it often takes interview more than one, and often several people, to find a desirable candidate — it's not that high. Given that any candidate will see probably around 4 interviewers, I don't think asking that the manager interview is that big a deal. I have to agree with that part of the article (though I disagree with it on the whole): meeting your manager-to-be is important. (And I don't think one understands this until one has a bad manager.)
In a prior job, we would also omit the manager interview if it was certain the candidate wasn't going to be a pass.
I did an interview with Google few years ago, I still don't know the position they wanted me for. I make pretty clear my preferences but I was interviewed by random engineers not related with what I wanted to do in Google.
I guess they just want software engineers as workforce. They don't really care about what you want and your skills, if you are very good at something you will probably be good at something else.
There is no standard way to interview a software engineer. Whenever one of these threads come up we see multiple posters explaining their process, and while each process has it's upsides and downsides, no two are exactly the same.
For a company the size of Google, with the amount of applicants they receive, I would assume that an interview standard is absolutely necessary. It's not perfect, but for 95% of developers out there you know EXACTLY what you're going to get when you interview Google. I think there is something to be said about that. Google recruiters tell you what the interview will be like, they give you study materials, and are pretty gracious with scheduling. If you don't like the process, that's fine, but I think Google in particular has done a good job of standardizing their process. It may not work for individual cases, but I would assume it works well for the company.
The problem here is that he wasn't pursuing it, they were pursuing him. Maybe the issue lies in the actual recruitment process, and not the stupid interview questions.
the problem with the way Google interviews is that, despite it being heavily standardized, it is not sensitive to non-algorithmic skills and talents that interviewees have. It will _only_ pass candidates who are unusually good at algorithm puzzles, on whiteboards, under time pressure.
Maybe it's not what they are looking for. Maybe it's only the easiest test, like looking for the keys under the lamp post. It could also be that this way of hiring people turned the company into a specific direction, more attention to the sw and less to the customers.
When I was interviewed for a job at Google I was told there would be 5 different interviews measuring 5 different things:
Pure Algo (which I view as "let's see that your CS grades were earned and not bought")
Pure Coding (let's see if you have a reasonable coding style and design and are proficient with at least one language)
Algo & Coding (a bit of both that makes sure you can solve a simple problem and code it [i.e. work entirely through a problem])
Software Design (so more on your skill in designing code - finding the right abstractions and interfaces etc.)
Systems Design (your ability to design complete, large scale systems at a very high level)
And this is more or less what I got, which seemed fair and logical to me. I agree that it is not tailored to the interviewee's individual skills (for example, your special training in cyber security is unlikely to give you an extra edge), but it makes sense for "good overall software engineer", and if you aren't also a good overall software engineer in addition to your special training in cyber security, then you are probably not what Google is trying to find.
Also, it does look at your skills in coding and design which are both non-algorithmic.
Now whether or not this experience is shared with other interviewees, or matches what you are looking for is something else :X
> it is not sensitive to non-algorithmic skills and talents that interviewees have.
I work at Google and do interviews (though I don't enjoy them). We do ask questions around domain expertise, software design, etc. It's not all just coding and algorithms.
A good question:
1. Has a low enough floor that a poor candidate can still make some progress and not feel like they are doing poorly and get stressed out.
2. Has a high enough ceiling that a strong candidate doesn't blow through it in five minutes.
3. Has a smooth ramp between those points.
4. Doesn't rely on too much domain-specific knowledge so that a candidate who happens to have a random gap in their background that leaves them totally hosed.
5. Is concrete enough that the interviewer can capture that feedback in a way that the hiring committee can easily understand.
6. Isn't well-known outside of Google as stock interview question so that candidates can game us by just learning the answer.
7. Isn't asked by any of the other interviewers the candidates sees.
8. Can be explained and worked through in about twenty minutes.
In case it isn't obvious, it is really really hard to find good questions that pass that gauntlet. Questions do tend to skew towards smaller-scale algorithm coding questions because I think those tend to survive that gauntlet better than most other questions.
> unusually good at algorithm puzzles
Interviewers are trained to not ask "puzzle" or "trick" questions. Not only are trick questions a shitty experience for the candidate, they are a shitty experience for the interviewer too. My job in an interview is to get as much data as I can about a candidate in order to provide information to the hiring committee. If I ask you a trick question, I get about one bit—in the binary sense—of data from you: did you find the trick or not?
I don't think you have to be unusually good at algorithms. I basically read some Wikipedia articles and spent a few hours in the hotel cramming Algorithms in a Nutshell, and I managed to squeak through.
That time was incredibly well-spent. Since then, I have relied on that algorithm knowledge way more than I expected too, and have since spent more time learning algorithms and data structures because I can clearly see it's made me a better programmer.
> on whiteboards,
That part is hard. We allow candidates to use a laptop too, if they prefer, or both. My experience is that candidates who use the whiteboard, at least for the earlier "design" parts of the question tend to do better than the ones that go straight to typing.
We need to learn how you think, and putting a screen in front of people tends to make them clam up. If all I see is the code you write and you don't explain your thinking behind it, I don't get much data.
> under time pressure.
That part is really hard too. The reality is that interviewers and candidates have a limited amount of time they can put into this process. Keep in mind that most candidates are currently employed and don't want their job to know they are interviewing. Many of them travel to interview. There are only so many hours.
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 process probably works well for the type of employee Google/Youtube wants to hire.. shame on me for not doing my homework.. I guess. 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. At least 5 times: me: 'I live near Princeton'. they: 'oh, did you go to Princeton??!!! (elation)'. me: 'No.. I went to a state school'. they: 'oh.. ' me: (silently) 'yeah.. I'm sorry. It gets better.' Again, whatever.. in truth, I appreciated the opportunity to interview.. no big deal.
What was even weirder after that was, for no less than 6 years, to be 'actively' recruited (again) by Google. My position each time was: thanks, but not interested in going through another bullshit interview where I'm continuously reminded that I didn't go to Princeton. I'm just not Google material.
In all seriousness, in my opinion, Google is one of the best companies in the world and is run and staffed by the best minds in the Industry. My hat's off to them for all of their accomplishments. I just don't want to work there (even if I could :)
> 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 rare breed I was at Google until after I got hired. (I came from the game industry where college degrees weren't as important.) There are so many over-achievers here, that I think many Googlers have never even considered that someone may not have gone to one of the top ten CS schools in the US. Especially in Mountain View, literally everyone they know probably has.
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 knowledge from memory is not necessarily a bad developer, or, frankly, in any way otherwise distinguishable from the guy who can.
> 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 the knowledge from memory is not necessarily a bad developer
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.
> 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.
> 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 comes from misunderstanding, rationalization, or what, but in my experience at least, neither do most of my coworkers.
That is, I at least don't recall a rote algorithm when interviewing In fact in one of my interviews (not at google, but I could see a similar question happening there) I had to derive a solution to a problem in a space I was totally unfamiliar with (locking and multithreading).
It seems like, if you assume (incorrectly) that somehow you can't cheat the system, Google is selecting for people who can solve unfamiliar, complex, problems by applying first principles. That is, I think, orthogonal to the idea of 'theoretical or practical' computer scientist.
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?
So, I think my biggest issue with your A/B dichotomy is that I don't see it. That is, in school, in myself, in coworkers, there isn't this large group of people who are trying to do all the theory at the expense of practicality, as opposed to this group of stuff-accomplishers who aren't theoreticians.
I mean, occasionally those people exist, both the "fuck it I'm going to sit down and type until it works" people and the "I must understand this concept before I write a single line of code" people. But as you say, everybody is a mix of both, and I think most people are nearer the middle than the sides, which makes the possibility of mild bias towards one side or the other a lot less harmful than you maybe expect.
The thing is that as an outsider looking in, I see a lot of evidence that Google has this dichotomy and suffers from it. I mentioned some of it in my posts above, but in general, a lot of the company's pain points from my perspective - and from the perspective of employees less satisfied with their experiences[1] - fit what we'd expect from such an enterprise.
Here's an example of what I mean: Google is a company with incredible tech and quite a lot of money, but its products tend to fall into clear patterns. First, create something awesome, then fail to support it, then fail to monetize it, and eventually, it fall to the wayside and is discontinued. There are so many apps Google has created that fit this mold that people have done meta-analyses on how long the average Google product lasts.[2] Obviously, not all Google's products fit this mold - but I think Google is unique in being able to support this pattern, fiscally and from a development fatigue standpoint.
This pattern is exactly what I would expect to find at a company that is mostly based around theory and concept, and that is either inexperienced at or disinterested in support work after the initial execution.
It's probably true that most people, even at Google, are somewhere in the mid-range. However, a large enough group of people with a small bias will result in a shift in the policy of an organization. I still think it's fair to say that, if my dichotomy exists, it would effect Google's institutional behavior even if the degree of difference between people is low on average. That is to say that while you may not see it, it also may not be obviously or even at all visible from the level of one person in one part of the organization, whereas its effects are visible from both within and without. It's kinda like dark matter - you don't know what's happening in someone's head, so you can't observe it directly, but you can predict outcomes based on hypotheses and see what comes true.
Interesting, when I read those answers, what I see is more or less people saying "management can sometimes be downright bad, and is often stupid". I very much doubt that many of the people (broadly) deciding which products to support and which to drop were hired via a new-grad-like interview process.
For things like moonshots/other bets, the "build something awesome but don't monetize it" makes a lot of sense, since the entire point of that division seems to be "build something awesome and see if it is sustainable too". More often than not, unfortunately, the answer is no.
In fact, if anything, I'd reverse the cause and effect in your idea. If we presuppose that there is this dichotomy in people and it affect google's motives and goals as a company, then this would influence the tech hiring practices to be the way they are, not vice versa.
> I very much doubt that many of the people (broadly) deciding which products to support and which to drop were hired via a new-grad-like interview process.
I'm confused as to why you doubt that. Google's been around for almost 20 years. Their interviewing process has been around since at least 2003.[1] It's 100% possible that somebody was hired, ended up in higher management, and graduated to making driving decisions (at least over a particular area) in that time, unless your suggestion is that nobody who enters as a new grad ever stays long enough to get to that level, which at Google (vs other SV companies) seems unlikely.
> For things like moonshots/other bets, the "build something awesome but don't monetize it" makes a lot of sense, since the entire point of that division seems to be "build something awesome and see if it is sustainable too". More often than not, unfortunately, the answer is no.
It does make sense, it's more the messaging around those kinds of projects that tends to get lost. You end up in situations where thousands or sometimes millions of users are relying on a "beta" product, which has no monetization strategy, and then gets scrapped. It's a pattern that's still unpleasant for end users and not great for Google's reputation.
> If we presuppose that there is this dichotomy in people and it affect google's motives and goals as a company, then this would influence the tech hiring practices to be the way they are, not vice versa.
That's a great point, and likely, assuming of course that Google started this way (I think it likely did, given its founders' backgrounds). It creates a self-perpetuating cycle, though, which still ends up being problematic.
> I don't think you have to be unusually good at algorithms. I basically read some Wikipedia articles and spent a few hours in the hotel cramming Algorithms in a Nutshell, and I managed to squeak through.
Either a lie or you are unusually good at algorithms. People work > 50 hours on Leetcode, CTCI, etc. to try and get a job at Big 4. A couple of hours just reading Wikipedia articles isn't even close to the amount of effort people put into 'gaming' the system these days.
That was the only prep I did for the interview. I was a senior software engineer at EA at the time, with about a decade of professional software experience.
I don't have much of an academic background, but I had written and shipped quite a lot of code by that point in time.
The cramming did help—several of the algorithms I read about were either new to me or I hadn't seen in ages—and some of them did come up on the interview. (I've also used almost everyone of them at my work at Google since, strangely enough.)
My point was just, if you are already a good enough engineer to be successful at Google but don't "interview well" because of whiteboard experience or algorithms it's pretty easy to shore up those two things. You don't need to spend a decade at a monastery meditating on Knuth.
If you're a decent coder, you've already done way harder things. Breaking down a big messy problem into pieces you can code and test is hard. Shipping applications is hard. Breadth-first search is not hard.
you're missing something important about my comment. the issue isn't the hair-splitting difference between what you call "puzzle or trick questions" and what you describe as "a good question" (with your eight criteria). the issue is that Google style interviews ONLY ONLY ONLY ask coding questions in a pressure cooker environment.
I've interviewed at Google and the interview experience was sufficient to convince me that I'm not a culture fit. Maybe that was the point. I tend to thrive in work environments where my "soft skills" matter more. Seems like that's not even on the radar at Google.
> the issue is that Google style interviews ONLY ONLY ONLY ask coding questions in a pressure cooker environment.
By "pressure cooker", to you mean in terms of time, or more social intensity? There's not too much Google can do about time. Like I said, it's not fair to ask candidates to dump weeks of their life into the hiring process.
If it's about the social intensity, I agree, that's hard. Many programmers are introverted and being "on" for an interview is really really difficult. It's one of the reasons I don't like doing interviews—it's hard for me on the other end too.
We are trained to try to make it as relaxing and pleasant of an experience as we can, but there's only so much we can do. The reality is you're in a 1-1 conversion with someone with a fixed time bound and where your performance may alter the trajectory of your life.
That is a stressful experience, no two ways about it.
Here's the problem I have with interviewing, speaking as someone already at a big 4 company and has gone through this process already. I know exactly what types of things I need to prep for and even as someone who's competed in competitions like ICPC and TopCoder, I'm always worried that I'll get the type of interviewer who will just ask obscure questions and not go to the level of depth you mentioned when it comes to working with the interviewer to assess their problem solving skills vs just checking to see if they know the solution to some trick question - the kind that most people not knowing the solution beforehand would almost never be able to figure out within 30-60 minutes.
I'm planning on interviewing with Google in a few months just because of all the great things I've heard about their infrastructure and engineering culture, but due to these concerns I've budgeted to use my current vacation time just to get back into prepping the way I did when training for ICPC just so that I'll have confidence knowing that most interviewers probably have never studied algorithms at that level and that I'll have more confidence in not being potentially tripped up by these types of interviewers.
Most of my friends, even those at Google, have tried to convince me that this plan is overkill but I just can't get myself to leave the fate of my future into the hands of some random interviewer and then regret not doing this level of preparation if I get rejected...
What I don't understand is that this person hasn't even had a Google interview... They literally say
"I won't accept an interview at Google because:
1. I had a bad interview at Amazon (???)
2. I read a story on HN about someone having a bad interview at Google
I'm sorry but that's an awful excuse. As you mention, Google works at an insane scale, and as foolproof as you try to make a process, there will always be a very small chance that it'll fail. Doesn't mean the whole process is bad.
And there's the whole bias that you'll only hear from horror stories and never from success stories.
I got part way through one interview process with Google -- never again. I'll stick to buying lotto tickets, the odds of 'winning' are about the same and the payout is higher.
Not to mention lotto isn't quite the tremendous time-suck that playing the Google interview game is (I mean, sometimes you get stuck waiting in line behind the old lady buying $500 worth of scratch tickets so you can buy your one powerball ticket, but still...)
There is no proof that joining Google is a lottery ticket(ie: whether you get in is luck). I have interviewed at Google, Amazon, Msft all multiple times and have passed every single one of their interviews multiple times(ie: I've never failed). If you want to attribute it to luck, then luck is when preparation meets opportunity.
You think preparation alone can get you in the Big4?
Obviously you are very smart if you passed every single one of their interviews multiple times. Hard work alone won't get you there.
Just curious, so where do you work now?
I do think that hard work and preparation can land you a job at these companies. I went from doing a manual labor job and never making over $33k/yr, to busting my hump 4 years in University to land these jobs. I also recognize that interviewing is its own skill that needs to be worked at, and simply doing LeetCode questions or reading Intro to Algorithms by CLRS isn't everything. I can honestly say that I have never had all the interviews go my way during a loop. I have been given problems where I could only find the naive solution. I have been in an interview where I made it through the first teaser question to be completely stumped by the second question. And I have made really ridiculous coding mistakes like increment the string variable instead of the index variable. But I also manage to never beat myself up about these mistakes, always talk about what I'm thinking during the interview, listen and try to apply the hints that the interviewer gives me, and have pleasantries with the other person during the interview. I dress well, always with a fresh haircut and clean shaved face, wear deodorant and take a shower the morning of an interview, and walk with good posture, because I do think that these things matter.
I do also believe in the interviewer anti-loop (see Steve Yegge's blog[1]), but I also think that it doesn't really matter unless you really want to work for a specific one of these large tech companies.
I currently work at Microsoft and just finished interviewing with a couple of the other large tech companies and have pending offers from them. I don't know, maybe I am smart, but when I see people like Andrei Alexandrescu or Mark Russinovich speak, or watch a video of Grace Hopper explain how she demo'd nanoseconds to military generals, I feel like an idiot compared to those people. I personally think you obviously have to have problem solving skills, but also gumption and a can-do attitude goes a long way.
I am not a standardized programmer, so I have no interest in Google's standardized interview. I tell their recruiters I am not interested as I doubt you would hire me anyway given I don't fit your standardized system. When you design your system for some specific person type, that's all you will get.
Yep. Your path into the company (were you interested in joining it) is:
1) Found your own company to do a specific thing
2) Prove out you can do the thing and do it well, and furthermore have the thing be valuable enough that it would be worth acquiring but not valuable enough that it can operate as an independent company that covers its own costs
3) Google decides that what you're doing needs to be part of their portfolio and they buy your company and staff.
I think when a company reaches a certain size it is hard to expect that there is such a thing as "a manager looked at my github/qualifications and decided they need me so they will tailor the interview to my skillset".
At this point it feels the interview process is becoming more of a combo between a hazing ritual and a lottery than something actually useful to ascertain if the person interviewed would be a good match for the position or not.
The longer the interview is, also, the more likely one will be discarded because one of the many interviewers is having a bad day, or because after several hours of whiteboarding one can understandably draw a blank on a simple question they would've waltzed through 4 hours prior and be failed because of that. How long before interviews also contain an anti-doping panel to weed out candidates trying to improve their odds?
It is strange though that in a country where there is at-will employment one is basically told that hiring the "wrong person" could destroy the company or something and so the interviewer has to make really really really really sure that the candidate is absolutely ok.
I personally think the risk of hiring somebody and they can't cut it after three months and you have to let them go, is worth not passing the candidate that doesn't do well at whiteboarding but will instead prove to be great when tasked with real business problems that take more than a few minutes to solve.
I think when a company reaches a certain size it is hard to expect that there is such a thing as "a manager looked at my github/qualifications and decided they need me so they will tailor the interview to my skillset".
Why? As a matter of fact, I have a friend who met a manager at Burning Man, then was hired into Google in just such a manner. He described the Google interviewing process as "a breeze!" My reaction: What!?
It is strange though that in a country where there is at-will employment one is basically told that hiring the "wrong person" could destroy the company or something and so the interviewer has to make really really really really sure that the candidate is absolutely ok.
What it does is destroy the recruiters reputation and KPI charts.
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 falling out of the funnel is surprisingly easy!
It's amazing how often "Hey, thanks for reaching out, I'm interested. Can you tell me more about the role?" results in the conversation ending right away. Probably over 50% recruiters that contact me do not reply back after that very polite and neutral response.
Many who do keep the conversation going have not read my profile or resume carefully, so I'll give them a summary of the types of work I'm actually interested in, which is never what they contact me for, and politely decline to move forward with the (usually way too junior) role they are looking to fill. That will almost always end the engagement.
Sure, it's a lot of noise, but filtering is very cheap: the time it takes to reply back. My actual success rate with recruiters probably pretty average. Of the eight or so jobs I've had in my ~20 year career, about three were obtained through recruiters, two times through in-house staff, once through an external recruiter.
To paraphrase you, there's always that remote chance that one of the Nigerian Princes could actually need your help.
I used to do a similar thing to you, but it's too much work now and the levels of job spam ("Oil pipeline engineer" roles, simply because my CV has the word engineer in it (prefixed with Software)... lazy recruiter, that's bad!). Basically, if they can't make the effort, why should I? I guess the answer is, "Because there's always that remote chance that one of them could be able to set me up with a "dream job""..
Recruiters and Nigerian scams aren't comparable. People legitimately get jobs through recruiters. I got my dream job through a recruiter who found me. Nobody gets the Nigerian Prince's money
My logic is that if something needs to be actively sold (pushed via recruiters), it's most likely average at best. I'm betting that the best jobs don't go through recruiters (or maybe they do if that's the company-wide policy, but the hiring manager already has a candidate in mind when they posts the ad).
You've hit on a truth here. Most of the jobs available through recruiters are what I like to call "dog jobs". The ones that aren't filled internally and don't instantly get a line of top candidates because they are so good or pay so well--the ones that NEED someone to sell them. Those are the jobs that are available on job boards and that recruiters and are trying to fill--not the awesome ones.
Think about it like the real estate market (in normal markets, not Silicon Valley). Some houses sell before they even hit the market. A few also sell after the realtor does a few private showings. The rest are the "dog properties" that go on the MLS and need heavy marketing to sell.
> The rest are the "dog properties" that go on the MLS and need heavy marketing to sell.
That's... a strange way to look at the housing market. The norm is to list your property and then see what bids you get. Putting your house on the market is not some weird trick to pass a crappy house on to a bunch of rubes, or am I misunderstanding you?
Like, how do you reliably find a willing buyer pre-listing, and how do you know that's a good price (other than just blindly trusting your agent), if you don't even bother listing it? Listing is as much about price discovery as it is about finding more buyers.
The point is that the best homes(top 10%) rarely need to go on the market.
The hotter the market, the more realtors know buyers willing to pay a lot for the first home that meets all their needs. Hence more homes are sold before listed.
This assumes that the Venn diagram of "top candidates" and "people actively looking for jobs" overlaps significantly. The best candidate for a job may not be looking for a job so companies pay recruiters to find them.
If the quality that companies were getting from regular applications was better than the quality they get from their recruiters why would companies pay to have recruiters?
I think we're agreeing with each other. Recruiters are needed if the job does not fill itself naturally, and a job will tend to get the candidate flow it deserves.
If there's an awesome job available out there, with way above average pay, benefits, great opportunities for advancement, good work/life balance, etc., you'll fill it with a top talent. You're not going to need a recruiter. Word will get around even to people who are not actively looking, trust me. Similarly, if you have an "average pay for an average worker" kind of job, you'll find that average worker.
When you have a ho-hum average job but you want top talent, then you're going to need that recruiter because the job needs to be actively sold.
I invite anyone who works at a company that pays 3X average salaries or is well known for being an unbelievably great place to work to reply and tell me they have trouble hiring.
Google and Facebook both pay reasonably above-market and have high employee satisfaction, and receive more resumes in a month than they could possibly hire in the next 10 years. They also both have ginormous internal recruiting departments.
They could definitely fill their need for new software engineers naturally, but presumably have data that the quality of candidates they get by bothering a substantial fraction of the world's software engineers on ~a yearly basis gets them better applicants and engineers.
Jobs do not fill magically. Most of us is too busy with work, side projects or family to track if your amazing company have new hot opening.
Above average people are usually treated well in theirs jobs. If you want to hire them you need to actively approach and lure into applying. Even then, they will not bother to refresh algorithms questions for whiter-boarding.
Below average people are looking for jobs because they are on PIP or they have toxic relationship with management or they will never get promoted in current role and need to change jobs.
The housing market in the Bay Area is very different from the housing market literally everywhere else in the US (except in some ways Manhattan). Pre-listing sales are very rare outside of SFBA and Manhattan, and the vast majority of domestic residential sales (>70%) are of MLS-listed houses/units, even in major metros like Chicago and LA.
The "dog properties" don't get listed on MLS at all; there is a cost to listing on MLS and the dog properties generally don't generate enough interest to justify the expense (and usually don't even attract a realtor willing to invest the effort).
I don't think it is really trying to sell the position, it's trying to find quality engineers who aren't looking.
Really talented engineers already have jobs and may not be actively looking to move, but if the right opportunity for the right company presents itself then they might consider it.
I tend to agree with you and try to at least be cordial with recruiters in my region. I have gotten 2 jobs from recruiters, both being external recruiters.
Once I applied for a job that had a really obscure job requirement which I met. The job was already filled but I spoke to the recruiter, who was really nice and ultimately found me a different job in another skill set about a month later.
The other was the traditional thing were a recruiter reached out to me. I actually didn't like the recruiter, but I liked the job and ended up pursuing it anyway.
I've been responding with "Sorry I'm pretty happy where I'm at right now, but can I keep your email address and let you know when I do start looking for something new". My goal is to have a giant mailing list of recruiters when I do start looking for work again.
I've found that working with multiple recruiters can be a nightmare if they are all working the same geographic market.
Due to my current situation, I tend to only deal with recruiters who are local to where I live; unless the job opening allows for telecommuting, or it is a "too good to pass up" situation (I have yet to see one) - I will generally pass it up.
Instead, I currently only work with a couple of local recruiters. I have told both what I expect for interviewing (I prefer a practical interview with tests - not a whiteboard pressure interview), and I keep both informed what interviews the other has sent me on, so they aren't both submitting me to the same position opening.
Going beyond 2-3 recruiters in such a situation can and will lead to a tracking nightmare, to keep all of them in synch and not submitting you to the same opening - either at the same time, or worse, after you have already been interviewed once and weren't successful.
I do however, try to review the contacts I do get from recruiters, and if I feel they might be useful in the future, I tell them so, and keep a contact with them (even if it is just a LinkedIn or email contact) - and let them know I am interested in the future. That'll usually be enough for them to keep me in their DB for future potential offers to come up.
In my experience, recruiting is a fairly cut-throat industry with a very high turnover rate of staff, so once you come to use your list you may find that a fair proportion bounce (or are redirected to someone else). It can't hurt though!
I have the same experience - it's easy to turn down if you are not interested, or if they what they propose is a bad fit.
I also think it is good to remember how extremely lucky we are to work in a field where there is such high demand. I have several friends that are in a technical field (but are not developers) looking for new jobs, and they have to work really hard to find anything. For developers, we can just sit back and wait for employers to look for us.
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.
A CEO of a small company once sent me what might have been a really interesting opportunity and I was going to reply but then I noticed the tracking links and realized it was just a very-well-crafted form letter. I stopped considering it then.
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.
Tracking pixels on emails aren't always an indication of a form letter. Marketing folks use lots of services that add tracking to all their outgoing email. (Whether that's OK or not for you is a different matter, I'm just pointing out that it could have still been an individual email.)
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.
My partner works at a recruitment company. Here's the thing: most recruiters are not very good at what they do and are only chasing placements. To get the most out of recruiters you need to be more pro-active, and find a recruiter or two who really understand your skill set and career ambitions. Build a relationship with them, and don't waste time with the other 90% of batch mailed crapshoots.
I don't doubt that this is the way to find a good recruiter. However, if I am going to put in the time to vet multiple recruiters in order to find one worth working with, why would I not just spend that time finding a job?
It's hard to get an accurate pulse of the market if you spend only a month every few years searching through angelist/indeed/etc.
I work with about 70 companies (only in NYC) from pre-launch to almost IPO and a new role opens up to a us every week. It's helpful to find a recruiter who knows you & the market well enough to curate jobs you want and tell you about opportunities that might not even be listed or on your radar.
This is true. I'm an engineer that started recruiting six months ago part-time and was able to bill six figures pretty quickly. I realized that colleagues in recruiting had a really tough time making efficient matches.
The best recruiters can not only make efficient matches, but they also connect the dots to reach out to matches in the pool of passive candidates they talked to when a new role opens up.
Even better than that is when I'm able to actual push back with companies and make an impact on the hiring process to get someone hired.
How'd you get started doing recruiting? I've been talking with recruiters lately and I find myself doing enough tech explaining to recruiters that I've wondered if I could consult for them. Interested to hear about your experience.
Feel free to e-mail (in profile). Started by trying to build tools for recruiters and interviewing recruiters for customer feedback. Found a good fit with a recruiter who placed my whole NY team before our startup got acquired and he offered me a consultant gig. Really enjoying it so far. Great way to monetize a mix of engineering career consulting + staying on top of startup trends.
Interesting! Do you feel like as you get further and further from having done the actual work (that you're helping recruit for) that you'll still be as effective?
I'm still coding professionally (js eng) and stay on top of trends! But, I don't think coding in the trenches will make me more effective. I've had a few eng. jobs, most of my friends are engineers, and I'm really passionate about job trends, job satisfaction, and employee retention.
With that foundation I'm more effective as I see more career trajectory data points when I talk to candidates that specialize (data, security, devops, ml) or ladder up (vp, manager, cto). Then I can provide even more value to new candidates with the career counseling approach.
> Here's the thing: most recruiters are not very good at what they do and are only chasing placements.
Related anecdote: There was a technology recruiter that was constantly calling me at work, despite the fact that my work number is not listed anywhere* and my LinkedIn profile having clear instructions not to do that.
I decided to look him up on LinkedIn. Guess what his previous job was? Debt collector.
* I figure the recruiters get around that by calling the front desk and asking to be transferred to me.
I like getting recruiter emails because it kind of means I am marketable, even though some of the recruitments can become an anecdote I can talk about at a dinner party with friends... (you know one of those totally weird recruitments)
But mostly I want to get it because I want to see what these companies are expecting from their candidates, technology these companies are using, and the salary range. DevOps / SRE / Production Engineers are high in demand.
A colleague of mine gave me some excellent advice here. She redirects recruiters. I am very happy with my current job so I'm not generally interested in emails from recruiters. However, I do hav many friends who are at jobs doing things below their potential. It's always good to see if the job fits anyone's profile, even vaguely, and redirect the recruiter to them.
(I don't redirect all recruiters, though, so there's still a filter)
As a young person with zero other commitments to worry about (kids, loans, etc), I'm really enjoying what I work on (and get paid pretty well) and that's enough for me for now. This could change in the future. I'll keep your advice in mind in case this situation does change :)
Head hunting is very profitable. If you get a recruiter email for a company that is not that company, it's _always_ junk. 100% of the time, it is a waste of time. Ignore those, and look for the ones that are from the actual company.
They have their own recruiting team that you are going to be dealing with anyway, and aren't playing the numbers game or shuffling their candidates between many different companies trying to get their (usually very large) hire bonus. They just throw as many people they can at as many companies they can till they get a bite.
Senior employees can be up to a FULL YEAR of the hired employees salary. As that employee you don't pay it, but it's not something that is benefiting you either. On top of that, the companies often have claw backs. If the employee leaves under a certain time, they have to give back their fee.
The reason they don't respond after the first email, is that they need someone who is going to be very proactive and actually motivated to get hired. Else their candidate catapult might hit the target, but less likely to stick.
Yes, it is possible to get hired with the use of 3rd-party recruiters, but it is still not in your benefit. If they never got people hired, then they wouldn't make money and even try.
If you don't have any way for companies to target you themselves, then 3rd party recruiters might be more effective the you targeting companies directly yourself.
However, if you are in the boat where you are getting many recruiter emails a week, my advice is sound. They are all junk, and the only way to get any signal to noise is to look for ones directly from the company doing the hiring.
100% true. I almost always reply to recruiters with my rate and ask if they can afford it "since most companies that pay recruiting fees cannot pay full rates."
>If you get a recruiter email for a company that is not that company, it's _always_ junk
Not true. Companies hire recruiters to find employees. Not all companies (especially startups) have their own internal recruiting department.
The flip side is true, though: as a company trying to hire people, every recruiter email that says "I have a perfect candidate for you" is junk. They just invent those people or send resumes of people who aren't even on the job market.
Massive difference between sourcing candidates and interviewing/making hiring decisions. If a founder is doing the former it's probably that she's wasting a massive amount of time and there is a huge opportunity cost there. Recruiters have their place.
I see you're working as $ROLE in $COMPANY_A. How would you like the exact same $ROLE in $COMPANY_B? Or worse, How would you like $ROLE-1 in $COMPANY_B.
Sorry but it's going to take at least $ROLE+1 to get me to uproot my life and go through that interview gauntlet again.
Of course, as I said in another post, the calculus changes entirely if you're unemployed and need "something, anything".
Agreed, this makes perfect sense. I'll even go further and let them put me up in a hotel / buy my plane ticket even if I'm not particularly interested. Going to interviews is a lot of fun.
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 the bottom, there's another email alias along the lines of 'yesireallydidreadthisgiganticemail2017@mydomain.com' that goes straight to me. I ask the recruiters to not email that address unless they've read the whole thing, and their position matches my requirements. I get 200+ emails to the catch-all autoresponder a month, and maybe 1 (qualified!) reply to the 'its really me' alias every six months. About once a month, I get an email to the 'its really me' alias from a recruiter expressing joy, amusement, and thanks for spelling out what I'm looking for so early in the process. All in all, it's a far more pleasant way to go about passively searching for The Next Big Role(tm).
I think you're right to thank them for their difficult job. I seriously got bored just reading the description of your setup. What percent get through to the second email? Is it like 10%? 50%?
(1 per month + (1 per 6 months)/6) / (200 per month) = 0.58%.
The more important nugget is that he is contacted about two attractive opportunities a year for his passive method that have a fairly high probability of leading to offers if he is interested. This enables him to:
1. Accurately appraise his worth to companies,
2. Quickly scale to a much higher number of interesting opportunities through the 14 worthwhile recruiters per year that already value his conduct (even if only 2 per year have opportunities with appropriate fit) by actively involving their aid if he becomes dissatisfied with his current employer/role (or they become dissatisfied with him),
3. Identify hiring trends in his field.
I for one think it is a brilliant strategy, and I'll probably adopt it myself!
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?
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% of it is for jobs within the surrounding city, 10% for within the state and 10% out of state. That said, most of these jobs you could also find without the recruiters as well, but sometimes ones from internal recruiters (and if you're lucky a developer/dev manager) are useful.
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.
Another interesting bit I've noticed is coworkers getting some of the same recruiter spam from the same recruiter. Seems some of them just blast everyone working for a particular company and hope to get a reply.
I think location is very important with these sorts of profiles. I'm on linked-in, Indeed and career builder.
I normally get nearly zero recruiter emails, but late last year I changed my location preferences on Indeed and/or Career builder (I don't remember) from my hometown to Washington DC and suddenly I was deluged with the 20+ recruiter emails per month; more right after I update something on my profile.
Strangely, 1/2 of the emails are for locations far away from DC. I might try changing my preferences to San Jose and see how many more I get.
My "profile" is pretty much just my resume. Experience seems to be another important factor.
AND work on IT. As an housing architect I received zero offers from recruiters despite having relevant experience. By the other hand I have been contacted several times by IT recruiters once I listed there (irrelevant) IT side projects.
Yes, I've gotten my last 3 non-consulting jobs through this method. Before I switched to FT consulting, pretty much all of my jobs were through recruiters. The 'wizardry' is basically having a well put together resume (I've had several people/orgs/etc take a look at it over the years and give me optimization tips), and I maintain profiles at dice, monster, and indeed. That's... about it. I avoid LinkedIn like the plague because I detest the company and its practices, but I'm sure folks who are less picky than me could do something similar on LI and EASILY get more than 200+ contacts a month.
1) I'm impressed by your technique, and I intend to copy it.
2) The numbers in that autoresponder caused my jaw to hit the floor. I thought I was well compensated but apparently there is a lot of room for me to grow!
If everyone does this, then recruiters will simply start to spam the yesireallydidreadthisgiganticemail2017@mydomain.com emails without reading the autogenerated "profile".
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.
You didn't take it too far, someone build the first online recruiter focused video game where the prize at the end of each level is the contact details for a more-and-more suitably qualified candidate.
What about 1% of people doing this? Or even 0.5%?
That is easily enough to live off, and enough to slip under the radar.
To me, getting this done on interesting domains seems to be the hard part. For people with their own domain, getting a separate server to deal with email for that is some hassle. You can't really do this on a generic domain either, cause that looks a lot less professional. Signing people up for gMail accounts might work, but that's probably against google eula. I'd guess the same for other webmail services that are at least somewhat professionally acceptable.
Best way I see is to give people with their own domain as easy a time as possible to set up DNS correctly. Getting through DKIM and SPF reliably seems like a minefield though.
Dude, you can do it yourself with a gmail throwaway. 'hireme.myname@gmail.com' or similar, set your vacation auto-responder appropriately, and have 'realdeal.myname@gmail.com' auto-forward to your real address.
Many years I had sent out resumes looking for work as a MCSE. Never mentioned novell. Guess what? Recruiter emailed me looking for novell engineer... Hw fell out of my funnel real quick.
I always give recruiters a fair go with their pitches (I'm between contracts now and today I had maybe 10 recruiters pitch me positions) - Most of them are pretty good at their job and they come up with decent stuff. You just have to ask the right questions to probe them and understand if the opportunity is actually good for you before you take it to the next phase.
As an engineer you should have a clear picture of the kinds of companies that you want to work for. As you get older, your selection criteria should improve and become more detailed.
> I should have told her that I didn't want to be interviewed by some programmers, because I would most certainly fail. There was no need to try. I wanted to be interviewed by the person who really needs me: my future boss. That person will understand my profile and won't ask pointless questions about algorithms, simply because he or she will know what my duties will be and what kind of problems I will be capable of solving, if they hired me.
While I agree with the author about algorithm questions being relatively pointless, my sense is they don't know about the team matching process. After I interviewed with Google, they presented me with a list of a eight teams who were interested in me and asked me to rank them in order of preference. They then had me come back a second day and meet with the managers of the top four teams I selected. At the end of the day, I ranked the teams again. The team I ranked the highest who also wanted to hire me was the team I would have joined if I had accepted my offer.
I much prefer the current process where you have one day of general interviews, and then go back a second day and just talk with the managers of the teams you would be interested in. It would only make the process much more of a hassle for everyone involved if you had to be interviewed by the managers of every team for which there was mutual interest.
Amazon won't hire you just for one role. The company allows free movement between teams by SDEs. If you're an SDE, you're an SDE, and you're welcome to change teams so long as the new manager will take you.
If you don't know algorithms, maybe that's okay for the team you're joining. But hiring you means screwing over the team you're going to be on in 3 years. That's why they interview that way.
You aren't going to interview with your future manager because they don't know who your future manager is. They need to hire hundreds of people, they aren't going to try to get separate candidates for each role, and they aren't going to have you interview with a hundred different managers.
My company is experiencing this as we grow; we have too many openings to have each team try to recruit for their open spots. We need a more general queue of talent to hire, so that we can interview for 10 open spots for every interview we do.
> You aren't going to interview with your future manager because they don't know who your future manager is.
I generally agree when it comes to cold resumes. However, in this case, OP is talking about being actively recruited. In that case there ought to be a specific manager that was looking for a specific type of person. Otherwise the recruiter is just wasting everyone's time.
I recently interviewed and accepted a position at Amazon.
Prior to the interview the recruiters did a great job of preparing me for what to expect.
My direct manager was also part of the interview team, so I got to meet them.
Overall it was a very pleasant experience, which is part of the reason I decided to join.
I really like this strategy, fighting back against these monolithic HR departments and bored engineers asking terrible questions is something we need to do more and more.
> I learned my lesson two years ago, when Amazon tried to recruit me. I got an email from the company that said they were so impressed by my profile and couldn't wait to start working with me. They needed me, nobody else. I was naive, and the message did flatter me.
I learned mine with AWS as well:
Scheduled call. They forgot to call. Waited like an idiot for an hour. Ok fine big company yadda, yadda.
Had the phone interview. Liked me, called me onsite.
Before coming onsite was sent the Leaderhips Princples and told to learn and will be quizzed on them basically. Had 2 offers in hand already and was told they'd get back to me at most 2 days after the interviews.
Got to the site. Future manager who was supposed to interview me not there.
Whiteboard questions, solve some algorithm puzzles. "Tell me about your worst failure". Most people I talked to would not have even worked with. People did not seem happy, kept warning me about how hard it is to work there and so on. (Subconsciously perhaps telling me to stay away?)
Lunch time comes, at least think I'll eat lunch with future team. So I wait, and wait, and nobody shows up. Ended up wondering the hallways exploring. Hoping someone would ask me if I am supposed to be there.
Then I got a bit snarky after that and kind of gave up on the chance of wanting to work there.
Went home. It took them 3 weeks to call me. But I wasn't surprised by that point.
LOL, your experience was much like mine. They sent me a ton of stuff to study pre-interview, which I thought was odd way to bias my answers (I attribute that to the recruiters trying to game system to get more of their finds hired and look good). When I got there the door was locked and I was trapped in an ante-room with another candidate waiting for 45 minutes. Interviews with a bunch of randoms, half from other teams. Only one whiteboard test which I apparently didn't do well on.
Back in the 90's and early 2000's in non Silicon Valley tech companies, this was Simply Not Done. I find Silicon Valley tech culture a little loose when it comes to interpersonal morals.
Shitty experience of not showing up apart, I know that, at Google, the fact that the hiring manager isn't involved in the selection process is done on purpose, to reduce bias.
I agree with this post. I've turned down Google interviews twice precisely because I was immersed in personal projects and didn't want to spend the time needed to practice algorithm writing just for a test. I could understand if they ask you practical questions like "when and why would you use a trie?" that seems more appropriate than "write a trie on my whiteboard or you're not smart enough to work here." None of their engineers are writing trees by hand and in fact are actively encouraged not to "reinvent the wheel."
I did a second phone interview at Amazon once. I have several years experience and understood the algorithm for the problem fine but got tripped up on the syntax a little. I was interviewing for a specific team and I could tell the interviewer was just looking for an excuse not to hire me. Perhaps I dodged a bullet in not getting on that team, but now I have to wait before I can apply anywhere else at Amazon.
The amount Amazon spends on airfare for these wasted trips must be staggering. I'm in Chicago and I don't know very many people who haven't gone on this strange pilgrimage to Seattle.
673 comments
[ 2.8 ms ] story [ 379 ms ] threadNot sure they actually do hire anyone straight to this kind of engineer levels though, I assume they'd give you the salary and responsibilities and make you earn the title through promotions?
They just need as many warm bodies as possible to ram through their test so that a few trickle out the bottom of the funnel to keep the ranks from shrinking. If too many started getting hired, they'd add competitive basket weaving to the skillset if that's what it took to balance it.
(1)http://news.nationalgeographic.com/news/special-features/201...
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 specific role. They have to fill that role. Having a generally smart person would be great but they have this immediate need and they can only hire one person. And once that req is filled, no more hiring until you get another req.
I'd love to see a company literally just looking to snap up smart people and then have them come in and kind of define their own role, one where they can add the most value. Nobody does this!
The only place hiring generic warm bodies at random state-U is Starbucks.
> I'd love to see a company literally just looking to snap up smart people and then have them come in and kind of define their own role, one where they can add the most value. Nobody does this!
At least with hiring out of college, a lot of companies do the "Let's snap up smart people, then train them to do the specific job we need done". In my experience, this has been particularly prevalent among the big consulting firms.
The recruiter may start out with a role that they are trying to fill, but they have plenty of other roles that they could be happy to put you in. And furthermore for the right candidate, they don't have to figure out the role up front.
When I was hired by Google, SRE poached me out of a pipeline to a different group. (Accepting that offer was a mistake on both sides, but it was a learning experience.) When I was hired by Amazon, I was contacted for a job in Seattle, then got hired in Orange County.
That said, plenty of candidates start the process by being too arrogant about what they can demand. Recruiters know to look for that and stop wasting their own time taking these people seriously. That's why pointing out that a proposed role is too junior for you is likely to result in being dropped.
> That said, plenty of candidates start the process by being too arrogant about what they can demand. Recruiters know to look for that and stop wasting their own time taking these people seriously.
Maybe, but I think it saves both sides time. If I'm shopping for a new sports car and a salesman approaches me with a great deal on a 10 year old pick-up truck, it's helpful for both of us if I make my expectations clear right away.
Most Recruiters: "I have this role you'll be great for! Let's see if it's a great match!"
Better Recruiter: "What are you looking for? I work with a lot of companies and probably have a great match!"
These things are generally a mess if you start out that way. Waste of time and money on both sides.
I am a programmer. I tend to dive into things in depth and context switching is unusually hard for me. A sysadmin needs to be able to operate on relatively limited knowledge and rapid context switching is par for the course. I was therefore a poor fit in that role.
After I left I was shocked at how many people I met who had known someone else whose story matched mine pretty closely. I would hope that Google has solved this organizational problem since. But rumor from those I know that are still there indicate that things have gotten worse over time, not better, so I don't think that it has.
However it was quite educational. I wish things had worked out differently but I definitely learned a lot that has served me well since.
You're looking for the sort of person that could setup a startup from the data center up. On top of that, they need to be good coders so they can automate everything, and also understand the applications running on the things they build. It's generally a much more in-the-trenches job - relying on limited information, and much harder to test things in isolation since there are so many moving parts, and things you can't change or automate easily (network vendor appliances, and so on).
I don't know about letting people "define their own role", but a lot of the biggest companies are constantly hiring without a specific role in mind. If you've got thousands of employees then your best strategy is just hire the smartest people you can find, and figure out how to use them effectively - you have enough roles available that you'll find something for anyone to do, and while not every role you need filled is someone's dream job, a combination of internal mobility between teams and great benefits and pay will attract a lot of good candidates.
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 and new challenges instead of saying "Well, the foo project is closing down and foo's pretty much what I wanted to do, so I guess I'm going to quit (and take all the knowledge and skills Google spent time and money to train me up on with me)."
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-advisable strategy, though, as the GGP I was responding to indicated. In fact, I'd argue that well-crafted teams of specialists are superior to, but harder to staff than, teams of generalists.
The big tech companies do also build well-crafted teams of specialists where appropriate (for instance, Google's Deep Mind team is all AI specialists). I don't know what sort of hiring process they use for those roles, but I would wager the process is a little more personalized, and also substantially more selective.
If you interview at Google and they ask how much you make you should probably tell them or you might get a weak non-negotiable offer. Unless what you make is already far less than their "standard offer."
It would be a shame to waste all that effort by sticking to negotiation techniques that maybe don't work on Google for regular candidates.
would you hire a plumber that refuses to name his rate, and then when pushed, tells you a number 5 times higher than normal? why do you think any other employment negotiation is any different?
if you "never name a number", the person on the other end is going to know you're inexperienced and operating on cargo cult mythology, and will simply take advantage of you.
http://www.kalzumeus.com/2012/01/23/salary-negotiation/ https://www.twilio.com/blog/2016/02/patrick-mckenzie-on-sala...
Definitely would be good if someone wrote a counter-response to this prevailing meme
The standard "don't name a number" advice is based on the assumption that most candidates don't have that. They know what they earn right now, but they don't know what they could be earning. In that situation, you want to sweat some information out of the recruiter by getting them to name the number.
There are other ways you can get a bit of edge.
In a previous round of job hunting, i let a recruiter persuade me to apply at Amazon, even though i was 85% sure i didn't want to work there. They made me an offer substantially higher than my salary at the time, because they're desperate to hire, because nobody wants to work there, because they're a shitshow. I could then take that offer to the other companies i applied to, where i actually did want to work, as a starting point in salary discussions.
In my most recent round, one recruiter said to me "Company X want to know how much you currently earn, because they can't offer above 130k for this position and they don't want to waste their time if you're on more than that". 130k may not sound like a lot to you over in the Valley, but it was getting on for twice what i was making at the time here in London. "Well,", i said in the most noncommital voice i could manage, "130k would probably be okay".
I gave express disinterest in doing that, and had no issue with providing salary expectations. But I made it clear that this behavior was completely unprofessional and unbefitting of a recruiter.
I then told them in no uncertain terms that as long as they have this policy on their books, do not call back. If however, they change this, I would consider them again.
Also the experience of being caught lying is emotionally and mentally draining for me so I stopped way way back. Like in childhood. I wouldn't say I'm completely fib free, but if you are even remotely entitled to the truth your going to get it. If I get caught lying I have to be OK with it and not care. That is a high bar.
This is a negotiation, they aren't entitled to know how much you make nor do they have a good method of checking up on it.
I have been through what you describe. A recruiter reaches out and tries to get you in their funnel. For me, it's a no-go because of my college background. (Unsexy school, shitty grades.)
A family member was pursued by them very aggressively after making some presentations at significant conferences and getting praise in a book written by a high level business exec.
This family member was received borderline harassing levels of outreach from recruiters from Google. It's pretty obvious there is some sort of targeted hunting list and KPIs associated with it.
> 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.
Take an afternoon and skim Cracking the Coding Interview before applying. There's no reason a competent engineer shouldn't be able to solve questions like that. You know exactly what's expected of you, show some initiative.
I think the core issue here is whether the prospective employee should have to show some initiative. My initial reaction is that of course they should, but when you're fielding job offers from numerous companies, some of which don't require you to go out of your way to pick up new knowledge specifically and only so that you can pass an interview, why not just dump Google and go somewhere else? A few years ago Google was probably the most desirable place anyone could work, I really don't think that's true any more.
Overall, it sounds like the system is working. Developers that don't much care for Google's methods won't go and work at Google. Those that are very passionate about working at Google for the sake of working at Google will jump through those hoops.
I'm with him up until "never be interested...", thats a piss poor attitude. I've never needed to know big-o complexities for work, and I've only scraped the surface of needing/using various data structures, so I get annoyed at some of the heap/tree trivia questions as well. But if I were in a situation at work where I needed a tree, of course I'd stop coding and read up on how binary trees work and use them for my benefit.
I think the process selects well for new grads who have recently completed algorithm courses.
I think the process selects well for people who are comfortable with doing work on a whiteboard.
I think the process selects well for people who are motivated enough to work at Google that they read and study books like you mentioned for weeks, and do a bunch of practice self-study interviews before coming.
Whether that set of people overlaps significantly with what makes a company do well -- I don't know. I'm not sure.
But I am pretty sure that the reverse assumption, that people who don't pass those bars are not good canddates, is an arrogant position that only a company of Google's standing and size can/should get away with.
What I don't get is the trend of small companies, startups, and the like, copying this interview process. It is entirely not a match nor a way to find the kind of motivated, culture-fitting, creative people you need in a smaller company.
If I am not mistaken, you can choose to do the exercises on a Chromebook in an IDE instead of the whiteboard, so there's that.
First, I know this isn't a black or white issue but the problem I have with this is that I'm wondering if they are hiring people with the skills they want or are they hiring people with the skill to succeed in their test.
In theory, they should be the same. In practice... I don't know.
I'm not really selecting for people who are really, really good with binary tries -- I'm selecting for people who display those qualities, the question is pretty much incidental.
But maybe I'm just not very smart?
My recent experience with AMZN was:
- get contacted by recruiter, schedule a call with recruiter a few days later
- take a take-home coding test a few days later
- talk to the recruiter again a few days later to tell me I did well on the coding test
- talk to another recruiter a few days after that, get scheduled for an all-day in person interview 4 weeks in the future
- cram cracking the coding interview for 4 weeks
- go to the interview all day, hear at the interview that I was close but didn't pass, they recommend I should try again in 6 months.
All in all thats a pretty big time & mindshare investment
Meh. Being a developer is being a developer. Not to say that certain specific companies don't sometimes have specific challenges or perks that would be of unique interest to somebody, but by and large, there's no real reason to think if Google/Facebook/Amazon/$anybody_else as a "dream job."
I used to think that way, and after working at two of my "dream job" companies, I've realized that it's pretty never what it's cracked up to be.
Really, the world is SO much bigger than just GoogBookHooSoftCart... I'd encourage people to NOT put those companies on any kind of pedestal.
This is assuming that smart leadership equals no deathmarches. Deathmarches are for the young and gullible.
So I counter your advice by saying the best opportunity for a young engineer is likely a large company that is well-known for having generally smart people. At least I learned what I wanted and didn't in the rest of my career.
From my own experience I interviewed with a small company right out of school where I would have been the second or third developer (I forget now). One reason I did not pursue it is that I seemed to know more about development best practices than their existing developers; for example they did not use source control at all. While I would have had the opportunity to make a big impact on the product, I don't believe I would have grown much.
There isn't really a "once in a lifetime" email from a recruiter. Once you interviewed with them you'll have plenty of opportunities to interview again.
I LOLed over the phone, it was a riot.
EDIT: On the other extreme hand, it's a HUGE turn-off when a recruiter makes an incorrect assumption about my time availability in the initial contact. Stop me when you've seen this one: "Your background looks great! Please tell me what time slots today would work for you in order to discuss this role." Wow, really? You're assuming I have time to call you RIGHT NOW?
Story time: At <X>, I knew after the culture fit round that I wasn't getting an offer. I had middling coding rounds and a terrible culture fit round with the hiring manager. The recruiter claimed that it was close and the team was arguing about the hire, while the person that referred me let me know that they were passing because the hiring manager vetoed everyone with a 'no hire' about 2 hours after I left their building. I had no qualms with the reject, I truly felt a misfit in the interview, but the recruiter play was funny. Someone reached out to me 4.5 months later asking if I wanted to interview :)
Interview process: complete success.
This phrase precedes the one you mentioned. He's saying the process he has been through completely ignored his background and field.
OP says that his field is object-oriented design, which links to a page where he announces that "We've started work on a new programming language". The idea that a computer scientist/software engineer would embark on building a new programming language but also state that they don't know how to solve tree traversal problems and "will never be interested in learning them" seems strangely incongruous, given that building a language almost certainly involves working with ASTs.
Specifically, OP pushed a commit in late 2016 that contains code working with stacks, linked lists, and an AST class for the EO language.
https://github.com/yegor256/eo/commit/6df2281d8b0163b9f9e1b8...
I guess I just don't believe that interview questions about trees are ignoring the author's background and field.
Hiring a junior with such criteria might make sense; hiring a more seasoned person, probably not so much. Because the seasoned person will just not be as compelling as the more junior person, due to having spent the past few years working on other things.
There is one thing I want to point out though. Before starting my algorithms course I knew how to solve problems recursively. I had done project euler tasks and what not. I just never knew the words abstract syntax tree or binary search tree. I could guess what they were prior to the course but I didn't know what they were off the top of my head.
Do you think that it's possible that a self taught engineer would know how to solve these problems given time and enough questions to the interviewer? Maybe get frustrated with "How do you balance a search tree?" questions under pressure?
It's very easy for new interviewers to come up with problems that are easy for them (because they know the subject), but very difficult for the interviewee. Avoiding that is a priority for me, but I still strive to evaluate how the candidate approaches problems.
My strategy is to keep my questions as close to first-principles as possible, making the problem more about programming approach than algorithmic recollection. I had a Google interview once where they asked me to implement pivot tables, and I had to sheepishly ask: "What's a pivot table?" That set me back somewhat, and I try to avoid that in my own questions.
Most people can work with Vectors/DynamicArrays, linked lists etc. but they don't know how to implement one or even how it works in detail under the hood.
In response to not knowing the speed of sound as included in the Edison Test, Albert Einstein replied:
"[I do not] carry such information in my mind since it is readily available in books. ...The value of a college education is not the learning of many facts but the training of the mind to think."
This is even more true today with the vast trove of easily searchable called the Internet. A competent programmer should have high-level knowledge of different algorithm types, but should not strive to memorize their implementation (e.g. for interviews), since it is trivial to look that up.
And aside from that, let's face it, none of us here are Einsteins.
Same thing with algorithms like tree traversal. You should know the theory behind them, but unless you regularly implement them, there is zero reason to commit their implementation to memory to the extent that you can casually write them on the white board during an interview.
>>And aside from that, let's face it, none of us here are Einsteins.
Even more reason to not try to memorize something unless you use it constantly.
You mix two completely irrelevant things: education and experience.
You will be taught binary trees in CS, but not every programmer is studying that.
If you learn binary trees in CS, you will forget it after few years of experience, because skills that are not used are forgotten.
So yeah, Amazon/Googles of the world are looking mostly at recent CS graduates (most of the set of programmers that know many algos) and the very small set of programmers that deal with algos every day.
I know several people that did, taking several months off to prepare (and got in), and yes, you have to re-learn all the CS algorithms which will probably be irrelevant again after you pass the interview.
It would have been different if he was asked questions that only algorithms experts could answer, but really these are really basic questions.
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.)
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.
In your day-to-day you have wikipedia, stackoverflow, hn and so on: software development hasn't qualitatively changed in the past decades to require multi-day interviews when 15 years ago a single 30-45 min interview was more than enough.
It would actually be interesting to compare the length of, say, a google interview a year after company inception compared to now. I am sure that despite the fact that nowadays the impact of a bad hire would be minuscule compared to back then, the interview process is way, way, way longer and more difficult.
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.
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 can watch them implement one.
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.
this is also what is annoying me, the thought of so much ink being devoted to O complexity and so on when with modern processors in the end often "less optimal" algorithms are a lot faster based on how they work and often you end up writing the same thing 3 different ways so you can test and see which one is actually fastest given your language/compiler/toolchain/processor
In a book-level discussion whether a comparison in your algorithms evals to true or false in a predictable or unpredictable pattern doesn't make a difference in its performance, however write that out in code and the branch predictor of your CPU will be a LOT happier (and faster) if you make it so that all the "false" and "true" comparisons happen in streaks as opposed to randomly...
When they passed on me after my Google interview, the HR person actually told me "You can try again in 18 months. There are quite a few people who study for it during those 18 months and get it the next time!"
Yeah, I don't want to study for 18 months to get a job at Google, sorry.
I have a friend who was interviewed at Google, rejected, then interviewed again a year later, rejected again, and then a year later a Google recruiter got in touch to see if they'd like another interview. They said it started to feel like a cruel joke.
I might eventually try going through the gauntlet again, but I wasn't quite willing to move to the west coast during that time (new relationship, new home, new puppy, work was going well, I didn't really need more big life changes at that point).
I'm starting to consider a job change but I'm still not sure I want to move to the west coast. I'd probably have to downshift my home quite a bit out there.
To clarify, it seems to me the interviews tend to focus on things like "what's a good data structure for the social network in a Facebook clone?" but that's only 1% of the actual job, 5% tops.
It's true that those technical design decisions are very important, but they're not decisions that every engineer needs to make on their own on a day-to-day basis. They come up fairly rarely in a typical project and usually multiple people will be involved.
I don't have any easy answers -- I don't know a good way to interview for the other 95%+ of useful skills, like communicating well within a team, testing, debugging, benchmarking, writing documentation, good source control practice, knowledge of standard tools, meta-knowledge of how to learn about standard tools, how to evaluate new tools, system administration, dealing with production panics, etc.
I think some of this was why some time ago there was a way of interviews with "off the wall" questions, but those seemed to be fairly vilified so I guess that's why they aren't as common now, but personally I would get more of an understanding in how somebody thinks by giving them an unexpected question than by asking them something they could've studied for.
In fact, I would argue that one could know how to write one and have no idea of the practical use of it.
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 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?
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.
I you need to write so performance critical code that the choice of tree structures matters then this interview question sure as hell isn't going to find out if you are cut out for it.
1. https://en.wikipedia.org/wiki/Attribute_substitution
This is what confuses me. I tend to take the problems I get during an interview as representative of the work I would be doing, and then get turned off by the job immediately.
At least at the PhD level, you'd expect that the job would be using more of my unique expertise, I'm not a BST expert (though I can write one when I need to, it definitely isn't "warm" in my brain).
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.
I wrote millions and millions of lines of code in my 30 years career, I was once a top shot mac developer, and I was once a top shot computer geometry expert, and an OpenGL expert and all of that, and I've forgotten most of it... If someone asked me a trick question, I'd look like a fool.
Simply because I don't need it. My strength over all these years is my capacity at learning stuff quickly, and that doesn't come up in a trick-question interview.
So for these data structures questions: In 30 years I once had to implement a binary tree for any sort of problem I had in my job. Now it's not the same for hashes, lists, queues and many others, but trees? Quite frankly it's a CS toy. You know it's on the shelf in case it's needed, but it very rarely get a dusting.
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 persistent recruiter emailing me over and over and over again to apply, despite my knowing there was zero chance I'd be a fit for the job they asked me to apply to.
And more generally: I don't really care about binary trees. They're simply not relevant to the work I do. I suppose if someday the only way I can get a job is to buy a book with all the stock interview questions in it and memorize the answers, then that's what I'll do. But if somebody's hiring me, I want them to hire me for the things I know that aren't standard interview questions anyone can memorize.
The way I try to phrase this to people who don't get it is: my metaphorical working set in memory does not include basic algorithms (that's what libraries are for), and does not include brainteasers or riddles. It does include a lot of arcana about how web application stacks work, the network and gateway protocols they use, the points where security and reliability issues are most likely to happen and how to avoid those issues, the application and database architecture patterns most often needed, available libraries and frameworks which implement them, pros and cons of different approaches, etc., etc. I could, if so inclined, probably take the metaphor all the way and outline which things are in the equivalent of CPU cache vs. the equivalent of main memory.
So sure, I could page all that out to disk and forcibly cram a binary-tree answer into my brain's L1 or L2 cache, or load up one of the dynamic-programming questions Google loves (tip if you want to work for Google: memorize the Wikipedia article on longest common subsequence, even if it will never ever be relevant to anything you'll ever do, because they will have you do it in an interview). But that would be actively harming my own usefulness, and I'm not willing to do that for Google or for anyone else.
Which I guess raises the question: why do you apparently want me to harm my own usefulness just to try to get a status-symbol passing grade on a Google interview?
I'm not arguing that Google doesn't have a huge scale, but I'm pretty sure that Microsoft, Facebook, Amazon and most likely the NSA also have unique systems and challenges.
And all of them (well maybe not the NSA not sure on that one) do the entire "algorithms quiz".
They have this reputation because, it turns out, not every engineer at the company needs to be able to rebuild all of Google from first principles in order for it to keep running. And even at Google scale there's not enough interesting greenfield work to do to, or de novo problems to solve, to keep all those "famous engineers" busy all the time. The same is true at most companies -- you need a mix of talents and skillsets, and you need to match up people to roles based on that. The Google approach -- of putting people into drudge work and paying them enough to hope they won't quit -- is a grossly inefficient use of talent and knowledge. Which is another reason I wouldn't want to work there!
What distinction are you making between "expertise", "knowledge", and "outside experiences?" The outside experiences are the basis of the expertise and knowledge. If you understood, used, and contributed to other existing build systems, you are then in a good position to understand, use, and contribute to Google's in-house build system, because you have useful knowledge about the problem domain of building software. And so on.
This was my second phone screen at Google, for what it's worth.
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 completely open ended question.
I don't work at google so I won't speak to their daily work, but very rarely should you be writing your own binary tree or traversal code. If you should find yourself on that task you hopefully won't be doing it from memory / without reference because unless that is the ONE thing you know like the back of your hand, even then you are likely going to make mistakes.
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. There has only been a few times that I have actually needed to implement any of these algorithms in the last 10 years. Of those they were very low level and implemented in a kernel driver where libraries are not so abundant. Can I remember all the fine details today? No. Did I make a system that runs on hundreds of thousands of linux systems across the world? Yes. If I were interviewed on the fine details of implementing some of these algorithms and data structures would I pass? Not likely. Does this make me a bad programmer? Depends who you ask. If you ask the guy interviewing me Yes. If you ask my boss and the many customers who use my product No.
Memorizing algorithms does not make you a good programmer. Knowing how to apply and when to apply them does. The hard part was done when the algorithm was created, not regurgitating an implementation.
Now you might say hey, they should at least know binary tree! Sure maybe they should have some knowledge of it, but there will always be some algorithm you don't know. I would feel completely different if Google said "Come ready to talk about these 5 algorithms and maybe implement one or two". That falls inline fairly well with the author of the article. At least then somebody can say, "Hey, I don't have time", or "Sorry, not interested". And both sides can have their expectations insync.
Now don't get me wrong. We are talking about Google and Amazon. So yeah, somebody there might need to know something about these algorithms. But I doubt they all do. The Few interviews I have been on at these organizations I was not even convinced that all the people interviewing me would be able to pass the round of 5 had they interviewed each other. I should note not all the people who interviewed me gave me that impression. I did meet some really nice people that I thought I would enjoy working with.
I also don't think that these companies don't take into account that some people just interview badly. There is a lot of stress involved. While I think people should be able to work unders stress, I think the type of stress these interviews cause is something entirely different. I live a fairly stress free and carefree life. But when I went to interview at Google my stress levels were so high that I felt sick and worn out for days after. What I am getting at is I am presented with hard problems and short deadlines daily at work. Not once did any of those challenges cause me any level of stress. On the other hand trying to figure out what the interviewer really was asking and cramming to memorize algorithms caused so much stress I did not sleep for days days before the interview. It's not that I was up studying, its that my mind was racing and I could not sleep if I wanted. I just lied there in bed staring at the ceiling. I think they call that anxiety.
> Interview process: complete success.
It was a failure because they wasted everybody's time. Had they been more upfront on what they were looking for then he coul...
Very good point. The amount of memorization involved in the process is excessive. It'd be helpful if each candidate was told what subset of all possible problems they should focus on.
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.
Implementing a delete on a binary search tree or traversing one has nothing to do with analyzing performance. If you want to ask questions that require recursion don't make them dependent on algorithms that require rote memorization. Or at least have a alternative recursion question if the candidate says - "Sorry, I don't remember all the rules for this algorithm". Or even be ready as a interviewer to go over how said algorithm works and see if the candidate picks up quickly. If you wanted to really talk about performance then you can talk about WHEN to use a given algorithm and WHY. You don't want to ask questions that there literally is ONE (maybe two) answer that are correct. You don't want to ask questions that when asked WHY the answer "is because that is how the algorithm dictates it." You want to ask questions that are open for interpretation that you then can ask the candidate why they chose that solution. This gives you much more information.
> 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.
Let's not conflate algorithm implementation from rote memory with not wanting to answer any technical questions. You can't just come in and start talking about ACID transactions and concurrency as if that is what people have been objecting to. Those are valid topics and I doubt most people would have any qualms talking about them. As those are concepts, not rote memorization. You have to have a good understanding of the problems to know where the pitfalls are and know how to spot them. Implementing a algorithm rally covers higher level concepts other than simply regurgitating something like "traverse the left subtree of the root node, accessing the node itself, then recursively traverse the right subtree of the node ....".
I think what most people are suggesting is that there is too high of a penalty on not being exposed to a given algorithm. It is not that these people incapable understanding the algorithm or even implementing one. They simply don't remember. I think this is because a large number of people working at google are fresh out of school. They literally have no experience other than the rote memory required to pass their classes (yes, I simplified that a bit).
I will say that I did find a correlation to the age of the interviewer and the type of question asked. The older 30+ and 50+ guys that interviewed me asked practical questions not related to a specific algorithm. The youngest interviewer I had was a complete hothead and started out the interview saying "he was not your normal interviewer so he was going to ask the hard questions" Then proceeded to ask me a rote memory question about a algorithm. Either I had knew it and memorize it or not. That is not a hard question. The hard question have nothing to do with a defined algorithm. They are often open ended and leave lots of rope for you to hang yourself.
Yes, surely! Have the algorithm explained, or even diagrammed for them with pseudocode.
Let's not conflate algorithm implementation from rote memory with not wanting to answer any technical questions. You can't just come in and start talking about ACID transactions and concurrency as if that is what people have been objecting to.
Let's not conflate the need for a good background with rote memory. I object to rote memory being rewarded by interview questions. I also object to programmers who maintain they don't need to know any of this stuff at all, because they can just Google it and spend a few seconds reading the Wikipedia article. Where in the Dickens did you get the idea I'm Captain Rote-man?
One purpose of training in a highly skilled field is to teach people how to avoid the egregious gotchas. Go ahead and read my other comments in this thread and on this site. I'm not the all conquering champion of rote memorization you seem to think I am.
If I read them in a different mindset then i can take them as a complement to what I said. That knowing how to analyze application performance and concepts like recursion are more important than rote memory. And that interviews should focus on things that can't be ""look up" then read a one paragraph blurb for 3 seconds". I can fully agree to that.
Once again, I am sorry I misread your reply and dumped a wall of text on you.
http://v.cx/2010/04/feynman-brazil-education
I get that things can be fluid, but its such a meat machine.
And if you write out the answer in silence, be prepared for a "tell me how it works" follow-up.
No, jesus. Some people need to switch to a presentation mindset and out of a problem-solving mindset. This is completely normal in life.
I'm starting to think most interviewers are terrible only for not having a decent amount of social interaction with strangers. Let's just admit it's 90% hazing ritual at this point so we can get on with putting up guides to get through it.
https://en.wikipedia.org/wiki/Tripos#Etymology
Of course, if we had this in swe land, it would probably end up looking a lot like those silly certificate programs in soon-to-be-obsolete tech of yesteryear...
> soon-to-be-obsolete tech of yesteryear
Not if it focuses on things like basic algos, and understanding basic data structure.
Then it would be timeless.
And if that makes employers more confident in my abilities, then I will gladly do that.
Because it's a lot easier to study for a standard test than a bunch of different tech interview scenarios.
Cracking the coding interview is damn near encyclopedic and many interview question you are asked that have a "trick" to them will probably have something you can adapt from the book. You go in knowing most of the tricks and it's a huge edge.
It's a dishonest approach and the response laid out in the article works just fine to weed out shady recruiters doing this.
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 would prefer to drop out and not waste time for anyone involved. I was very happy to say that multiple times - I know what I don't know. The interviewer goaded me into taking the challenge anyway, saying I'll "definitely be fine and pass."
The next day I attend the timed coding challenge. Three algorithm puzzles that are in no way insignificant. I had Google at my disposal and still could not solve a single problem - although I came close on one involving permutations of chess pieces.
Unreal. At least Yegor had the good fortune of not being directly lied to by the recruiters!
One of the skills they're looking for is adaptability/flexibility, to offset the terrible resource planning.
The message I really get from this post is that they'd be happier in a more structured, predictable environment, and there are plenty of places like that, old+new, small+large.
By having the future direct manager involved early, they can hopefully say "I need a algorithm person, not an OOP person. Go talk to Carla, she's been looking for someone like this" sooner.
I don't like algorithm questions either but at least they optimize by time, the alternative is to have people in for a few days, or spend a day doing chat interviews and risk getting a bullshitter.
While, yes, it often takes interview more than one, and often several people, to find a desirable candidate — it's not that high. Given that any candidate will see probably around 4 interviewers, I don't think asking that the manager interview is that big a deal. I have to agree with that part of the article (though I disagree with it on the whole): meeting your manager-to-be is important. (And I don't think one understands this until one has a bad manager.)
In a prior job, we would also omit the manager interview if it was certain the candidate wasn't going to be a pass.
I guess they just want software engineers as workforce. They don't really care about what you want and your skills, if you are very good at something you will probably be good at something else.
For a company the size of Google, with the amount of applicants they receive, I would assume that an interview standard is absolutely necessary. It's not perfect, but for 95% of developers out there you know EXACTLY what you're going to get when you interview Google. I think there is something to be said about that. Google recruiters tell you what the interview will be like, they give you study materials, and are pretty gracious with scheduling. If you don't like the process, that's fine, but I think Google in particular has done a good job of standardizing their process. It may not work for individual cases, but I would assume it works well for the company.
Pure Algo (which I view as "let's see that your CS grades were earned and not bought")
Pure Coding (let's see if you have a reasonable coding style and design and are proficient with at least one language)
Algo & Coding (a bit of both that makes sure you can solve a simple problem and code it [i.e. work entirely through a problem])
Software Design (so more on your skill in designing code - finding the right abstractions and interfaces etc.)
Systems Design (your ability to design complete, large scale systems at a very high level)
And this is more or less what I got, which seemed fair and logical to me. I agree that it is not tailored to the interviewee's individual skills (for example, your special training in cyber security is unlikely to give you an extra edge), but it makes sense for "good overall software engineer", and if you aren't also a good overall software engineer in addition to your special training in cyber security, then you are probably not what Google is trying to find. Also, it does look at your skills in coding and design which are both non-algorithmic.
Now whether or not this experience is shared with other interviewees, or matches what you are looking for is something else :X
I work at Google and do interviews (though I don't enjoy them). We do ask questions around domain expertise, software design, etc. It's not all just coding and algorithms.
A good question:
1. Has a low enough floor that a poor candidate can still make some progress and not feel like they are doing poorly and get stressed out.
2. Has a high enough ceiling that a strong candidate doesn't blow through it in five minutes.
3. Has a smooth ramp between those points.
4. Doesn't rely on too much domain-specific knowledge so that a candidate who happens to have a random gap in their background that leaves them totally hosed.
5. Is concrete enough that the interviewer can capture that feedback in a way that the hiring committee can easily understand.
6. Isn't well-known outside of Google as stock interview question so that candidates can game us by just learning the answer.
7. Isn't asked by any of the other interviewers the candidates sees.
8. Can be explained and worked through in about twenty minutes.
In case it isn't obvious, it is really really hard to find good questions that pass that gauntlet. Questions do tend to skew towards smaller-scale algorithm coding questions because I think those tend to survive that gauntlet better than most other questions.
Interviewers are trained to not ask "puzzle" or "trick" questions. Not only are trick questions a shitty experience for the candidate, they are a shitty experience for the interviewer too. My job in an interview is to get as much data as I can about a candidate in order to provide information to the hiring committee. If I ask you a trick question, I get about one bit—in the binary sense—of data from you: did you find the trick or not?I don't think you have to be unusually good at algorithms. I basically read some Wikipedia articles and spent a few hours in the hotel cramming Algorithms in a Nutshell, and I managed to squeak through.
That time was incredibly well-spent. Since then, I have relied on that algorithm knowledge way more than I expected too, and have since spent more time learning algorithms and data structures because I can clearly see it's made me a better programmer.
That part is hard. We allow candidates to use a laptop too, if they prefer, or both. My experience is that candidates who use the whiteboard, at least for the earlier "design" parts of the question tend to do better than the ones that go straight to typing.We need to learn how you think, and putting a screen in front of people tends to make them clam up. If all I see is the code you write and you don't explain your thinking behind it, I don't get much data.
That part is really hard too. The reality is that interviewers and candidates have a limited amount of time they can put into this process. Keep in mind that most candidates are currently employed and don't want their job to know they are interviewing. Many of them travel to interview. There are only so many hours.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 rare breed I was at Google until after I got hired. (I came from the game industry where college degrees weren't as important.) There are so many over-achievers here, that I think many Googlers have never even considered that someone may not have gone to one of the top ten CS schools in the US. Especially in Mountain View, literally everyone they know probably has.
It's a weird bubble.
So you imply they're doing a bubble sort on candidates?
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 the knowledge from memory is not necessarily a bad developer
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.
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.
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 comes from misunderstanding, rationalization, or what, but in my experience at least, neither do most of my coworkers.
That is, I at least don't recall a rote algorithm when interviewing In fact in one of my interviews (not at google, but I could see a similar question happening there) I had to derive a solution to a problem in a space I was totally unfamiliar with (locking and multithreading).
It seems like, if you assume (incorrectly) that somehow you can't cheat the system, Google is selecting for people who can solve unfamiliar, complex, problems by applying first principles. That is, I think, orthogonal to the idea of 'theoretical or practical' computer scientist.
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?
So, I think my biggest issue with your A/B dichotomy is that I don't see it. That is, in school, in myself, in coworkers, there isn't this large group of people who are trying to do all the theory at the expense of practicality, as opposed to this group of stuff-accomplishers who aren't theoreticians.
I mean, occasionally those people exist, both the "fuck it I'm going to sit down and type until it works" people and the "I must understand this concept before I write a single line of code" people. But as you say, everybody is a mix of both, and I think most people are nearer the middle than the sides, which makes the possibility of mild bias towards one side or the other a lot less harmful than you maybe expect.
Here's an example of what I mean: Google is a company with incredible tech and quite a lot of money, but its products tend to fall into clear patterns. First, create something awesome, then fail to support it, then fail to monetize it, and eventually, it fall to the wayside and is discontinued. There are so many apps Google has created that fit this mold that people have done meta-analyses on how long the average Google product lasts.[2] Obviously, not all Google's products fit this mold - but I think Google is unique in being able to support this pattern, fiscally and from a development fatigue standpoint.
This pattern is exactly what I would expect to find at a company that is mostly based around theory and concept, and that is either inexperienced at or disinterested in support work after the initial execution.
[1] https://www.quora.com/What-are-the-disadvantages-of-working-... [2] https://www.theguardian.com/technology/2013/mar/22/google-ke...
It's probably true that most people, even at Google, are somewhere in the mid-range. However, a large enough group of people with a small bias will result in a shift in the policy of an organization. I still think it's fair to say that, if my dichotomy exists, it would effect Google's institutional behavior even if the degree of difference between people is low on average. That is to say that while you may not see it, it also may not be obviously or even at all visible from the level of one person in one part of the organization, whereas its effects are visible from both within and without. It's kinda like dark matter - you don't know what's happening in someone's head, so you can't observe it directly, but you can predict outcomes based on hypotheses and see what comes true.
For things like moonshots/other bets, the "build something awesome but don't monetize it" makes a lot of sense, since the entire point of that division seems to be "build something awesome and see if it is sustainable too". More often than not, unfortunately, the answer is no.
In fact, if anything, I'd reverse the cause and effect in your idea. If we presuppose that there is this dichotomy in people and it affect google's motives and goals as a company, then this would influence the tech hiring practices to be the way they are, not vice versa.
I'm confused as to why you doubt that. Google's been around for almost 20 years. Their interviewing process has been around since at least 2003.[1] It's 100% possible that somebody was hired, ended up in higher management, and graduated to making driving decisions (at least over a particular area) in that time, unless your suggestion is that nobody who enters as a new grad ever stays long enough to get to that level, which at Google (vs other SV companies) seems unlikely.
[1] http://jeremy.zawodny.com/blog/archives/000616.html
> For things like moonshots/other bets, the "build something awesome but don't monetize it" makes a lot of sense, since the entire point of that division seems to be "build something awesome and see if it is sustainable too". More often than not, unfortunately, the answer is no.
It does make sense, it's more the messaging around those kinds of projects that tends to get lost. You end up in situations where thousands or sometimes millions of users are relying on a "beta" product, which has no monetization strategy, and then gets scrapped. It's a pattern that's still unpleasant for end users and not great for Google's reputation.
> If we presuppose that there is this dichotomy in people and it affect google's motives and goals as a company, then this would influence the tech hiring practices to be the way they are, not vice versa.
That's a great point, and likely, assuming of course that Google started this way (I think it likely did, given its founders' backgrounds). It creates a self-perpetuating cycle, though, which still ends up being problematic.
Either a lie or you are unusually good at algorithms. People work > 50 hours on Leetcode, CTCI, etc. to try and get a job at Big 4. A couple of hours just reading Wikipedia articles isn't even close to the amount of effort people put into 'gaming' the system these days.
That was the only prep I did for the interview. I was a senior software engineer at EA at the time, with about a decade of professional software experience.
I don't have much of an academic background, but I had written and shipped quite a lot of code by that point in time.
The cramming did help—several of the algorithms I read about were either new to me or I hadn't seen in ages—and some of them did come up on the interview. (I've also used almost everyone of them at my work at Google since, strangely enough.)
My point was just, if you are already a good enough engineer to be successful at Google but don't "interview well" because of whiteboard experience or algorithms it's pretty easy to shore up those two things. You don't need to spend a decade at a monastery meditating on Knuth.
If you're a decent coder, you've already done way harder things. Breaking down a big messy problem into pieces you can code and test is hard. Shipping applications is hard. Breadth-first search is not hard.
Then you must be much smarter than the average Silicon Valley software engineer. Congrats on being born that smart. You should thank your parents.
I've interviewed at Google and the interview experience was sufficient to convince me that I'm not a culture fit. Maybe that was the point. I tend to thrive in work environments where my "soft skills" matter more. Seems like that's not even on the radar at Google.
By "pressure cooker", to you mean in terms of time, or more social intensity? There's not too much Google can do about time. Like I said, it's not fair to ask candidates to dump weeks of their life into the hiring process.
If it's about the social intensity, I agree, that's hard. Many programmers are introverted and being "on" for an interview is really really difficult. It's one of the reasons I don't like doing interviews—it's hard for me on the other end too.
We are trained to try to make it as relaxing and pleasant of an experience as we can, but there's only so much we can do. The reality is you're in a 1-1 conversion with someone with a fixed time bound and where your performance may alter the trajectory of your life.
That is a stressful experience, no two ways about it.
I'm planning on interviewing with Google in a few months just because of all the great things I've heard about their infrastructure and engineering culture, but due to these concerns I've budgeted to use my current vacation time just to get back into prepping the way I did when training for ICPC just so that I'll have confidence knowing that most interviewers probably have never studied algorithms at that level and that I'll have more confidence in not being potentially tripped up by these types of interviewers.
Most of my friends, even those at Google, have tried to convince me that this plan is overkill but I just can't get myself to leave the fate of my future into the hands of some random interviewer and then regret not doing this level of preparation if I get rejected...
"I won't accept an interview at Google because: 1. I had a bad interview at Amazon (???) 2. I read a story on HN about someone having a bad interview at Google
I'm sorry but that's an awful excuse. As you mention, Google works at an insane scale, and as foolproof as you try to make a process, there will always be a very small chance that it'll fail. Doesn't mean the whole process is bad.
And there's the whole bias that you'll only hear from horror stories and never from success stories.
You cannot claim that someone "literally" says something then make up a fictionalised quote that mischaracterized what they're saying.
None of that "quote" appears in the article. Therefore the term literally and the quotation marks are at best misleading.
Not to mention lotto isn't quite the tremendous time-suck that playing the Google interview game is (I mean, sometimes you get stuck waiting in line behind the old lady buying $500 worth of scratch tickets so you can buy your one powerball ticket, but still...)
I do also believe in the interviewer anti-loop (see Steve Yegge's blog[1]), but I also think that it doesn't really matter unless you really want to work for a specific one of these large tech companies.
I currently work at Microsoft and just finished interviewing with a couple of the other large tech companies and have pending offers from them. I don't know, maybe I am smart, but when I see people like Andrei Alexandrescu or Mark Russinovich speak, or watch a video of Grace Hopper explain how she demo'd nanoseconds to military generals, I feel like an idiot compared to those people. I personally think you obviously have to have problem solving skills, but also gumption and a can-do attitude goes a long way.
[1] http://steve-yegge.blogspot.com/2008/03/get-that-job-at-goog...
1) Found your own company to do a specific thing 2) Prove out you can do the thing and do it well, and furthermore have the thing be valuable enough that it would be worth acquiring but not valuable enough that it can operate as an independent company that covers its own costs 3) Google decides that what you're doing needs to be part of their portfolio and they buy your company and staff.
I have yet to hear back either.
At this point it feels the interview process is becoming more of a combo between a hazing ritual and a lottery than something actually useful to ascertain if the person interviewed would be a good match for the position or not.
The longer the interview is, also, the more likely one will be discarded because one of the many interviewers is having a bad day, or because after several hours of whiteboarding one can understandably draw a blank on a simple question they would've waltzed through 4 hours prior and be failed because of that. How long before interviews also contain an anti-doping panel to weed out candidates trying to improve their odds?
It is strange though that in a country where there is at-will employment one is basically told that hiring the "wrong person" could destroy the company or something and so the interviewer has to make really really really really sure that the candidate is absolutely ok.
I personally think the risk of hiring somebody and they can't cut it after three months and you have to let them go, is worth not passing the candidate that doesn't do well at whiteboarding but will instead prove to be great when tasked with real business problems that take more than a few minutes to solve.
Why? As a matter of fact, I have a friend who met a manager at Burning Man, then was hired into Google in just such a manner. He described the Google interviewing process as "a breeze!" My reaction: What!?
What it does is destroy the recruiters reputation and KPI charts.
It's amazing how often "Hey, thanks for reaching out, I'm interested. Can you tell me more about the role?" results in the conversation ending right away. Probably over 50% recruiters that contact me do not reply back after that very polite and neutral response.
Many who do keep the conversation going have not read my profile or resume carefully, so I'll give them a summary of the types of work I'm actually interested in, which is never what they contact me for, and politely decline to move forward with the (usually way too junior) role they are looking to fill. That will almost always end the engagement.
Sure, it's a lot of noise, but filtering is very cheap: the time it takes to reply back. My actual success rate with recruiters probably pretty average. Of the eight or so jobs I've had in my ~20 year career, about three were obtained through recruiters, two times through in-house staff, once through an external recruiter.
To paraphrase you, there's always that remote chance that one of the Nigerian Princes could actually need your help.
I used to do a similar thing to you, but it's too much work now and the levels of job spam ("Oil pipeline engineer" roles, simply because my CV has the word engineer in it (prefixed with Software)... lazy recruiter, that's bad!). Basically, if they can't make the effort, why should I? I guess the answer is, "Because there's always that remote chance that one of them could be able to set me up with a "dream job""..
Think about it like the real estate market (in normal markets, not Silicon Valley). Some houses sell before they even hit the market. A few also sell after the realtor does a few private showings. The rest are the "dog properties" that go on the MLS and need heavy marketing to sell.
That's... a strange way to look at the housing market. The norm is to list your property and then see what bids you get. Putting your house on the market is not some weird trick to pass a crappy house on to a bunch of rubes, or am I misunderstanding you?
Like, how do you reliably find a willing buyer pre-listing, and how do you know that's a good price (other than just blindly trusting your agent), if you don't even bother listing it? Listing is as much about price discovery as it is about finding more buyers.
The hotter the market, the more realtors know buyers willing to pay a lot for the first home that meets all their needs. Hence more homes are sold before listed.
I think that's locale specific. Except in the 15million+ bracket, auctions (here in Melbourne at least) tend to get the best money for the seller.
If the quality that companies were getting from regular applications was better than the quality they get from their recruiters why would companies pay to have recruiters?
If there's an awesome job available out there, with way above average pay, benefits, great opportunities for advancement, good work/life balance, etc., you'll fill it with a top talent. You're not going to need a recruiter. Word will get around even to people who are not actively looking, trust me. Similarly, if you have an "average pay for an average worker" kind of job, you'll find that average worker.
When you have a ho-hum average job but you want top talent, then you're going to need that recruiter because the job needs to be actively sold.
I invite anyone who works at a company that pays 3X average salaries or is well known for being an unbelievably great place to work to reply and tell me they have trouble hiring.
They could definitely fill their need for new software engineers naturally, but presumably have data that the quality of candidates they get by bothering a substantial fraction of the world's software engineers on ~a yearly basis gets them better applicants and engineers.
Why do you think so? Just because you receive X resumes doesn't mean they're all qualified to work there.
Above average people are usually treated well in theirs jobs. If you want to hire them you need to actively approach and lure into applying. Even then, they will not bother to refresh algorithms questions for whiter-boarding.
Below average people are looking for jobs because they are on PIP or they have toxic relationship with management or they will never get promoted in current role and need to change jobs.
The "dog properties" don't get listed on MLS at all; there is a cost to listing on MLS and the dog properties generally don't generate enough interest to justify the expense (and usually don't even attract a realtor willing to invest the effort).
Really talented engineers already have jobs and may not be actively looking to move, but if the right opportunity for the right company presents itself then they might consider it.
Once I applied for a job that had a really obscure job requirement which I met. The job was already filled but I spoke to the recruiter, who was really nice and ultimately found me a different job in another skill set about a month later.
The other was the traditional thing were a recruiter reached out to me. I actually didn't like the recruiter, but I liked the job and ended up pursuing it anyway.
Due to my current situation, I tend to only deal with recruiters who are local to where I live; unless the job opening allows for telecommuting, or it is a "too good to pass up" situation (I have yet to see one) - I will generally pass it up.
Instead, I currently only work with a couple of local recruiters. I have told both what I expect for interviewing (I prefer a practical interview with tests - not a whiteboard pressure interview), and I keep both informed what interviews the other has sent me on, so they aren't both submitting me to the same position opening.
Going beyond 2-3 recruiters in such a situation can and will lead to a tracking nightmare, to keep all of them in synch and not submitting you to the same opening - either at the same time, or worse, after you have already been interviewed once and weren't successful.
I do however, try to review the contacts I do get from recruiters, and if I feel they might be useful in the future, I tell them so, and keep a contact with them (even if it is just a LinkedIn or email contact) - and let them know I am interested in the future. That'll usually be enough for them to keep me in their DB for future potential offers to come up.
See, I see that time as very expensive.
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.
Tracking links are not always == shotgun approach
It's a little less flattering when they can't correctly pronounce my name or the state I live in.
I work with about 70 companies (only in NYC) from pre-launch to almost IPO and a new role opens up to a us every week. It's helpful to find a recruiter who knows you & the market well enough to curate jobs you want and tell you about opportunities that might not even be listed or on your radar.
The best recruiters can not only make efficient matches, but they also connect the dots to reach out to matches in the pool of passive candidates they talked to when a new role opens up.
Even better than that is when I'm able to actual push back with companies and make an impact on the hiring process to get someone hired.
With that foundation I'm more effective as I see more career trajectory data points when I talk to candidates that specialize (data, security, devops, ml) or ladder up (vp, manager, cto). Then I can provide even more value to new candidates with the career counseling approach.
Related anecdote: There was a technology recruiter that was constantly calling me at work, despite the fact that my work number is not listed anywhere* and my LinkedIn profile having clear instructions not to do that.
I decided to look him up on LinkedIn. Guess what his previous job was? Debt collector.
* I figure the recruiters get around that by calling the front desk and asking to be transferred to me.
But mostly I want to get it because I want to see what these companies are expecting from their candidates, technology these companies are using, and the salary range. DevOps / SRE / Production Engineers are high in demand.
Note many job recruitments are from agency so they are likely hiring consultants, so paycheck doesn't come from the actual client company.
(I don't redirect all recruiters, though, so there's still a filter)
The best time to interview is when you're very happy with your current job.
Zero pressure, zero commitment and potentially huge upside in terms of pay and title increase.
They have their own recruiting team that you are going to be dealing with anyway, and aren't playing the numbers game or shuffling their candidates between many different companies trying to get their (usually very large) hire bonus. They just throw as many people they can at as many companies they can till they get a bite.
Senior employees can be up to a FULL YEAR of the hired employees salary. As that employee you don't pay it, but it's not something that is benefiting you either. On top of that, the companies often have claw backs. If the employee leaves under a certain time, they have to give back their fee.
The reason they don't respond after the first email, is that they need someone who is going to be very proactive and actually motivated to get hired. Else their candidate catapult might hit the target, but less likely to stick.
This is false. My last two roles were both initiated by 3rd-party recruiters.
If you don't have any way for companies to target you themselves, then 3rd party recruiters might be more effective the you targeting companies directly yourself.
However, if you are in the boat where you are getting many recruiter emails a week, my advice is sound. They are all junk, and the only way to get any signal to noise is to look for ones directly from the company doing the hiring.
Tumbleweeds every time.
Not true. Companies hire recruiters to find employees. Not all companies (especially startups) have their own internal recruiting department.
The flip side is true, though: as a company trying to hire people, every recruiter email that says "I have a perfect candidate for you" is junk. They just invent those people or send resumes of people who aren't even on the job market.
A founder should personally be handling recruiting until the company is big enough to have their own internal recruiting department.
"Hey, you look like a great candidate for $AWESOME_JOB"
"Great, let's talk"
"Oh, you're not really what they're looking for, can I interest you in $GARBAGE_JOB or $BASEMENT_AT_YELLING_CORP"
But by then I've showed interest, so I start getting calls. Not worth it.
I see you're working as $ROLE in $COMPANY_A. How would you like the exact same $ROLE in $COMPANY_B? Or worse, How would you like $ROLE-1 in $COMPANY_B.
Sorry but it's going to take at least $ROLE+1 to get me to uproot my life and go through that interview gauntlet again.
Of course, as I said in another post, the calculus changes entirely if you're unemployed and need "something, anything".
My company has 'Linux' in it's name, apparently recruiters think that means I'm a sysadmin (I'm a dev).
Out of 200 job offers from recruiters you're lucky if one is open to a remote placement.
Nevertheless I think being out there and reducing your time invested in this slow process is still worth it, and a great idea.
The more important nugget is that he is contacted about two attractive opportunities a year for his passive method that have a fairly high probability of leading to offers if he is interested. This enables him to: 1. Accurately appraise his worth to companies, 2. Quickly scale to a much higher number of interesting opportunities through the 14 worthwhile recruiters per year that already value his conduct (even if only 2 per year have opportunities with appropriate fit) by actively involving their aid if he becomes dissatisfied with his current employer/role (or they become dissatisfied with him), 3. Identify hiring trends in his field.
I for one think it is a brilliant strategy, and I'll probably adopt it myself!
80% of it is for jobs within the surrounding city, 10% for within the state and 10% out of state. That said, most of these jobs you could also find without the recruiters as well, but sometimes ones from internal recruiters (and if you're lucky a developer/dev manager) are useful.
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.
Just follow all the guidelines that LinkedIn gives you, so that your profile is an "all-star" and make sure you have a bunch of connections (500+).
An email a day is fairly normal at least for SF engineers.
I normally get nearly zero recruiter emails, but late last year I changed my location preferences on Indeed and/or Career builder (I don't remember) from my hometown to Washington DC and suddenly I was deluged with the 20+ recruiter emails per month; more right after I update something on my profile.
Strangely, 1/2 of the emails are for locations far away from DC. I might try changing my preferences to San Jose and see how many more I get.
My "profile" is pretty much just my resume. Experience seems to be another important factor.
AND work on IT. As an housing architect I received zero offers from recruiters despite having relevant experience. By the other hand I have been contacted several times by IT recruiters once I listed there (irrelevant) IT side projects.
Resuming: it's not you, it's IT..
Edit: heck with it, I've got nothing to hide. Enjoy: https://www.fuzzy-logic.org/file/Lee_Whalen_Resume.pdf
So folks don't abuse my poor auto-responder, here's what would happen if you hit the email in that resume: http://bit.ly/2lxsly3
2) The numbers in that autoresponder caused my jaw to hit the floor. I thought I was well compensated but apparently there is a lot of room for me to grow!
I'm not kidding. Dear HN reader, please steal this idea!
Okay maybe I took it too far.
You didn't take it too far, someone build the first online recruiter focused video game where the prize at the end of each level is the contact details for a more-and-more suitably qualified candidate.
To me, getting this done on interesting domains seems to be the hard part. For people with their own domain, getting a separate server to deal with email for that is some hassle. You can't really do this on a generic domain either, cause that looks a lot less professional. Signing people up for gMail accounts might work, but that's probably against google eula. I'd guess the same for other webmail services that are at least somewhat professionally acceptable.
Best way I see is to give people with their own domain as easy a time as possible to set up DNS correctly. Getting through DKIM and SPF reliably seems like a minefield though.
As an engineer you should have a clear picture of the kinds of companies that you want to work for. As you get older, your selection criteria should improve and become more detailed.
The only ones I tend to ignore are the recruiters who are bringing positions that are far out of my geographic areas and are not remote.
While I agree with the author about algorithm questions being relatively pointless, my sense is they don't know about the team matching process. After I interviewed with Google, they presented me with a list of a eight teams who were interested in me and asked me to rank them in order of preference. They then had me come back a second day and meet with the managers of the top four teams I selected. At the end of the day, I ranked the teams again. The team I ranked the highest who also wanted to hire me was the team I would have joined if I had accepted my offer.
I much prefer the current process where you have one day of general interviews, and then go back a second day and just talk with the managers of the teams you would be interested in. It would only make the process much more of a hassle for everyone involved if you had to be interviewed by the managers of every team for which there was mutual interest.
If you don't know algorithms, maybe that's okay for the team you're joining. But hiring you means screwing over the team you're going to be on in 3 years. That's why they interview that way.
My company is experiencing this as we grow; we have too many openings to have each team try to recruit for their open spots. We need a more general queue of talent to hire, so that we can interview for 10 open spots for every interview we do.
I generally agree when it comes to cold resumes. However, in this case, OP is talking about being actively recruited. In that case there ought to be a specific manager that was looking for a specific type of person. Otherwise the recruiter is just wasting everyone's time.
I learned mine with AWS as well:
Scheduled call. They forgot to call. Waited like an idiot for an hour. Ok fine big company yadda, yadda.
Had the phone interview. Liked me, called me onsite.
Before coming onsite was sent the Leaderhips Princples and told to learn and will be quizzed on them basically. Had 2 offers in hand already and was told they'd get back to me at most 2 days after the interviews.
Got to the site. Future manager who was supposed to interview me not there.
Whiteboard questions, solve some algorithm puzzles. "Tell me about your worst failure". Most people I talked to would not have even worked with. People did not seem happy, kept warning me about how hard it is to work there and so on. (Subconsciously perhaps telling me to stay away?)
Lunch time comes, at least think I'll eat lunch with future team. So I wait, and wait, and nobody shows up. Ended up wondering the hallways exploring. Hoping someone would ask me if I am supposed to be there.
Then I got a bit snarky after that and kind of gave up on the chance of wanting to work there.
Went home. It took them 3 weeks to call me. But I wasn't surprised by that point.
Back in the 90's and early 2000's in non Silicon Valley tech companies, this was Simply Not Done. I find Silicon Valley tech culture a little loose when it comes to interpersonal morals.