At a certain point, your resume should speak for itself. The fact that experienced engineers with impressive resumes are put through these types of interviews is insulting and frustrating to the interviewees.
Succeeding at these whiteboard questions requires weeks of preparation. You need to practice, practice, practice. After enough practice, you are pretty likely to pass. So ultimately, it is more of a test of "how much do you want to work here." If you care enough, you can pass. That said, these types of interviews do favor fresh grads over experienced programmers (you have algorithms and data structures fresh in your mind), which means that they are flawed in IMHO.
These types of interviews work really well for the "I got 1600 on my SATs and went to {insert high profile school here} crowd" There are books out there just to prep you for Google interviews I see these as very similar to SAT test prep books. I'm not so sure Google is really interested in hiring the best engineers but rather a specific type of engineer.
Think of the problem from Google's perspective though. At some point, you have tens of thousands of candidates and you need a system to quantify how good they are. Further, it's reasonable to have false negatives (people you don't hire that should have been hired) but really bad to have false positives (people that you hire that you should not have). Together, these boil down into the de facto whiteboarding interview process.
People have previously mentioned hallway discussions at Google routinely devolve into bragging about SAT scores and GPAs.
Nothing says Google must accept sub-par technical people, but Google fails to realize you don't have to be the top 0.0001% in absolute algorithms intelligence to do great work.
Google's basic theme seems to be "you must be low latency ultra smart in our narrow interest areas" to pass an interview (or well-connected in other ways to lower scrutiny), but Google's main problem these days isn't lack of smart people — it's lack of projects with meaning and lack of how to organize smart people into anything resembling a coherent world-moving force.
In The Plex is great read for insight into their entire process. Basically, Google is run by people who have never been told "no" to anything in their lives, so they continue to think they are the best at everything until reality forces them to reconsider their delusional assumptions ("montessori naivety").
> Google is really interested in hiring the best engineers but rather a specific type of engineer.
I think you made an excellent point. It seems that outside a tiny minority of world-class experts, Google is more interested in hiring interchangeable workers.
Exactly. I see it as a tacit admission that you are effectively a cog in a wheel if those are the kinds of questions they are asking.
I know some people get frustrated by those kinds of questions, but I'd just see it as a reverse weeding out process. If you still want to work at (insert company here), just build something valuable and have them acquire you. At that point they'll acqui-hire you and you'll leap frog all the people who got in because they had Knuth books memorized.
Really? Being able to solve basic CS101 problems requires some sort of privileged upbringing? I grew up poor - my family lived off food stamps for a while. This stuff is easy. I find it disgusting the level of entitlement swept throughout this thread. Oh Google HAD to give you that job, it was yours and they stole it by testing basic skills.
You know, there is something to be said for someone who has a good product sense, but not good developer skills. They sound very valuable, so why are they applying to a developer position? Just because you are unqualified for one job, doesn't mean you deserved that job, or that you're worthless.
I suspect the issue is that programmers right out of college are strong on testable skills (like how to do X to a linked list) and weak on experience-based skills that are harder to test (like how to keep projects under budget or how to manage technical debt). Whereas veterans naturally tend to be the opposite. And hiring processes naturally tend towards what's easier to test.
As such, the best approach to these interviews might be to say, "Look, I could take a stab at that algo question, but I haven't touched that stuff since school, and if I needed it I'd google it. It might be more productive if we talked about what I've been doing day-to-day for the last ten years to ship successful products, because that's the main value I can bring to your company."
I aced some data analyst interviews fresh out of grad school. A lot of the questions were excel and probability questions, which I used to teach. Now, I have more experience and knowledge, but I would be much slower in those interviews.
>not so sure Google is really interested in hiring the best engineers but rather a specific type of engineer.
Any mature company should focus on finding those specific candidates - the ones who fit the company and specific team, on several dimensions beyond standard skillsrequired for the job. That's someone who will be called the best candidate in that specific company. And it's absolutely natural that s/he won't be considered "best" insome other company.
I interviewed @ google several years ago as part of some due-diligence they were doing to decide if they wanted to acquire the startup I was working at, [redacted].
It was several hours, with many interviewers one at a time, of academic exercises. Some I could see were relevant to some of Google's projects, but that wasn't the emphasis- it was very much a "how much do you remember from CS courses?" (with a few exceptions- one had me explain why a snippet of C would crash- something more what I would expect a senior engineer to know that was more practical-oriented).
I _think_ I did pretty well (again, it was part of a bigger due-diligence-- another story altogether, so I never heard), but in the end I was struck by the fact that (a) not a single interviewer had looked at or asked about any of my publicly available work, and (b) not a single one even asked something along the lines of "what are your strengths / what do you think your contribution would be" (or weaknesses, for that matter, but that seems less important).
Of course, one of the other guys I worked with lucked out and got interviewed by one of the paypal-mafia, and ended up with a reportedly very stimulating hour long discussion about actual work, strengths, and actual situations that one would hypothetically need to handle at google.
Your previous work is what gets you in the door, but interviews at Google are explicitly structured so that you need to demonstrate competence right then and there.
And ye olde "what's your greatest strength/weakness" question sounds like a terrible way to judge an engineer.
> not a single interviewer had looked at or asked about any of my publicly available work
It could be dangerous. Let's say you explain some interesting techniques you used on your GPL'd software and a Google product starts doing something suspiciously like what you showed them. You may even sue and end up making their source public after some litigation.
Replying to myself- too late to edit. Some other comments in here lead me to believe there would be experience-related questions ideally these days. Again, my experience was a few years ago :-)
"How much do you want to work here?" is probably a better predictor of your performance on the job than your experience is. I don't see the problem with that: IMHO, the fresh grad who really really wants to be there should be hired over the experienced veteran who's just putting in time. I'd like to think that an experienced veteran who really really wants to be there would also get the job, though, over both of the other candidates.
> At a certain point, your resume should speak for itself. The fact that experienced engineers with impressive resumes are put through these types of interviews is insulting and frustrating to the interviewees.
Only to bad interviewees.
You'd be shocked to hear the number of impressive résumés I have seen who turned out to be absolute no-hires after 20mn on a white board. By "absolute no hire", I mean the kind where some of the interviewers tell me in the debriefing "I will quit if we hire this guy".
Not all excellent engineers have impressive résumés but they all share a common characteristic in my experience: they all really enjoyed working on the problems I asked them to solve on the white board. I even had some of them be disappointed when we ran out of time because we were having interesting conversations about the problem.
> You'd be shocked to hear the number of impressive résumés I have seen who turned out to be absolute no-hires after 20mn on a white board.
Hmm, at least in my experience it's really quick and easy to tell if someone is bullshitting about their resume or not by simply talking about the different projects they worked on. I know a few developers who didn't go to a 4 year school so they don't know all of the correct terms or algorithms (one even interviewed for Google and failed) but I would hire them in a heart beat because they are really awesome.
I still feel some sort of pair-programming exercise or something similar is better than simply trying to solve problems on a white board. Unless you're in a SCIF you're going to have access to the internet to refresh your memory, etc so I've never found utility in asking academic questions. In fact I've had a few people who could pass the academic questions but couldn't build an application to save their life so I don't even bother anymore.
>By "absolute no hire", I mean the kind where some of the interviewers tell me in the debriefing "I will quit if we hire this guy".
That's just a self-reinforcing selection bias - you hire people that are good at these kinds of problems/enjoy them - you filter out the rest by default and it becomes ingrained in the culture - it doesn't say anything about the suitability of the candidates you filtered out. If you said "we hired a guy who had a great resume but he couldn't do algorithmic problems, turned out to be a bad fit for the company" - that would still be a single data point but at least it would be relevant.
I would agree with what you said if you replaced resume with reputation. Anyone can fill out a nice resume.
One of the challenges with Google's interview process [0] is they are very worried about hiring mistakes, and also know that the process is very noisy. As such, they interview a tremendous amount of people for hiring. In addition, they've found it more efficient to just keep a high bar (missing many good hires to keep out 1 bad hire) than to conduct more than 5 interviews.
The one thing I've wonder is - if they want the top 100 computer scientists in the world to work for them, will this process produce that? Or is there another process for them?
I think the most effective way to get a job there is to build a small company and get acquihired.
[0] I don't work at Google, but I've researched the process in anticipation of an interview.
Well I know one mistake they may have made in hiring. Guy I used to work with had a totally unclear design process and couldn't complete his work. He would design flawed algorithms that made no sense to anyway and then he asked for lead a project which he dug himself into a hole and had me pulled in to help him and then abandoned me and left the company. Spent 3 months cleaning up his mess. I wonder how he is working out for them...
Ah, they are very unlikely to get the top 100, but very likely to get e.g. 100 of the top 200? Now I think I understand the trade off they are going for (e.g. Getting 100 of the top 200 is more efficient and they are "good enough")
It's also stressful. To be fair the tree problem he got was easy, but brain freeze can kill you. I flubbed a trivial problem at a FB interview that still haunts me today.
Often it's completely free-form too. So you have to pick the language, the data model, the data structures, the traversal mechanism (recursive vs. iterative), state to track (allow duplicates? prevent infinite loops?) and how to test the example all at once before even getting _started_ with their problem description.
Many of the interviews could actually work if they broke the process down into 8 questions instead of one (how would you represent a tree? a binary tree? how would you find node X? how would you move node X to the other side of the tree?). But, the ability to accommodate understanding takes empathy and human connection, not being a jerk programmer on interview duty who is browsing HN while listing to the interviewee mumble on your speakerphone.
Never underestimate the lack of ability in the interviewer and not the interviewee. Except, the company always believes itself to be more competent than outsiders, so you're ultimately left with being condescended to unnecessarily.
Ha, I totally messed up a question for a front end interview today that could have easily been solved with timeouts. I didn't realize timeouts had resets as I haven't used them extensively and bam I'm trying to essentially design a reset for a generic counter. Boy I felt ridiculous. As soon as he said use timeout reset it's immediately obvious what I had to do. I'm not a bad programmer but between brain freeze and whiteboarding, and interviewing day after day for a few weeks, it just didn't occur. Killed me and I hope I don't miss out on an offer from a company I was actually really interested in because of some bullshit brainfart on something I'm not particularly well versed in.
Whatever! They asked me back but it sure is a frustrating feeling even if I tend not to appear flustered until I walk out, introspect, and realize what a doofus I was.
They don't just stop at binary trees. Think of it more like memorizing hundreds of magic tricks that could be done using a deck of cards. The tree is more analogous to those deck of cards. The data structure remains constant but the tricks you can do keep changing.
I know of situations where candidates have been grilled whole full hours on tree traversal methods, and then asked to code up perfectly working solutions for them.
Do these people seriously think people who can invent 50 years of CS research by sheer analysis over an hour on the whiteboard, will be ready to work for them to write shell scripts? If not you are only testing memory skills.
In my academic days I used to refer to say "physics-standing-up" is a different subject from "physics-sitting-down" and needs to be studied separately. Some years after I left academia I had the good fortune to get in contact with the person who introduced me to acting at a very young age and thank her for her contribution to my academic career. About 30% of my success was due to my comfort working in front of an audience--even a panel of examiners is "an audience"--and I had a huge advantage over my peers because of it.
One thing that I'd recommend to anyone seeking any kind of job is taking some improv courses--they are pretty common in major centers and even some smaller towns, and can really improve your ability to deal with this kind of nonsensical interview situation, which tests a bunch of skills that have nothing to do with your ability to actually do the job.
I'll disagree that these questions require weeks of preparation. I think it's more just unfair because they favor a certain type of person: those whose interests align more strongly with the theory and algorithms and less with building things.
Of course, the irony is that for vast majority of the people they hire, most of the work they do will be building and not much algorithms work. So then what will happen is either you have people who are great at building things and force them to suffer through the interviews or you have people who are great at algorithms but not that interested in programming.
Of course, you might also have people who are great at both, but I wonder how many of them there are..
I don't necessarily agree though, I think if you can reason about a problem, you are infinitely more valuable than someone who memorizes problems and just applies them blindly.
Correct me if I'm wrong, but a binary search tree is a very simple data structure. It has rules, and just by it's definition, and the definition of "inverted", you should be able to come up with an iterative solution, even if it's just walking the tree and re-creating it.
It may not be the best, but it's a solution, it's a starting point.
But if you're interviewing for a job solving problems, shouldn't you be able to solve problems? Even if they aren't the best solution? Genuinely asking here, as this approach seems to have a 85-90% success rate for me.
It depends how your interviewer is ranking/scoring you. One interviewer might be impressed with your ability to talk through and solve the problem from first principles, where another might ding you for not instantly knowing the answer. The former type of interviewer would be happy to give you hints and prompts, the second is a stone wall. I try to be the first -- it helps assess how a candidate responds to coaching too! -- but there's a spectrum between "nudging" and "telling them the answer straight out".
Is a binary search tree a problem that the Dev would have needed to solve? In over 5 years as a dev, I have never once needed to solve a binary search tree. Why not ask the candidate how to perform a kidney transplant.. That's solving a problem too. White boarding algorithms is not relevant to the majority of Dev jobs. It's related, but not particularly valuable as a screener.
Typing "how to reverse a binary search tree" into google is not the same thing as solving a problem.
If these problems were so reliant on individual problem solving ability, there wouldn't be dozens of books with reams of answers to these questions on the market. These questions test memorization and nothing else.
Google said early on they want to hire the best and brightest and that was the most important. We got the mantra that passing over a good person is better than hiring a bad one. And they were right. But they're a huge company now. They, and other gigantic tech companies are always complaining they can't find 'good people'.
But how do you make this philosophy scale? Do you say, "This person is smart but lacking some skills so we'll invest in them"?
Smart people will learn what they need to to do a job if they're interested in it.
Google has decided that the only way to tell if someone is smart is by asking academic questions.
Even though anyone with half a brain knows that there are other ways to gauge how smart a person is... such as experience.
Does anyone really think Max can't look up how to invert a binary tree if he needs to do that? He obviously knows how to read and learn. So why is that a reason to reject someone?
Google is filled with smart people.. but their interview process is pretty stupid.
> The gigantic tech companies are always complaining they can't find 'good people'.
The "can't find good people" argument can usually be solved either 1) raising the pay, or 2) increasing the labor pool (i.e. H1B, etc). Raising the pay is what is done in finance because it's harder to make the argument that the required "skills" are lacking in the labor pool. To enter investment banking, and then private equity, it often only requires a B.A. in French literature and willingness to work 90 hours.
I agree. I feel the overpowering urge, when asked this sort of basic interview question, to shout back "WHY?". What does inverting a binary tree have to do with software engineering, at all?
Google (and other interviewers) might as well be asking me to name the last 1000 digits of PI. The Kafkaesquen ability to recite how to do the task correctly reflects nothing about the candidate, except the strength of their memory.
It boggles the mind that the field of computer science does not have any standard way to detect the competency of a person. It is extremely discongruous for a company with as many smart people as Google to have such an absurd hiring policy.
At my job, our interview guidelines explicitly say that we don't expect non-graduates to be able to whip out fancy data structures. We want to see that the person can program, how he thinks about problems and system design, and how they deal with being stuck. I've seen people with impressive CVs and PhDs that were unable to solve very simple programming tasks.
Google interviewers are strictly told to ask these data structures and algorithms questions, it doesn't matter to them if they are relevant for future work. I have even read reviews by PhD candidates where even they were asked these questions in the interviews. When I interviewed with Google last year, I remember that the interviewers had a blueprint of the type of questions they were allowed to ask. They hardly concentrate on your resume during the interviews.
At what point during one's career should one simply be hired at face value and be exempt from interviewing? After 10 years? 20? 30?
"I see your resume says you've been writing software for 30 years, and wrote this really well known tool. Wellllll....That's good enough for me. You're hired!"
Background: I worked at Google for 5 years and did a bunch of interviewing for them.
I don't support skipping interviews even for good candidates, but if you were going to it would work the other way around -- you'd value recent accomplishments over more distant ones.
People don't understand that cutting out folks who had their name attached to some big successes but can't solve a toy problem in an interview is usually a really good thing. It's a strength of the system more often than a weakness. You wouldn't believe the number of senior candidates I interviewed who had really impressive resumes but were clearly checked out from doing real technical work -- folks who obviously no longer lived close to the code and either were very rusty or just no longer had the temperament to spend time thinking through a slightly tricky piece of code.
One of the reasons not to skip an interview for a candidate you're confident is good is that a good interview can be a great sales pitch to come work for your company.
I've interviewed and worked with 30 year programmers and for some of them it was obvious could not program and their resumes were concocted. I would never rely on a resume.
Another way of looking at it is that they do these kinds of interviews particularly because they do want to hire fresh grads (and ideally, the best 5% of those) over experienced programmers. And if that's the case, then it's not really flawed, it's doing what it's supposed to do.
Actually, Max himself said that it "Felt like they would have preferred a fresh comp sci grad."[1]
Investment banks recruit bright young graduates, putting them through a tough selection process (c.f. all those hard-working interns we keep reading about), and select the ones who perform/conform the best. The rationale for bringing in young (as opposed to experienced) people is that they'll work their asses off, can be moulded to fit the culture (i.e. independent thinkers aren't necessarily sought), and (perhaps most importantly) are too junior to present a threat to the incumbents.
If Google's going down the same path, it may be a sign that their corporate culture is solidifying, which would be a bad sign, IMHO.
I think this is probably overall true. I'm a bit cynical, maybe, but the set of tech used by developers here at Google does not necessarily intersect with what is used in the rest of the industry. So much is proprietary, and best practices are heavily codified and well understood. So in reality I suspect that new grads are as valuable or more valuable to Google as experienced engineers since it's unlikely the specific technologies an experienced engineer has under their belt will be specifically applicable here.
For the top elite of experienced engineers that may not be the case, as they will come with some overall good analytical skills that Google wants. But for most in our industry, what we have learned over the years is how to be good in various sets of tech around our platforms of choice... and that is mostly irrelevant to Google, as they have their own platforms.
It always surprises me when people like Pacino or De Niro talk about going for auditions - I'd imagine they had a large enough body of work that directors would know what they can do.
But then it occurs to me that they won't have seen them in -this- role acting -this- way for -this- film/play/whatnot and that's what the director needs. And given the amount of money and risk involved, it's probably wise to check first...
That's true. However In Google defense, they tell you upfront what kind of interviews you're going to get and their process it's pretty well known anyway (with all its flaws).
I went through the same pain myself a few years ago and I'm not disagreeing that the chap should have just got the job there, but their process is well known and perhaps he just had the wrong expectations.
They all just seem to be varying levels of fanciness over relatively common data structures and algorithms. I was only applying for internships but the whiteboard stuff wasn't too bad when I did (and other questions I practiced online), I imagine almost completely because we'd done 2 related modules at university.
You spot patterns but there's so many different ways they can ask things and things that you just remember from studying it, that I imagine I'd do worse now unless it was close to what I've done since. On the spot I couldn't invert a BST right now.
I suspect you could probably pass a whiteboard interview a few weeks after taking a mooc on data structures/algorithms with enough depth for example.
Could you illustrate? I can find plenty of examples of mirroring/reversing a tree (below the root node) but none that really invert it. I haven't even found a definition of what inverting a tree means (aside from some academic papers I haven't been able to read yet), despite quite a bit of googling.
The fact is, that reliably separating bad from good engineers is incredibly difficult at best.
For big companies that want to scale hiring process, there's really not much you can do.
You put difficult questions and you hope that bad engineers will not be able to solve them. Then you absolutely have to commit to not hiring the guys who can't solve the assignment, otherwise it's all for naught.
I spent Xmas break reviewing the most recent TopCoder problems, C++ and STL, and read Sedgewick's algorithms book cover to cover. I drank two quad espressos right before the interview. The interview was a straightforward process and I didn't miss a single question. The offer came that evening.
I should have turned it down. I've written on this thread already what a career-churning waste of time my brief stint at Google turned out to be because I was blind allocated.
Fortunately, the skills that got me noticed by Google were in demand elsewhere then (and, ironically, in demand at Google now) so I just exited the building when it became clear HR had labelled me a troublemaker for trying to find a position that made use of my talents rather than opt for the career reboot they seemed to expect of me. Great perks, but the 2nd worst gig I've had my entire career.
To all of those saying ranting on twitter is the wrong move I couldn't disagree more. Twitter is often the ONLY tool that the average person can use to communicate and/or call out large companies on their actions. This is BS and should be made known. Homebrew is an amazing tool and I'd be falling over myself getting the offer papers in this guy's hands if he came to me looking for a job. The fact that google turned him away only further cements my opinion that google would be a terrible place to work.
My main complaint with the tweet is that it's almost certainly speculation.
1) Most companies (for legal reasons) don't tell candidates why they weren't offered a job. Maybe it was because of the binary tree question, but maybe it was for some other reason.
2) Homebrew is a Mac-only product, so the likelihood that 90% of Googlers use homebrew is very low. Moreover, Google does not track the software its employees download onto their laptops, so there's no way they would even know the percentage.
> 1) Most companies (for legal reasons) don't tell candidates why they weren't offered a job. Maybe it was because of the binary tree question, but maybe it was for some other reason.
So when I was declined at Google I knew people who worked for Google. One looked up my profile in whatever system they used and the other simply asked the interviewer why. OP may have done the same but as you say it's unclear either way but knowing is still possible.
> 2) Homebrew is a Mac-only product, so the likelihood that 90% of Googlers use homebrew is very low. Moreover, Google does not track the software its employees download onto their laptops, so there's no way they would even know the percentage.
Most of the people I know at Google use Macs so I don't see why not. I don't know what the majority of them use but a good chunk at least do.
As far as tracking he could simply be tracking it himself and comparing his results of known Google IPs to employee counts. Not as accurate but might give a rough estimation. He may have further analytics based on data collected (if collected) by each machine.
We don't have all the details. You might not hire the best computer programmer in the world if he was also a psychopath. Heck, you might skip on him even if he wasn't a good culture fit. I'm not saying this person is / was any of those things, but there's more to hiring than just talent.
There's also the committee factor. Google doesn't hire/no-hire based just on one person's opinion. If half your committee says, "90% of our engineers use his thing!" and the other half says, "But he can't code on a whiteboard!" then the committee is already kinda likely to take a pass due to lack of consensus. If there's any doubts at all on culture fit, which Google absolutely does care a great deal about, even more so. That said, when I was there, I interviewed someone who was essentially going to be my partner on something and everyone else (who weren't going to be working with this person) ranked the person poorly and I was the sole voice of (positive) dissent. I wasn't on the committee, so I don't know what their logic was, but the person was hired. And they were great. So it's not always even a majority opinion thing with the interviewers. In a nutshell, not only are we dealing with incomplete information here, we're dealing with VERY incomplete information.
That's not what happened at all. Google has an interview process that is designed to weed out false positives(incompetent people getting hired). Because this guy didn't have enough algorithmic knowledge he failed their filter. To work at the borg you must learn and play by the borgs rules!
Ranting on twitter is fucking awful. All it gives is nuance-free soundbites, and there are no 'lines to read between' due to it's brevity. Stuff gets taken the wrong way or out of context all the time.
One of the reasons why it's so powerful is because it gives lazy journalists a stream of easy reaction quotes. When else in the history of journalism has there ever been a private company that was so heavily promoted, regardless of the media source? And even then, the react quotes are poor quality, single-sentence shit.
This rant on twitter is absolutely meaningless unless you have a heap of context to go with it. And because twitter is popular, it's dumbing down public discourse along with it.
/rant, that I couldn't have fit in 140 characters.
maybe Homebrew is amazing, but Google can hire the best people in the world. that day they might've interviewed 10 people better than him who just didn't make a popular tool
"that day they might've interviewed 10 people better than him who just didn't make a popular tool"
Are you judging this on their ability to invert a binary tree? People here are ranting about having a problem with interview practices not representing whether or not you are good at your job. That's presumably (IMO) why the tweet was posted.
Esteemed schools of music probably produce dozens of guitarists "better" (in any way you would measure it academically) than Jimmy Page or Jimi Hendrix per year who go on to a life of producing nothing of lasting worth.
I'll take the guy/girl who has actually proved they can produce something useful every time over someone who is "better" but hasn't.
Has no one stopped to question what Google may have been looking for in a candidate?
The OP has written some great apps, sure, but there is a huge difference between writing a package manager for Mac (among other Mac/iOS apps and utilities) and writing incredibly complex, highly performant algorithms for say search indexing, machine learning, ai, etc...
In that context, knowing CompSci basics like Binary Trees (usually taught to pre-major CompSci students) has a lot of relevance. It's clear Google was looking for a Computer Scientist here, not just another developer.
I am also put off by the extreme display of non-professionalism here. It's like the OP took this personally as an insult. "I've written popular things, how dare you not hire me if I want to work for you!". That's not a professional I'd like to work on a team with. Rather, that's a throw-back to the "Rockstar" programmer that nobody wants to work with.
This boils down to a person who was personally offended a company did not hire them at a drop of a hat, as-if he was "blessing" Google with his presence.
I'd say, Google (and other companies) are better off without this type of ego.
They made the proper choice to weed this individual out.
I used to do interviews at Google, and most likely, the interview process just failed in this case. Typically a candidate will do 5 technical interviews, where the Google engineers can ask basically anything they want to (eg. invert a binary tree in this case) and score the candidate. If the candidate trips up on one of these interviews, that can be enough to reject them. The process will sometimes randomly reject qualified people.
Additionally, I think people have a mis-perception of the skills required to work at Google:
> writing incredibly complex, highly performant algorithms for say search indexing, machine learning, ai, etc...
...
> Google was looking for a Computer Scientist here, not just another developer
This is not really the case. The large majority of positions are for basically "just another developer" to maintain an internal Java tool, or some web UI, or whatever. They are complex in that they have many dependencies and often lots of legacy code, but not all to different from Microsoft, Apple, Facebook, or any company with a large code base. In my several years at Google, 0-5% of my time was spent coming up with complex algorithms.
Then why do they put people through those extreme paces? If you have the chops to get through the Google interview process, you are not "just another developer." If I were enough of a star to get through the process, got hired, and then was put to work maintaining some internal Java tool, I'd be pretty pissed off.
In fairness, package managers can get surprisingly complicated from a CS aspect. openSUSE wrote an elaborate reusable SAT solver library just for the dependency resolution component. Then let's not ignore that a package manager at its core must deal with the finicky nature of contemporary dynamic linking, the OS environment and all the baggage that comes with heterogenous library contexts and namespaces, maintaining transaction consistency, preferably ensuring atomic operations and so on.
That said, I don't think Homebrew is one of these. Always seemed like a quick fix for an OS X deficiency to me, and its competitors MacPorts and Fink being mediocre themselves certainly helped with its popularity. Not to rain on the achievements of the developers, but still.
To further your point, Package Managers have been done... and have been getting done for a long time.
Blazing the trail in machine learning, ai, etc... that's new territory where there are no knowledge bases or places you can go to source information about how to do it.
That's a different ballgame, and requires a scientist, not an engineer/developer.
If you follow the twitter discussion, it says he applied for iOS tools. I don't know what tools they write but I'd be surprised if someone who manages to write a (pretty good, actually) package manager can't solve the problems in this position.
> If you follow the twitter discussion, it says he applied for iOS tools
We cannot just assume that since he applied for iOS something at Google that he's the best fit and what they were looking for.
Maybe the tools Google needs built are very CS heavy (hence the "Build us a Binary Tree" question)? Maybe during the interview his arrogant attitude was on full display? Maybe the interview team dug up past episodes of explosive arrogance like this very one we're discussing right now?
Even if they were looking for someone that matched his profile exactly, his post-interview display of non-professionalism is sure to hurt his chances of a re-interview anytime in the future (and quite possibly at many more companies than just Google).
He conveyed several things with this display, none good;
There is no slander in his tweet, he reported the FACT, may be a tad-bit dramatic, but FACT none the less. I just cannot understand why people think, Job seekers should cower down in public in fear not getting a future offer. To the hell with it, speak your mind, live like a boss even it means you make a little less financially, its better than being a rich coward.
- The guy was not offered a job at Google after his interview.
Anything else is unconfirmed and, speaking as someone who's thrown quite a few frustrated hyperboles onto the internet, sounds like frustrated hyperbole.
Frustrated hyperbole should not be taken at face value as fact; sometimes there's truth in a smaller version of what's said, but not always.
For example, there is no fact established that Google hired him because he can't "invert a binary tree". In actual fact, we don't know that Google even asked him to invert a binary tree (at least not specifically). It could be that they asked him a question that he thought was as irrelevant as academic datastructure exercises.
And we don't know that his answer was the reason he got turned down either. This is the part of the hiring process (and really any human interaction) that takes the maturity of recognizing that people and their motivations/reasoning are more complex than we reflexively flatten them out to be.
> There is no slander in his tweet, he reported the FACT, may be a tad-bit dramatic, but FACT none the less
What facts are you talking about? The "facts" coming from half the parties involved? The "facts" coming from an upset and irrationally thinking person who's caught up in the moment?
All that you say is true, but there's another side of the coin.
Nobody wants rockstars in teams, because rockstars are bad team players. That's the reason why they're rockstars.
Nonconformity (sometimes) leads to innovation.
Like it or not, a lot of the tools and libraries which we use every day and on which the internet runs, was written by lone-wolf 'rockstars' too weird and too eccentric to work in large corps.
You don't want your whole army to go over those mountains, you send scouts. Scouts are terrible soldiers, but they are quick to find a path between the trees and rocks and they come back with new information, new ideas and concepts of how to optimally win the battle.
Then and only then you bring the whole army and win.
A company, imho, should always have a small number of rockstars - impossible characters, crazies and lunatics with universe-sized egos, who have a track record of successful projects in the wild, working on insane things, alone or in very small groups, carefully managed by someone who can earn their respect - usually a lone wolf turned general.
They might be terrible programmers, they may have no education, but they have this unusual ability to see into the future and come back with interesting ideas and prototypes, which the 'soldiers' - people with solid fundamentals - can polish and transform into profitable products.
If a company innovates 'from the top', then it's trend is going to slowly be downwards towards irrelevance, because true innovation comes from the trenches and is done by the rockstars nobody wants to work with.
being able to invert a binary tree makes you qualified to develop machine learning, ai, etc code? that's a pretty low bar. If that's the level of knowledge you need to do that, then can it really be called AI?
If that's really what they intended for him to develop, then why not ask questions about machine learning or AI?
The OP is the type of person that, six months from now would be demanding special treatment because "he wrote Homebrew".
Writing a package manager (been done before, a lot of times) is far different from writing machine learning algorithms (new field, blazing the trail for the industry). One requires an engineer, one requires a scientist.
The OP flamed out because Google was looking for something he was not. Instead of taking it like a professional, he decided to retaliate.
The tone he took in his post is appalling, and I cannot believe HNers are defending him. "I'm special because I wrote something popular (and make absurd claims about 90% of people using it), so you better hire me or else" is what he just laid down.
That's not the type of person I'd want to hire or work with... and I'd wager most would agree.
I didn't agree with you at first.. but after thinking about it I think you're absolutely right.
Getting rejected from one interview at Google isn't the end of the world. The right and mature thing would have been to go home and figure out the problem that you got stuck on.. and then try again. We all go through this process, why should we expect anyone else to get a free pass?
I recently watched an online game of chess between a grandmaster and an anonymous individual.* The grandmaster got caught off guard and got lured into a trap. Instead of getting defensive, he sincerely thanked the other individual for a great game and spent the next few minutes after discussing the intricacies of the trap.
Shouldn't someone as accomplished as the creator of Homebrew feel the same way about a problem he got stumped on?
They reached out to him - he mentioned it in a tweet, and they've skipped the phone interview . Also, he would not be the one writing the machine learning, search indexing, but rather the app itself. All of those would be handled by other non-ios developers.
[Ex-Googler here] Truth be told this is a trivial question to be asked during an algo interview and as an interviewer I'd consider this a warm-up. Otherwise it's a rather poor question since either you know how to do it (ie, you have an idea about recursion) or you don't - there aren't too many shades of grey or possible follow-up questions that I can ask to probe the depth of your knowledge.
That being said if I asked this as a warm-up and we'd spend the whole interview trying to get that done then of course my verdict would be No Hire. As an interviewer it is not my job to look at your GitHub profile - instead I am assigned an area to check and I try to come up with the best understanding of the candidate in that area. While failing to reverse a binary tree is a total failure in algo/ds you can still be hired since there are several interviewers (if you make it to onsites, that is), each probing a different area.
My biggest problem with Google style interview process is that it's easily passed by folks who already passed it in a different company. After having interviewed hundreds of Google's candidates I moved to another big company with the same interview type and the experience was really surreal. On my algo/ds interview I got asked slight variations of the same questions I was asking myself - and over time I've seen some totally brilliant, unexpected solutions. Must have been a strange experience for the interviewer who got his questions each answered in 3 minutes tops. I also made it a sport to solve each one in a different language because why not. Not sure though about validity of the signal the company got from this interview.
> [Ex-Googler here] Truth be told this is a trivial question to be asked during an algo interview and as an interviewer I'd consider this a warm-up. Otherwise it's a rather poor question since either you know how to do it (ie, you have an idea about recursion) or you don't - there aren't too many shades of grey or possible follow-up questions that I can ask to probe the depth of your knowledge.
It is a terrible question.
First, you can't invert a binary tree (as in flip upside down). If you did, you'd end up with multiple roots and since all binary trees are rooted, you'd no longer have a binary tree. It'd be a tree, just not a binary tree.
If the questioner meant mirror a binary tree (swap left & right at each node), then it is a no-op. You do not need to modify memory to do it. Left & right are just labels for two pointers. You can just swap the order your variables in whatever struct defines your node and cast it against your existing memory (or change what your accessors return in a derived class or create a reverse iterator or however you want to implement it) and there you go, a "reversed" tree with zero overhead.
Either way, it is a terrible question unless you wanted to see if someone understood the difference between how a data structure is drawn on a whiteboard for humans vs. how it actually works. Maybe they were actually asking that question, but that seems highly unlikely.
And if they actually meant for you to recurse down and swap left and right on everything, it would dramatically lower my opinion of them because it would make me wonder if they knew the difference between how a binary tree is drawn on a whiteboard vs. how it is laid out in memory.
> First, you can't invert a binary tree (as in flip upside down). If you did, you'd end up with multiple roots and since all binary trees are rooted, you'd no longer have a binary tree. It'd be a tree, just not a binary tree.
Inversion is a transformation that maps directed graphs to directed graphs. Binary trees are a subset of directed graphs, so applying inversion to them is not unreasonable. That subset is not closed under inversion, so you can get results that are not binary trees, but I see nothing in the question that implies that the interviewer was asking for the output to be a binary tree.
That may even be one of the points the interviewer wants to see the candidate address. Since the output no longer has a single node from which all other nodes can be reached, in addition to just inverting it they may want the candidate to mention the need to have some new auxiliary data structure to keep track of the multiple root nodes (and perhaps note that in the inverted tree each node only has one outgoing link, so if we are inverting in place each has room for two, so we can use that now available second link space to make a linked list of the roots, so we don't need any extra storage for the new root list data structure).
> if they actually meant for you to recurse down and swap
While only the person asking this question knows for sure I'd assume that was the intention.
It's not a _terrible_ question - it's just a recursive equivalent of FizzBuzz. You would treat this as a way of making a (good) candidate gain some confidence. And that alone is extremely important since the more at ease the candidate is the better the signal that you're getting. What I was trying to say there was that if I asked that as a warm-up and didn't get a satisfactory response very very soon I'd realise that your man has no clue about recursion and would move to the main question, choosing one that does not involve it. It would be something easier than I'd ask otherwise and would be closer to real-life scenarios - like first solving a simple problem, then parallelising the solution and correctly managing concurrent access.
> First, you can't invert a binary tree (as in flip upside down). If you did, you'd end up with multiple roots and since all binary trees are rooted, you'd no longer have a binary tree. It'd be a tree, just not a binary tree
Just because someone wrote on Twitter with limited number of characters that the problem was to "invert a binary tree", does not mean there were no clarification from the recruiter.
> And if they actually meant for you to recurse down and swap left and right on everything, it would dramatically lower my opinion of them because it would make me wonder if they knew the difference between how a binary tree is drawn on a whiteboard vs. how it is laid out in memory.
If you're thinking about making a real structure, I believe you should recurse down and swap. If you don't do this, rotating, joining etc, could be a real pain.
If they said "swap left & right at each node" it would have been easy. But they used a term that doesn't even yield an example in google searches - what kind of "inversion" do they have in mind? It's as if everyone is on the same page but me.
Exactly. This style interview doesn't find the people I think are valuable - people who ship code. Instead, it validates people who spend time thinking about interview questions.
The link between the content of your GitHub and your ability to ship code is unclear at best. I knew a guy who had a really awesome GitHub profile but turned out to be a mediocre contributor to the codebase. He claimed that coding style guides we used were hurting his creativity to the point that he did not enjoy coding and would avoid it if possible. He'd fix bugs and make small-ish contributions but would never ship major features or libraries "because of the style guide". While I understand the sentiment I always found his attitude juvenile.
WTF is "inverting a binary tree?". The smattering of search engine results points to some seemingly operation that basically generates garbage by destructively manipulating the tree into a DAG in which the leaves of the original tree are roots, which point downward the parents. The original root node is returned, and still points to its children. Unless you return some aggregate (e.g. list) of all the roots which are not direct children of the original root, or it is understood that something elsewhere holds reference to them, they are leaked.
Be that as it may, if the interviewers hand you a reasonably detailed specification of what "invert a binary tree" means and you can't whiteboard it, I don't see how you can expect the job.
If you're expected to know what it means, and get no hint, then that is just stupid. "Whiteboard up an implementation for something we refuse to specify, beyond citing its name."
I agree. I have no idea what "inverting a binary tree" means, or why I would want to do it, so I'd need some context from the interviewer. Chances are, I'd ask some very pointed questions about whether a binary tree is really the best underlying data structure for whatever the "inversion" process is intended to accomplish. The interview would probably go downhill from there.
My guess is that the potential leaking of some nodes is one of the points of the question. A lot of people would not notice it.
Note that in the original tree each node needs storage for two pointers. After inversion only one is needed. You can use that now unused storage to link together the multiple roots to solve the leak problem.
But note that only consumes the second pointer storage in the roots. Interior nodes end up with some free storage after inversion.
Since inversion is reversible, the binary tree and its inverse contain the same information. Does this mean we should only need one pointer's worth of storage in the binary tree nodes?
Is there something for binary trees similar to Knuth's xor trick for doubly linked lists?
If you invert the tree such that each node points to its parent, and there are no child pointers, you lose information. Namely, the order among children is lost. A given interior node still has two children as before, but it is not known which is the left child and which is the right child; there is just a set of up to two nodes which point to the same parent.
The binary tree inverse specifications/implementations I have looked at preserve the information by selectively using the left or right links. For instance, given:
P
/ \
L R
The inverse would be:
L R
\ /
P
Both children point to the parent. But the left child uses its right pointer, and the right child uses the left pointer. That's what preserves the information about which child is which.
Sorta ironic, but remember that the point of an interview is to determine how well you'd do in the environment that's hiring you, not how good a developer you are. Because Google tends to reinvent the wheel for basically everything, algorithmic knowledge really does matter. Package management only matters within a few very specific subteams. If you're interviewing for a general SWE position, you could be Mark Zuckerburg and still not qualify for it.
FWIW, I find Facebook turning down Jan Koum in 2009 and then spending $19B to acquire his company even more ironic.
That may well be, but if you're considering hiring a guy who's an expert at writing package management tools, don't you put him on one of the specific subteams that needs that skillset? Surely it's something Google deals with?
The problem is that Homebrew is very different from the sort of package management tasks that Google deals with. The design goals for Homebrew include: make it easy for users, make it not require root, make it work on Macs, handle dependencies robustly. If he were at Google it would be Linux-only, he'd be using Linux containerization extensively, he'd be deploying packages to thousands of machines instead of one, it'd be a virtual guarantee that some of the machines would fail during the installation process, there would be little or no user intervention and if there was a user it'd be a trained SRE, and the installation procedure would probably need to be an order of magnitude more efficient than Homebrew is.
I don't want to take away from his accomplishments as a programmer - I use Homebrew too. But my point is that it's very easy to see "Good programmer, of course he should get hired" from the outside, while the reality is that it may not be all that similar to the tasks he'd be doing.
I failed my third google interview. My problem wasn't that I couldn't solve the problems. I just wasn't fast enough because I didn't spend 3 weeks beforehand training speed in programming brainteasers.
I'd like to present HN with a challenge. Come up with an interview process that matches _all_ of these requirements:
Objective - the process avoids human bias (this guy was in my frat, therefore is awesome).
Inclusive - someone doesn't need extensive past knowledge in a particular area of coding to do well in the interview.
Risk Averse - Avoids false positives.
Relevant - it properly tests the abilities needed for a coding job, and not irrelevant ones (like the ability to write an impressive resume).
Scales - this will be used for tens of thousands of interviews.
Easy-to-do - this will need to be done by hundreds/thousands of engineers, who would probably rather be coding.
It's easy to poke fun at what is perceived to be a flawed process. It's much harder to propose a solution that satisfies the above requirements. Google has done extensive research on this topic and has done remarkably well with it compared to other companies of similar size.
Xoogler here. I can't meet your challenge. IMO the very premise of a company-wide unified interview process for all software engineers is wrongheaded.
How can you make the interview relevant without knowing what the position is? I was asked the typical CS-type questions in my interview, but the team I ended up on required no theory.
How do you define false positives before you know what the candidate will work on? A superstar in one team will be a dud in others.
And let me add another bullet point to your process wish-list: gives the candidate a sense of whether they want the job. This is impossible when the interviewer is a random engineer from an unrelated team, unable to speak to what the candidate's work life will be like. A Google style process gives candidate very little information.
I would instead propose something very old-fashioned: teams hire for themselves. The usual reply is that this results in an "inconsistent hiring bar", but so what? Teams have different requirements and need engineers with different skills, so why shouldn't the hiring process reflect that? We are not fungible engineering units.
Create an online game/project/test that people must solve in order to get an onsite interview. The game can be customized for individual teams to have more appropriate domain challenges. Spend the onsite interview walking through the code the people wrote for that game. Devil is in the details, but that's the broad strokes of what you are asking for.
It may be hard to find a solution to the full interview problem. I still do not prefer whiteboard interviews; would be happy to code using my own laptop, projecting the session for everyone else in the room to see.
To be fair, inverting a binary tree is a pretty easy question. Google also tells you BEFORE you start the interview process that it'll be very data structure/algorithm oriented and asks that you please prepare (and take as much time as you want doing so). They even say that they want you to prepare because they know a bad candidate that prepares can look better than a good candidate that doesn't prepare - then want all candidates on a level playing field so they can make accurate judgements. All that being said, I still think that there is lots of room for improvement in the process.
I am dismayed by the way all the reactions on Twitter are piling on with outrage and/or relating similar experiences.
Inverting a binary tree is pretty easy. It is not quite as trivial as FizzBuzz, but it is something any programmer should be able to do. If you can't do it, you probably don't understand recursion, which is a very basic programming concept.
This isn't one of those much-maligned trick interview questions. This is exactly the kind of problem one may have to solve when writing real software, and though you may never have to do this specific thing, it is very related to a lot of other things you might do.
I run a small software company and I very likely would not hire a programmer who was not able to step through this problem and express a pseudocode solution on a whiteboard.
> If you can't do it, you probably don't understand recursion
No, I can't do it (don't even understand the question) but I certainly understand what recursion is, and can solve problems and make things work far more reliably than many of the more academic programmers I have worked with.
I'm a CS major, and I'm not even sure exactly what they're expecting. I mean a binary tree is just nodes with no more than 2 children. A linked list is a binary tree. Do they want a search tree? Do they want a self balancing tree?
Can you confirm that actually inverting a BT or solving other similarly probs would have been part of his future job at Google?
If so, they were consistent in disqualifying him in spite of his awesome track record, fame or "street cred" but if not, I can't really justify or defend this type of ceremonial or bureaucratic gotcha interview questions as they are just useless and can be abused by the interviewer to reject applicants they dislike for any reason or whim they might have at that moment.
What does it mean to invert a binary tree? I'm not familiar with this operation on binary trees. Does it mean to swap parents with child nodes? Or to swap siblings?
I have a feeling that the question is not really about whiteboard coding or solving graph problems. This is a blatantly ambiguous task. Maybe it was meant to force the interviewee to demonstrate how they communicate to the interviewer that they needed more information about the problem before starting.
Pretending you understand or blindly assuming what the interviewer meant is more of a red flag to me than requiring a few rounds of clarification.
In my opinion, an ideal interviewee would communicate that they don't fully understand the requirements and possibly offer a brief set of possible interpretations. Once the interviewer has clarified, my ideal interviewee would restate the clarification to demonstrate competence and verify their new interpretation of the requirements before proceeding.
In this case, it means to reverse the binary tree, so that you get the largest item by iterating down the left branch to the bottom of the tree. You would do this by breadth-first scanning the tree, swapping the left and right pointers as you go.
Oddly enough, Google shows me interview questions where "inverting a binary tree" means something quite different — for example, flipping it upside down, and making the left leaf the root, the right leaf the left leaf and the root the right leaf.
If this was really about "reversing" the tree, as you mention, the question seems more likely to address how the candidate approaches the situation. Like, he should start by making sure they both agree on what the question actually means.
Once that's out of the way, it seems relatively easy to come up with a naive solution, without having memorised any algorithms. It seems more like a case of brainfreeze to me, which can be sort-of fixed with practice (which in turn many candidates refuse to do: the dreaded "If I have to cram for the interview, I don't want the job" statement.)
So maybe he really wasn't a good fit for Google, despite apparently being a rockstar developer. Hey, startups need rockstar devs too.
I don't even understand why you would ever want to do this. You could just invert the input or output at the beginning or end (depending on what the binary tree is used for) for super cheap. It's not uprising that no one has done this in practice, though it also seems trivial (visit each node once).
Yeah I checked Google as well, but swapping children seemed too easy for an interview question. I'm wondering if it means restructuring the tree so a different node is the root. Trees have the property that any node can be the root and it is still a tree. Not sure just wondering if anyone had more info.
Interviewing seems broken to me too. I have spent the last few months trying to get a job out of college and everyone seems to be interested in how well you can regurgitate CS fundamentals.
They are seemingly less interested in seeing how you solve problems and work through the process of software.
I would be more than happy to see this process change, I am just not sure what it entails.
Devil's avocado: if they're truly CS fundamentals, then they should be baked into you good and deep during the course of your college education. It shouldn't be painful at all.
Especially as a fresh grad. Reviewing for a week or two if you've gone to a good school/actually did your work instead of 'consulting google' is definitely enough...
If you are trying to get a job straight out of college and you didn't have many relevant internships, there really isn't much to judge you on other than what you learned in college. This isn't a fault with the interview process.
Some companies give take-home assignments (small projects that can gauge how well you learn). I tend to find that these are smaller companies. You can always try there.
Also, the most important thing that they don't teach you in school is that getting a job is all about connections. Email some people that you've interacted with to see if they know of anything that might be suited for you.
I guess it depends on where you're interviewing and what their expectations are of you. Since you've just graduated they may expect you to be very junior and just want to make sure you have a good CS foundation. They should ask problem solving questions but it wouldn't be weird if they just focused on what they think you know.
I've phone interviewed with Google a couple times. I wasn't really interested in working there, but wanted to see what it was like. Both times, the people who interviewed me were decent, friendly folks and we had a good chat. They then dug into algorithm questions on topics I hadn't seen since my undergrad (I'm about 20 years into my career) and haven't touched since then -- though I've done a bit of algorithm work outside of that they weren't particularly interested in that.
I reached into my way-back machine and tried to derive some approaches where I simply didn't remember the answer (and I was very open about it). I made it to call backs both times, but they declined to move forward, probably because they wanted a younger person who remembered their big-Os off the top of their head, but I was okay with it. I told all the interviewers I had fun and I did.
Even if I had made it in, I'm not sure I would have taken the job at those times. So my lack of motivation ended up turning what could have been stressful into a fun look at their hiring practices.
However, I can see for people who are really dead set on working there, it can be a harrowing experience.
If you rate engineers on their ability to memorize something they could have looked up on Google in 5 seconds, what are you really actually testing?
If you're not at Google's scale, a take-home test that involves them producing a working solution to a problem in their own time, that you then expect them to be able to discuss, reason about, justify, and so on is a much better tool; even at Google's scale, where you might be worried people who copy answers off the net, have them bring the laptop they used in, and then get them to expand upon their solution.
All that said, I'd be surprised if that was the only factor at play. The Twitter comment itself seems to indicate a - uh - cultural fit issue. Additionally, and with no actual knowledge of the insides of HomeBrew, that a piece of software is widely used isn't evidence that the author is an excellent (or even good) developer.
Interviews break most people's intellectual context. Talky/show-me interviews are designed around interviewing MBA "how well can you present yourself" roles, but it completely fails to evaluate a technical person.
Doing a blind and "surprise me with a clever (or traditional) algorithm" whiteboard interview is a teaching skill, not a coding competency. You have to illustrate, explain, make your self vulnerable while understanding the problem, and work in front of someone while being judged confrontationally. It's not sane. (and glob help you if you don't wrap your entire brain around the problem in the first 5 seconds, then you're clearly subpar and are worth less than dirt even with your 15 years of experience shipping products to millions of users.)
Google is happy to have 1,000 nerd projects and only one thing that makes money. As long as they continue to interview smart people on technicalities instead of well-roundness and ability to actually contribute or move the company forward, they have no need to fix their insultingly irrelevant interview process.
Why not just take a chunk of code the candidate has written that was interesting and talk about it?
The main problem with interviews [imo] is it grabs stuff the interviewer is familiar with and throws it at the person in the more stressful position of being the interviewee. Its also [often] a very non-standard way of communicating. I don't know about you but all of my communication is via text or graphic, not whiteboard.
And, honestly, do you care more about the fact they can invert a binary tree from memory? Or that they can learn to in the next hour and implement it?
I think the best way is to give them access to a code base, give them 48 hours and have them submit a pull request for a feature. That way you can see that they can learn the codebase and implement the feature in their own time. During the interview, you can discuss their code and the reasoning behind the implementation details.
Demonstrating one small part of a real working software engineer's job, by solving an artificial problem in an artificial environment under artificial time constraints, while one or more people with no pedagogical training look on and (sometimes) interfere. The amount of information gained is less than the amount lost from having poisoned the entire rest of the interview environment.
Number of times I have had to invert a binary tree in my 25+ year career: 0. Number of times I have been asked to invert a binary tree in an interview: 0. What I would do if I had to invert a binary tree: look it up.
It may surprise you, but in the real world very few people get paid to find new primitive methods of manipulating fundamental data structures. Google may do a lot of that, but they are an unusual company. The problems a working developer is asked to solve are far more likely to involve higher levels of abstraction. The one I worked on most recently was coarse geocoding (find city/state) of free text. But a couple of decades ago I did sort of invent a use of BSP trees for searching RGB palette space (http://www.drdobbs.com/cpp/vga-palette-mapping-using-bsp-tre...). Well, probably not, but I still think I should get a cookie.
>Number of times I have had to invert a binary tree in my 25+ year career: 0. Number of times I have been asked to invert a binary tree in an interview: 0
Well, if you wanted to pull that card, it would have been nice to mention the sorts of problems you've worked on in those 25 years.
>What I would do if I had to invert a binary tree: look it up.
Unless you're already good at algorithms, it would net you a mediocre solution.
For e.g. You would only know that there are multiple ways to implement an algorithm when you've actually done the work dozens of times and noticed that some implementations won't be appropriate for you needs. Like with many things, its about having experience, knowing whats a good fit, and knowing why something similar isn't a good fit.
Certainly - every single time you choose an algorithm, and then decide on a particular way to implement it - you could in theory, implement each algorithm in 10 different ways and then choose the best one after benchmarking. But that would be a huge drag on productivity. And if you had to choose 5 algorithms for 5 different tasks then it quickly becomes a quadratic complexity time sink. It would be far better to just know via experience. Its kind of like in chess - the better players just KNOW that certain paths lead to less favourable winning odds. Well, novices do take those paths and eventually find out the hard way !
>> Well, if you wanted to pull that card, it would have been nice to mention the sorts of problems you've worked on in those 25 years.
Quite a range of stuff, unsurprisingly. I started on an HP3000 mainframe in 1976, if you want to go back to the very beginning, writing BASIC programs on a teletype or one of the two early CRTs, and storing my programs on paper tape.
Since then I've worked in DOS, 16-bit Windows, 32-bit Windows, 64-bit Windows, Ubuntu, iOS, and Android, using Pascal, 8086 assembler, C, C++, C#, javascript, Python, and Java. I've worked on applications in multimedia, telephony, banking, insurance, pharmaceuticals, cosmetics, health care, and I'm sure a few other things I've forgotten.
All of which will mean jack squat if, tomorrow morning, the most important thing I have to do is invert a binary tree. But I'm fairly certain I would be able to figure out what I needed to do, and I am fairly certain I could manage to implement it well. It's what we're supposed to be able to do, and if you think that having studied up on it so that you could pass a Google interview means that, a few years down the road when you actually need it you'll just whip it off the top of your head, then I think life may hold some surprises for you.
Another instance where silicon valley favors the young... he probably would've nailed this question if he'd been only a couple of years removed from school.
He also would've nailed it had he been given 10 minutes to do some research to refresh.
Silicon valley (and the numerous companies that mock the interview style) are testing for the wrong thing when they hire, then complaining about not being able to find good engineers.
You're given weeks to refresh your knowledge ahead of a Google interview. They tell you the basic CS fundamentals that are going to be covered. Binary trees are MOST ASSUREDLY on that list. They just don't have time during 45 minute interviews to let the candidate go on the Internet to look things up they should already have come prepared for.
Anecdotally, at a previous company, we tried an "open book" (i.e. you can use the web) interview policy for a few interviews. It was a train wreck.
I just don't get it why companies assume you can spend so much time to refresh and memorize topics just to prepare for an interview. Especially when this knowledge will only be used in the interview process and then forgotten about.
>> You're given weeks to refresh your knowledge ahead of a Google interview
Begs the question, doesn't it?
>> Binary trees are MOST ASSUREDLY on that list
Sure they are... and my intro to CS textbook was ~500 pages. I'll bet I could find something to trip up just about anybody, especially when coupled with the pressure of doing it in front of the class ^H^H^H people that have $$$$/power over you.
A project manager at Google was upset that my 'bot literally ran circles around theirs (it was 2010, Android based robots were just starting) and told me that I was just a hobbyist and my project did not exist.
So I gave him one of the spare logic boards (open design anyway). And wrapped my hand around his. And squeezed. And asked him, if it doesn't exist, why is it making you bleed?
He watched impotently as the people who had been invited for the presentation played with my robots and ignored his as two of his guys tried to get it to work.
I finished the two projects I was doing with Google and did not call them again.
(Before you downvote: Yes, there is some video, and I consider the small amount of pain I inflicted that day a kindness compared to the much greater amount of pain that an engineer is in danger of enduring if he says things like "This thing that is in front of me, it does not exist", especially if he works with big machines).
I get that a lot. Very occasionally, it's after "thanks for saving my life / my job". There's no shame in being an asshole but there is shame and dishonor in being insincere.
No, a psychopath would've done something out of revenge.
I was doing something to remind an engineer that the physical world is of paramount importance.
A bit of bleeding and embarassment in 2010 as a reminder that things that are there, are indeed there, is better than being pulped by heavy machinery that "shouldn't be there" but is anyway in 2018.
I'm sorry but Twitter is one of the few (if only) megaphones most people have to call out corporations for their actions. This is exactly the sort of thing that Twitter (IMHO) shines at, a platform to call down the goliaths. If I didn't already want nothing to do with working at google I would have been pushed further away by this tweet which is exactly what should happen. If google has the right to say no to someone that wrote an extremely valuable tool that 90% of their employees use then he has the right to inform the general public. Popular opinion seems to be one of the few things that can cause a corporation to change their minds or at the very least acknowledge the situation and he is expertly wielding it to his purpose. I applaud and support him in making this choice.
Playing devil's advocate here (because I, personally, wouldn't have done something like that), but I can see the insult. Here's someone with a very public proven track record (that they're fully aware of, if 90% of their engineers use his software), and they're asking questions like this. They're the wrong questions to ask in this case, surely? It's fair enough to ask them, but I can understand this person's frustration if that was genuinely the reason he hasn't hired (which we have to take his word for, since we didn't witness it ourselves).
From his perspective, I bet he's frustrated for the reasons he point out. If he never talks about it out loud, how would any one know? Keeping people silent about this issue is in the company's interest because they'll not have to really change, and they'll hire someone eventually.
I mean, I know I sometimes choke on problems I'm trying to solve in the privacy, quiet, and comfort of my own home on projects I really care about.
I don't know what went on in the interview but given what he said, I think I would be upset, too.
Why? He's under no obligation to Google. It's not like they hired him and he has to sign an NDA or be polite. He had a frustrating interview process and vented about it online, it's a pretty human thing to do. Why would that make him a bad employee?
Well, not that I agree with the sentiment, but corporations likely have incentive to hire individuals that are easier to push over and keep quiet as long as they have the skill set needed.
If you were a corporation trying to keep PR positive, would you hire someone that has shown themselves as an outspoken public mouthpiece and tip-toe around them to keep them happy, or just avoid the problem?
If the tweet is accurate in its implication that he didn't get hired because he couldn't invert a binary tree (honestly, I don't even know what that means) on a whiteboard, then I'd say the tweet is totally justified.
On the other hand, if it was a complex and reasoned decision that he's summarizing badly, then yeah, good call on their part.
And I'm pretty sure this is EXACTLY the type of guy you want to hire, I would strongly suspect writing mild mannered complaints about not getting hired on twitter has very little correlation with job success.
Well, he is the author of numerous widely used open source projects. It is a bit redundant (and useless) to give him a "homework assignment when he has such an impressive portfolio that speaks for itself and of which you can assess the quality.
To be fair, though I know the situation in question: Company A wants to acquire Company B, because their product integrates well and also adds value to a particular niche of their customers. Person is one of the lead developers of Company B's product, and together they have also open sourced one of the single biggest components of their product.
i.e. "You want to buy us because of this, and a decent part of this is on GitHub, running every day, but you'd rather not look at -that- code but -this- arbitrary homework assignment".
He is doing both Google and people who were rejected by Google a favor by pointing out that Google's interviews are not indicative of real world performance. He might have hurt his own chances a bit in the process, but overall this will undoubtedly have a positive impact.
For him individually, I might agree, but the bigger issue is how one of the largest tech companies is hiring this way. I don't think it's worth focusing on this guy's understandable outburst to the exclusion of that.
As large organizations grow, their workforce trends towards mediocrity. Google
* takes special care to counter-act this effect.
* researches their hiring/interviewing practices just as much as their machine learning.
* publishes their methodologies: https://www.workrules.net/
I feel the original tweet conveyed a bad attitude, was emotional, reactionary, and ultimately a bad career move on the part of OP.
In my younger days I suspect I would have done something similar. I'd like to think I would see the experience as a learning opportunity and be able to react with humility and maturity, but who knows? Hopefully I can think of OP and not tap the tweet button.
Really? Pretty much everyone recognizes that google style interviews weed out perfectly good people. What Max went through is just an example of one such obvious case. It's very much a case of the google hiring algo failing. Lot's of people would have no doubt that Max can cut it when it comes to iOS dev.
That's all it is. Now, if you are going to read "tweet conveyed a bad attitude, was emotional, reactionary," into a perfectly human tweet, holy crap you are judgmental.
>> ultimately a bad career move on the part of OP.
Not at all. I've done a lot of interviews and basically none of them required us trawling twitter. I think it would have to be something pretty heinous for me to not hire someone based on their social media crap. Definitely not something as mundane as this. This sort of hilarious cowardice about expressing feelings just makes me angry. At what point do we stop acting like these trivial, humanizing glimpses into a person are somethign that is a bad career move?
I had a big comment here, but I erased it. I think one story proves my point. When talking to google engineers one thing I noticed was that they considered youtube to basically be a joke. The reason why is that youtube has a messy python codebase. I asked them what they worked on while they were at google. They had rewritten an internal web portal for a support tool. From everything I can tell it was literally a mysql crud app.
If this is how success and failure are determined at google, it's no surprise how many of their products that people actually use come from acquisitions.
I don't know if I would rant on Twitter, but I would be as frustrated as well. Those 'tests' are very academic and I am not an academic person. I've not even officially finished high school. This test will not properly judge how well I can code or design software. I've been doing just that for 20 years now, and launched a few start ups, but I would fail that interview at the door.
I interviewed once for Google (at their request) and failed. For some reason they interviewed me for a networking position instead of a code one, so questions about TCP internals were not really my forte. I was just launching my second start up at the time and would have declined the job had I gotten it. I admit it does sting a bit to be declined - not just for Google, but for any position - even those you would decline yourself.
As others said, much more than 10% of Google's engineers don't even own an Apple machine. So, even if Google's Mac management team somehow uses Homebrew to manage the employees' machines (which may or may not be true: I have no idea, even though I used a Macbook in Google until recently for years), the percentage of Google engineers using that software is nowhere near 90%. The percentage of Google engineers knowingly using that software is certainly closer to 10% than 90%.
I think there is some validity to the general point, but I'm not commenting on that.
Just quibbling: I don't think anywhere near 90% of engineers use homebrew? Google development is done on Linux, and Homebrew is a Mac thing AFAIK. I have never used Homebrew.
Android development can be done on Macs but I doubt they use Homebrew. Certainly not for anything important.
It's funny because the guy actually thinks having built something popular equals being a good software engineer. Wordpress, PHPMyAdmin and so forth are all really popular but the code is shit and though it's used by millions of people, a _real_ software engineer will shudder looking at its source code.
Now, I have no idea what the code quality of Homebrew is, but just because he built something popular doesn't mean he should get a green light in every company. If Google is looking specifically for top-notch software engineers, they are probably filtering them very well with their practices.
Maybe they are only good on paper at that moment and don't have something like "Homebrew" on their Github, their knowledge is sufficient to perform work at Google. So why pick someone who has fame to his name, probably wants to get paid accordingly and thinks he is a hotshot because of his Twitter and Github follower count over someone who proved himself in an interview?
The first is not necessarily better than the latter.
I strongly believe that the best kind of technical interview is to talk with the person about things they have done in the past, go into details and see if they are telling you bullshit. If the things are interesting, at least somehow relevant to what the company is doing and the person knows what they are talking about, it's a good hire.
One problem is that only experienced developers can do these kind of interviews, because you need wide experience, be able to talk about various technical topics and tell whether the other person is telling you stories from their own experience or some quickly learned facts.
It's funny, but the best experience I had interviewing at Google and Amazon was talking with the managers.
Was it really because he couldn't do the problem, or was it that he didn't handle himself well in the interview? At two different interviews I was given logic puzzles just so they could watch how I went about trying to solve them.
That experience doesn't mean that's just what they're saying. It could mean in those cases the person a) didn't solve them problem, and b) didn't demonstrate an approach to solving they problem they were looking for.
This just gets back to the question of whether you are hiring based on interview skills or coding skills. If someone has shipped code that shows high coding skills, why would you reject them based on interview skills, if it's a coding job?
You could still interview an experienced person. On the technical side, you could see if they're familiar with your specific stack, and know how to handle version control etc. Aside from all that, you can make sure they share the team's goals, are willing to use version control the way the rest of the team does, stuff that's not about skill.
That is the killer right there. The 23 year old recruiter responds to your rejection with: "The interviewer thinks you'll be better if you get another 6 months experience. Keep practicing! We'll loop back around to you next year!"
Thanks, I've been doing this for 15 years. I'm sure another 6 months is all I need to meet your delusional standards of ineffable ability.
Personally I don't really care about Google's hiring process. It's unlikely I'd ever want to work there anyway.
What does bother me is that other companies, who are not even in the same league as Google, start to copy their hiring process.
I remember interviewing with a digital ad agency a few years back and I swear, these guys thought they were Google. The number of academic trivia questions that came up, it was ridiculous.
In a way, I think Google has done a lot of harm to the industry in general by making others believe that everyone should have a hiring process like Google's.
I've been there as well. I interviewed at a design agency a while back. I nailed all of their puzzles pretty easily only to get there and realize I was going to be doing Wordpress hacking and other CMS work from 2010. I left after a few months because of how trivial I realized the work would be in the long term.
On the exit meeting it was relayed to me that they were having trouble finding people because no one could pass their tests and I was beside myself because I couldn't understand how they would expect someone with that technical ability to want to bang out Wordpress sites all day while there are 100s of people who would love to do that job and be very successful without ever even knowing what basic recursion let along the stuff they had in their test. Bizarre.
i had a similar experience with ita software, later acquired by google. i'd submitted a solution to one of their puzzles (which was actually very close to their business) which exploited a symmetry in the data and my solution produced results significantly better than anything else that they'd seen (per the engineer that managed that puzzle)
interview was brutal - lots of whiteboarding very artificial problems totally unrelated to the business and i just couldn't get excited about it and didn't end up getting an offer
You just have to know the basic data structures and some algorithms for them. Liked list, binary tree, Hash map etc...
In the worst case, set up the data structure, then derive the algorithm. Do this in Java FWIW and make your life easy.
This is like knowing math and/or stats and applying it to a word problem.
Actually my pet theory is this: Interviews for experienced folks are more meant to keep them in their current companies rather than to filter the incoming new ones. This acts as a gentleman's agreement between the giant companies to keep their own talent pool semi-intact :) /s.
I mean imagine the amount of extra work someone has to put in to start interviewing. Take a break from your current work, Prepare your CS basics again, Prepare from interview question dumps online, read up / analyze everything the new company is doing and form reasonable opinions, practice white board coding / coding without an IDE, allocate time for any homework projects given, Psych yourself up if you are introverted etc. The alternative is just to stay in the current role and hope stuff gets better. 90% of the folks I know choose the alternative over the dehumanizing process of interviews. So many folks I know are good engineers get chewed up in interviews (both in my current company and elsewhere) because the process is pretty cooked. We are trying to see how this can be improved, but yeah - I just keep going back to my pet theory :)
I do agree with one of the commenters here though: At one point your resume should speak for itself. These are the kind of problems I would like LinkedIn to be solving instead of finding ways to spam me with recruiter deluge.
It's interesting the amount of hate and either rumors of bad experience or bad experiences directly. I interviewed for an SRE position last September and they were clearly trying very hard to make it a good experience no matter the outcome. I flubbed a couple of questions and they didn't make an offer, but the impression that they cared about my experience as an interviewee lasted. I wonder why my experience was so dramatically different from many here.
I've been invited to interview at Google three times. And they've declined to hire me three times. The last time I interviewed there the quality of the people that interviewed me was much lower than the earlier two times. I was still rejected, but I felt much better about working somewhere else.
I'm sure Google is still a great place to work, but its reminding me more and more of 1999 Microsoft. In fact the similarity is spooky.
Firstly, you're not entitled to any job you want just because you wrote Homebrew. If you accepted an interview with Google, then you accepted the fact that Google will judge you based on your problem solving skills, just like every other person was asked.
Secondly, I don't think this is a hard interview question; it's certainly fair.
Did you expect to be asked knowledge-based questions that Google knows you're already good at? Questions specifically geared towards you?
Or questions where Google can watch you solve a problem and be comfortable with the fact that you are able to solve coding problems?
Did you think Google would hire you to write Homebrew? Or solve problems on teams Google has?
That may be somewhat true, depending on how crucial and dependent Google is on Homebrew. But 90% of Googlers don't rely on Brew for work.
It is just a figure he made up to make a point about how popular his software is. Using his software outside the context of our jobs is no means to justify a hire. He should go through the same interview process as 90% (much higher than that actually) of Googlers.
It seems that almost everyone here knows better than Google how to hire employees for Google. Given that you can see why it is trivial to see through hours-long hiring committee decisions in just two seconds.
Edit: as pointed out by others, the hiring decision probably does not take a few hours, but under an hour. Still, the point is valid.
If their goal is hiring from industry, as opposed to from schools, I think I could credibly defend an argument that they don't.
(I think what they do now makes sense if they want the top of their funnel to be comprised mostly of recent CS grads, and I think that industry people with really high profiles, or that internal people really want, get to skip a lot of this evaluation.)
I have a lot of respect for Google (how could you not). That doesn't mean they can't be a bit clownshoes with recruiting.
Well, this thread escalated quickly! Am I wrong in my understanding that when a company rejects they don't specify why and hence "rejected due to failure to invert binary tree" may be a guess here?
As Google bragged in 2013 that it managed a Mac fleet of over 40k and with a workforce of 55,419 in Q1 2015 (not just engineers, 2013 numbers were about 10k engineers), that's 72%+ of Google's workforce using Macs.
Homebrew is at least one of the best package managers for Mac. I would be very surprised if it was not at least near the 90% mark...
I mean - what's the point of spending 3-4 years in an Academic environment that proceeds to then test and grade students on exactly how good they are, at the time - then only to perform the whole process over again some number of years down the road, with fuzzier results?
Seems dumb to me.
I've worked with people who could likely do very well on algorithmic tasks - (of which most software projects require precisely zero) - but actually deliver something of use... not so much.
When I used to interview people (I wasn't a manager, but I was senior enough to be entrusted to the role), I'd just ask about projects they had placed on their resume (to get a feel for their contributions) and then the rest of the interview would be focused on what the job was and how that matched with their career goals, why they thought they'd want the job, that sort of thing. The latter part was a bit harder because people are naturally defensive during an interview, so they can't be like "well I want an entry level web developer job so I can parlay this into something better in two years" (which is, IMO, totally an acceptable answer), but you can generally politely get the idea. Maybe I'm weird, but I just sort of think interviews should be more about determining fit than giving someone a lie detector test.
I get the puzzlers or whatever for a phone screens (quickly weed out people that are obviously unqualified), or if you're hiring someone junior who doesn't have work experience, but if you're at the point where you're bringing someone in you probably think they're minimally qualified, so it should really be about determining if goals are aligned IMO.
I like the spirit of this, but he may well have not been hired for a variety of other reasons besides this -- including how he attempted to solve the problem or how he handled not being able to solve it on a whiteboard in an interview.
I hate whiteboard programming questions and I don't give them when I interview someone - I give them a laptop with 10 different languages on it, and some data to munge -- I think it's a pretty decent thing for both parties.
I, for one, agree with this kind of hiring process.
From my own experience - people that do well in such interviews are good generalists. On their own they will start discussing performance improvements and ways to parallelize the solution, it's a pleasure to have such an interview.
It's about enjoying problem solving and willing to keep your brain fit. It has nothing to do with memorizing solutions to some existing set of problems.
The people vilifying Max or saying "duh you didn't get hired, Google requires awesome people" seem to have a totally warped sense of exactly what Google engineers do day to day.
Blows my mind that there are so many people defending this (well-known and pretty much taken as a trade-off) lapse in the Google hiring algo and instead making it seem like Max's fault.
It is not. IMO it's a pretty ballsy and idiotic thing to do. That's partly why I am not too active on Twitter. I have a lot of controversial, unpopular opinions that I wouldn't want a potential employer to get a whiff of.
Google really does only hire individuals who are strong in theory.
Maybe we are jealous. We wish we had the brains of the people getting into Google. I can say personally that I envy these people.
The fact that they don't mind being treated as numbers maybe says something about these people too. They are cold. Their ego must be pretty big too if they make it into Google.
I remember a story from college graduation. A friend contacted an alumni from the university. The alumni worked in the semiconductor business. One of the questions he asked the alumni was: "How does he select a great employee?"
Alumni's response that it is exceptionally tough. He shared an anecdote about one of his best hires.
The alumni wanted to test the interviewee's knowledge in different areas. He asked a question on diodes - it might not have been diodes, but for the sake of the story let's stick to diodes. The interviewee replied: "Hold on, I am not one to know about it."
I have not worked at Google and I do not think I'd pass its interview process. It is unlikely that I be diligent enough to make Homebrew. Nevertheless, I am inclined to the idea, that being knowledgeable in all tested areas would not reveal the personal fit necessary to make a great team.
It seems that google wants to have code monkeys instead of creative software engineers. This is a common problem of big companies. IMO it is one of the reasons they get stuck with innovations.
Of course also the interviewers don't want to hire people which are smarter than they are because of their own career.
As someone who struggles to learn by rote as opposed to learning by practical means and has been both hired and declined by the Google recruitment process. I can't help but agree with his sentiment.
The recruitment process (at least for experienced engineers) should be little more then "can I work with this person". The 6 month probationary period that follows the hiring process should be used for "can this person do the job well". But that's just my experience, and it seems to have worked well.
Regarding the same academic questions everybody gets asked in every development interview, I feel Einstein said it best with "[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."
Google is about monoculture (certain type personality) - and from their business perspective it seems that approach works. Why to change it?
If they try to invent something new or in different market they might need different type of people but as of now ads business is cash cow and they would be crazy to try change it.
Without commenting on whether this is a good interviewing strategy, surely the point is to sacrifice some potential good hires in favor of definite good hires. In other words, you might be able to write pretty good code even if you can't solve problems on a whiteboard, but, given a choice, why wouldn't we just choose the people who can do that, too?
I think the stated philosophy of interviews like this one is that a false positive is worse than a false negative. Every single one of the responses to that tweet either misses that point or sounds like little more than defensiveness in the wake of a bruised ego.
You might disagree with that interviewing strategy, but you're not addressing it directly.
More or less agree with this. I'm also a Google reject (didn't make it past the phone interview). I didn't take the rejection personally. I don't see how the interview process could be drastically improved. They get a lot of applications and they need some way to filter - there is a standard and it has to be met. With the sheer amount of applications that Google gets it's a virtual guarantee that there will be a subset of people taking the piss regardless of what the interview process is like.
I don't doubt that the engineers who manage to jump through all those hoops are sensational. Personally in the end it just dawned on me that I didn't want to work at Google that badly.
The whole Twitter exchange is a pitiful sour grapes circle jerk, and I'm surprised that it's provoked such a massive response.
> why wouldn't we just choose the people who can do that, too?
I agree with your overall point (why not both?) but how does the interviewer know they can do both if they are only tested on their ability to solve problems on a whiteboard? I don't have a solution (that scales) to this problem but I tend to agree the types of whiteboard problems typically seen in interviews are a bad way to identify good developers.
This guy sounds like a tool. Sure, he's accomplished, but his website and linkedin are dripping with self aggrandization. "Splendid Chap" -- cringe. My hunch is that they didn't hire him because he didn't seem like a cultural fit.
How can we see if this technique works? There are two methods try to know something: deduction and induction.
First a little deduction. Let's try to be explicit about the theory behind this technique.
It's safe to assume that the job will NOT consist mainly of cranking out binary tree inversions on whiteboards while being watched over. So obviously we're hoping to make a correlation with something else. Assuming the candidate was not tipped off and learned this particular puzzle, perhaps we are correlating to an ability to rapidly create novel solutions of long-solved algorithms without reference tools.
But is that what the new hire will be doing? Probably not.
We could continue down this path, identifying ever more removed correlations until we get to something that the job actually demands. This probably involves solving hard problems like naming things. [1] But by now our theory stands on pretty thin ice indeed.
In any case, all of this deduction is theory making. It's not knowledge until we attempt to falsify [2] it via induction. The human mind constantly induces hoping to verify our deductions. We reason, observe, conclude and repeat. We're good enough at it to survive, but that's about it. Lucky for us, science came along. Today's technical hiring is at best alchemy.
A interesting company called TripleByte [3] is trying to apply induction (first for YC companies). They specially shun on white board coding and puzzle solving tests in general. I will be interested to see how they fare and whether their learnings are adopted more broadly.
It is pretty well known there are a lot of false negatives in the hiring process since it is so much worse to make a bad hire than it is to not make a good hire. Sounds bad and it is, but no one has a better solution than try again in a year.
IMHO, I don't think it requires any practice to be able to invert the binary tree. It is so trivial that it only requires a very basic level of programming skills. I agree whiteboard is generally broken, but for this particular case, I don't think Google is doing wrong. We can think another way, if some company hires people based on his reputation instead of the ability of doing actual work, I don't think it will survive. In this particular case, you just didn't show your ability of doing actual work, that's it. I am glad to see that Google prefers ability of doing actual work to reputation.
In my very limited experience? None. They just trust the company they acquired to have filtered you properly. They do ask for references (like academic records and so on) but that was about it.
Without discussing too many details, I believe the issue with Google's recruiting process is it was designed when the company was smaller and it follows the philosophy that anyone that goes through the hiring process should be ready to be thrown into any of the many Google projects and be able to function immediately. That's not strictly true anymore.
You have some divisions that are extremely hardcore or require very good knowledge of a particular field (think Google Cloud Platform vs. Android Kernel vs. Chrome vs. Search, all completely disparate projects), but there's also work for people that don't need to hold a PhD from MIT (think front-end development.)
Hmm, it depends a lot on the size/type of company and reason for acquisition. If it's closer to a acqui-hire where the employees of the "acquired" company cease development on whatever they were doing and eventually just get staffed on a Google project, then they will MOST LIKELY do technical due diligence on each team member. It's common for only part of the team to get an offer to join.
Good engineer you didn't hire is not much of a cost to the company (other than resources wasted on hiring process and perhaps some bad publicity).
On the other hand bad engineer will stay at the company, lower standards, damage morale and set bad precedent to other engineers.
Being engineer myself, I feel much more motivated working in an environment where you can just assume, even before meeting, that the other person is intelligent and motivated. You trust hiring process to filter everybody else so you don't have to subconsciously distrust every person you meet.
I dont want to be an ass but how do you not know how to invert a tree? Anyone who knows how to write a tree and traverse it should be able to do this. If you ran out of time coding it then that's different.
Not even. If you know what a tree is, and you've written a couple of recursive problems on trees in your life, then you know most of them are approximately 5-6 lines of code.
If you're spending 45 minutes writing 5 lines of code, it is not definitive, but certainly a red flag.
Nobody in this thread has even been able to define what inverting a tree means. (Reversing or mirroring? Sure.) My search for how to invert a tree led to a bunch of fairly hairy academic papers.
An Indian eCommerce company wanted to test my mathematics while interviewing me for a VP of Marketing role. I had to tell them I won't fit into their company culture, let's not waste time further.
We're trying a different approach at Sourcegraph. In addition to looking at a candidate's prior work in open source if available, we ask them to complete tasks that approximate the job as closely as possible (i.e., coding on a computer): https://sourcegraph.com/blog/programming-interview
Would love to hear people's thoughts and feedback!
Yours sounds like an approach that measures how well someone codes in a vacuum, instead of how they operate on a team. It very much skews the results...
Not to mention for a qualified professional candidate, it feels an awful lot like you're asking them to work for free.
In addition to asking them to write some code, we also have each member of the team interview them onsite to get a sense of how they'd interact as a member of the team. The challenge does take a few hours, which is longer than a typical phone screen or single onsite interview, but because it lets us focus on getting to know the person onsite rather than go through a gauntlet of whiteboarding interviews, we think it actually saves time for everyone and is a win-win. Obviously, every candidate is different; we think of this not as a rigid template, but a better default option than whiteboard interviews. Thanks for your thoughts!
> The code is reviewed by the interviewer
> but probably never run.
This is what surprised me during an interview with Facebook. I tend to write a little code, run it to test it out, write a little more, test again, and so forth, you know, rapid iteration or whatever the fancy industry term is these days. The interviewer gave me these silly little shell scripting problems (silly in that they ought to have been easy and clearly had nothing to do with real life work) but instructed me _not_ to run the code. How the heck am I supposed to know if I've solved the problem? How will I know if I even have the right approach? I don't consider myself an expert software engineer and so probably not a fit for the position, but that style of interview definitely hamstrung me.
For what it's worth, being able to run programs "in your head" is a very common skill required of Computer Science undergraduate programs, where you're required to write programs of medium length on paper during exams. You should be able to write out, follow along with, and reason about the correctness of a program that can fit on a single piece of paper without having to run it. Programming hyper-iteratively is not really a good thing, especially not in environments where rebuilds or test runs can potentially take hours.
Another reason not to have candidates run the code is that they tend to get really hung up with debugging trivial errors. I've conducted a fair number of interviews either way, and the white board interviews were usually more pleasant experiences for all parties than the interviews where the interviewee was expected to execute the correct solution in front of me. The latter almost requires giving them some kind of web or library API access, which then just makes the distractions worse. I don't want someone worrying about what the exact name of a sort function is; that's not what I'm trying to evaluate in an interview.
i've done three over the years, complete and utter waste of time.
i also had some wierd binary tree questions when i interviewed at yahoo, was a total turn off as i was interviewing for web/front end related job. which probably would not have used any of this type of logic, ever.
The problem with google interviews and tech interviews in general is that it is almost impossible to capture what makes a successful candidate in a couple of mini interviews. They don't even pretend that what you do in the interview is what you will be doing in an actual job there. Most of a developers time is spent in meetings, understanding their problem domain, writing documents, or reviewing other developers documents.
This was years ago but a google interviewer asked me a make a complete copy of a directed graph (i have to do cycle detection). I was given 45 mins total and I failed. I cursed myself for not being good enough. I haven't forgotten it yet.
Google, if you have really smart people working for you then make a new problem solving question for each person you interview!
The current interview standards highly promotes memorizing stuff which is pathetic.
I wonder what an interview process at Google with Linus Torvalds or Theo de Raadt would be. I take for granted that the interviewer would not had a clue about their accomplishments.
At least he didn't get put off because his CV had the wrong font. It was actually a technical question. They probably have binary trees that needs to be reversed everywhere in Google :P
I don't know, inverting a binary tree seems like a pretty easy task. If I were hiring a senior developer (to code as a primary task) I think it's a reasonable fizzbuz.
He sure has an awful lot of his self-worth wrapped up in whether he gets a job offer from one specific company. It reminds me of being interested in a particular girl in high school.
At a certain point, you learn that there are other jobs out there, and maybe the one with the biggest name isn't the best one. I certainly wouldn't be the least bit offended. Not when the market is flush with high-paying-jobs-a-plenty, particularly for someone with his background.
I took my google interview as a gift from them to me. It showed me that I was mistakenly interviewing to become a cog in a terry gilliam-esque corporate machine, and that made me think hard about my path in life, and what i really wanted out of a career.
I know this was supposed to be a joke, but he can't retroactively change the license for the current released version. Any license changes will only apply to future releases.
Last week I walked away from a Google offer that included a 70% raise. A large portion of this was a rather dehumanizing interview process, along with the realization that the process doesn't select for people I want to work with, and weeds out most people who I do. I managed to do just enough in my interviews to squeak through, but in doing so realized that it wasn't for me.
Walking through the cafeteria made me feel like I was back in CMU CS again, in a bad way.
I think you may have left with the wrong impression. If you ask Googlers or Xooglers alike, most agree that the people here are actually the best thing about Google. Like anywhere else, there are some bad apples, but compared to most other places the people here are on average more talented, nicer human beings and more helpful. Certainly compared to your typical startup or other BigCo.
In my nearly 3 years here, that is my experience as well. I've also spoken to many engineers who have left who lamented the quality of their fellow engineering talent at their supposedly 'hot' startup, compared to their former team at Google. Or having to deal with way more unprofessional (or crazy) management, prima-donna teammates, etc.
As far as my specific interviewers are concerned, I liked 7 of the 8 as individuals, which is great. What I didn't like was the company felt like a monoculture. Same schools, same majors, same pre-education background. Everybody looks the same, dresses the same, etc.
The process, on the other hand. Ugh. I have zero respect for Google as a company after that.
It starts with the standard phone screen/day-long onsite/hazing ritual. Then come phone calls with teams, and teams saying "yeah, we want you", and me saying "sure, sounds good". The recruiter basically said "time for the higher-ups to rubber stamp this, and here's the $$ to expect". Someone up the chain said "well, we're not so sure, let's haul him back here for another round of onsite interviews". Which I did, it went through the same process, and the response was "well, maybe not you for this role, but lets set you up with more teams".
All of this finally goes through, and I get an offer. Then there's a negotiation that goes something like:
Me: I'd like 4 weeks to think about it while a couple of other applications come back (keeping in mind they've dragged this on about 2 months longer than it needed to be).
Google: You get 2.
Me: I'm at a conference week #2, but I'll do what i can to get a decision to you Friday.
<Fast forward to monday of week #2>
Google: Have you made up your mind yet?
Me: I'd like to look at my options, and I'll get back to you COB Friday
Google: It's really important that we hear beginning of day Friday
<Fast forward to wednesday>
Google: Have you made up your mind yet?
Me: No. One of the options I was looking at is now off the table.
Google: So WTF are you waiting for.
Me: The other options
<Fast forward to Thursday>
<Phone rings while I'm at the conference>
Me: You can't pay me enough to deal with this.
Maybe no individual involved is a prima-donna, but the ego showed by the company as a whole through the recruitment process is stunning. It felt like I was dealing with the star quarterback who never considered that when they asked someone on a date, they might get turned down.
In my experience pretty much everyone is excellent, apart from the lower level non-engineering managers. These tend to be grads from top schools who have zero previous work experience. I encountered at least three or four in my time at Google who were just out to prove themselves and get promotions and regularly threw their teams under the bus.
>Really smart people who are really insecure about their intellect?
Condescension. Condescension everywhere.
It is people who are at the top of their game that are the nicest. My old CEO, who is head of a company everyone here probably knows about, was such a chill and friendly person.
Maybe this guy wasn't quite arrogant enough to work at google, I mean he seems pretty arrogant, but I think you really have to be extremely arrogant and up on a moral high horse to work at google.
If you wanted to work for an organization where everyone likes to show off their skills to one another in the interviews, you'd have gotten the job, and you'd be one of them.
The best interviews I find are like a first day of work (but unpaid). Your experience and skills are established by resume and portfolio. The interview shows whether you can work with the team and wrap your head around the org's problems. If you're having to show off- well, that's how your work will be, too.
Google's interviews convinced me, years ago, that there's no way I'd ever want to work there. And that feeling hasn't changed one bit. Much like FB, it's an org whose coding needs are really pretty trivial and the real work was done and finished a long time ago (but there's plenty of need for debugging, egos especially). If you want to work there and surf the gravy train, cool for you.
> Much like FB, it's an org whose coding needs are really pretty trivial
I was with you till riiiiiight there. Google isn't just a search company anymore they're working on lots of very interesting non-trivial things all around the company.
And Google engineers aren't the shit either. Their Java libraries are large and unwieldy. They would learn something by taking an example from the apache libraries - clean and straightforward, focused and small. I hate working with Google code.
Maybe he was applying for the role of Lead Binary Tree Inverter. The astute will notice that he repeatedly ignored opportunities to confirm or deny that the position for which he applied was indeed, Lead Binary Tree Inverter.
Google Interviewer: "so, how would you do X, Y, or Z?"
Ruby Developer: "errm.. gem install X, gem install Y or gem install Z?"
Google Interviewer: "next!"
Am I missing something? Are we talking about getting a left-to-right mirrored version of the tree? If so, I'm amazed. This is a technical community, and people who presumably know how to program are moaning that this is some kind of "academic" question? Are you guys for real?
Disclaimer: GoogleFanBoy here, feel free to ignore or downvote.
So, I've interviewed with Google twice. Once was 3 years ago, the other was like 2 weeks ago. They contacted me. The way I see Google's interviews is like referee in Football(soccer or "Futbol"). Sure, you need a certain amount of skill to play in the World Cup but you winning or losing can, and often enough does, come down to a controversial referee call. You end up losing out to a team that did a handball - https://www.youtube.com/watch?v=-ccNkksrfls
, but that's just how it is. What makes me like watching soccer so much is the same thing that excites me about Google's interview process. Yes, there is heartbreak and anger. Just like World cup fans get angry when their team loses because they were denied a point for an off-sides call even when the player was nowhere near off-sides.
--- Is Google's interview process fair? Nope.
--- Would I subject myself to their futbol-referee style of judging candidates again? You bet.
--- Do I think they should make their process more fair? Nope, let the drama and _justified_ rant posts continue. Just like I want the unfairness in futbol to stay as is. I was one of the people against putting the microchip inside the ball to know for sure if it crosses the goal line. I want the drama of a ref having to call it and sometimes getting it wrong.
I know people, especially on HN, love reliable & repeatable. I do too, except when it comes to dealing with humans.
At a certain point, your resume should speak for itself. The fact that experienced engineers with impressive resumes are put through these types of interviews is insulting and frustrating to the interviewees.
Succeeding at these whiteboard questions requires weeks of preparation. You need to practice, practice, practice. After enough practice, you are pretty likely to pass. So ultimately, it is more of a test of "how much do you want to work here." If you care enough, you can pass. That said, these types of interviews do favor fresh grads over experienced programmers (you have algorithms and data structures fresh in your mind), which means that they are flawed in IMHO.
These types of interviews work really well for the "I got 1600 on my SATs and went to {insert high profile school here} crowd" There are books out there just to prep you for Google interviews I see these as very similar to SAT test prep books. I'm not so sure Google is really interested in hiring the best engineers but rather a specific type of engineer.
Think of the problem from Google's perspective though. At some point, you have tens of thousands of candidates and you need a system to quantify how good they are. Further, it's reasonable to have false negatives (people you don't hire that should have been hired) but really bad to have false positives (people that you hire that you should not have). Together, these boil down into the de facto whiteboarding interview process.
121 replies →
People have previously mentioned hallway discussions at Google routinely devolve into bragging about SAT scores and GPAs.
Nothing says Google must accept sub-par technical people, but Google fails to realize you don't have to be the top 0.0001% in absolute algorithms intelligence to do great work.
Google's basic theme seems to be "you must be low latency ultra smart in our narrow interest areas" to pass an interview (or well-connected in other ways to lower scrutiny), but Google's main problem these days isn't lack of smart people — it's lack of projects with meaning and lack of how to organize smart people into anything resembling a coherent world-moving force.
In The Plex is great read for insight into their entire process. Basically, Google is run by people who have never been told "no" to anything in their lives, so they continue to think they are the best at everything until reality forces them to reconsider their delusional assumptions ("montessori naivety").
18 replies →
> Google is really interested in hiring the best engineers but rather a specific type of engineer.
I think you made an excellent point. It seems that outside a tiny minority of world-class experts, Google is more interested in hiring interchangeable workers.
4 replies →
Exactly. I see it as a tacit admission that you are effectively a cog in a wheel if those are the kinds of questions they are asking.
I know some people get frustrated by those kinds of questions, but I'd just see it as a reverse weeding out process. If you still want to work at (insert company here), just build something valuable and have them acquire you. At that point they'll acqui-hire you and you'll leap frog all the people who got in because they had Knuth books memorized.
Really? Being able to solve basic CS101 problems requires some sort of privileged upbringing? I grew up poor - my family lived off food stamps for a while. This stuff is easy. I find it disgusting the level of entitlement swept throughout this thread. Oh Google HAD to give you that job, it was yours and they stole it by testing basic skills.
You know, there is something to be said for someone who has a good product sense, but not good developer skills. They sound very valuable, so why are they applying to a developer position? Just because you are unqualified for one job, doesn't mean you deserved that job, or that you're worthless.
Go do what you're good at.
1 reply →
I suspect the issue is that programmers right out of college are strong on testable skills (like how to do X to a linked list) and weak on experience-based skills that are harder to test (like how to keep projects under budget or how to manage technical debt). Whereas veterans naturally tend to be the opposite. And hiring processes naturally tend towards what's easier to test.
As such, the best approach to these interviews might be to say, "Look, I could take a stab at that algo question, but I haven't touched that stuff since school, and if I needed it I'd google it. It might be more productive if we talked about what I've been doing day-to-day for the last ten years to ship successful products, because that's the main value I can bring to your company."
Not just books. There are even courses: http://Interviewkickstart.com.
I aced some data analyst interviews fresh out of grad school. A lot of the questions were excel and probability questions, which I used to teach. Now, I have more experience and knowledge, but I would be much slower in those interviews.
>not so sure Google is really interested in hiring the best engineers but rather a specific type of engineer.
Any mature company should focus on finding those specific candidates - the ones who fit the company and specific team, on several dimensions beyond standard skillsrequired for the job. That's someone who will be called the best candidate in that specific company. And it's absolutely natural that s/he won't be considered "best" insome other company.
I interviewed @ google several years ago as part of some due-diligence they were doing to decide if they wanted to acquire the startup I was working at, [redacted].
It was several hours, with many interviewers one at a time, of academic exercises. Some I could see were relevant to some of Google's projects, but that wasn't the emphasis- it was very much a "how much do you remember from CS courses?" (with a few exceptions- one had me explain why a snippet of C would crash- something more what I would expect a senior engineer to know that was more practical-oriented).
I _think_ I did pretty well (again, it was part of a bigger due-diligence-- another story altogether, so I never heard), but in the end I was struck by the fact that (a) not a single interviewer had looked at or asked about any of my publicly available work, and (b) not a single one even asked something along the lines of "what are your strengths / what do you think your contribution would be" (or weaknesses, for that matter, but that seems less important).
Of course, one of the other guys I worked with lucked out and got interviewed by one of the paypal-mafia, and ended up with a reportedly very stimulating hour long discussion about actual work, strengths, and actual situations that one would hypothetically need to handle at google.
Your previous work is what gets you in the door, but interviews at Google are explicitly structured so that you need to demonstrate competence right then and there.
And ye olde "what's your greatest strength/weakness" question sounds like a terrible way to judge an engineer.
2 replies →
> not a single interviewer had looked at or asked about any of my publicly available work
It could be dangerous. Let's say you explain some interesting techniques you used on your GPL'd software and a Google product starts doing something suspiciously like what you showed them. You may even sue and end up making their source public after some litigation.
1 reply →
Replying to myself- too late to edit. Some other comments in here lead me to believe there would be experience-related questions ideally these days. Again, my experience was a few years ago :-)
"How much do you want to work here?" is probably a better predictor of your performance on the job than your experience is. I don't see the problem with that: IMHO, the fresh grad who really really wants to be there should be hired over the experienced veteran who's just putting in time. I'd like to think that an experienced veteran who really really wants to be there would also get the job, though, over both of the other candidates.
> At a certain point, your resume should speak for itself. The fact that experienced engineers with impressive resumes are put through these types of interviews is insulting and frustrating to the interviewees.
Only to bad interviewees.
You'd be shocked to hear the number of impressive résumés I have seen who turned out to be absolute no-hires after 20mn on a white board. By "absolute no hire", I mean the kind where some of the interviewers tell me in the debriefing "I will quit if we hire this guy".
Not all excellent engineers have impressive résumés but they all share a common characteristic in my experience: they all really enjoyed working on the problems I asked them to solve on the white board. I even had some of them be disappointed when we ran out of time because we were having interesting conversations about the problem.
> You'd be shocked to hear the number of impressive résumés I have seen who turned out to be absolute no-hires after 20mn on a white board.
Hmm, at least in my experience it's really quick and easy to tell if someone is bullshitting about their resume or not by simply talking about the different projects they worked on. I know a few developers who didn't go to a 4 year school so they don't know all of the correct terms or algorithms (one even interviewed for Google and failed) but I would hire them in a heart beat because they are really awesome.
I still feel some sort of pair-programming exercise or something similar is better than simply trying to solve problems on a white board. Unless you're in a SCIF you're going to have access to the internet to refresh your memory, etc so I've never found utility in asking academic questions. In fact I've had a few people who could pass the academic questions but couldn't build an application to save their life so I don't even bother anymore.
2 replies →
>By "absolute no hire", I mean the kind where some of the interviewers tell me in the debriefing "I will quit if we hire this guy".
That's just a self-reinforcing selection bias - you hire people that are good at these kinds of problems/enjoy them - you filter out the rest by default and it becomes ingrained in the culture - it doesn't say anything about the suitability of the candidates you filtered out. If you said "we hired a guy who had a great resume but he couldn't do algorithmic problems, turned out to be a bad fit for the company" - that would still be a single data point but at least it would be relevant.
I would agree with what you said if you replaced resume with reputation. Anyone can fill out a nice resume.
One of the challenges with Google's interview process [0] is they are very worried about hiring mistakes, and also know that the process is very noisy. As such, they interview a tremendous amount of people for hiring. In addition, they've found it more efficient to just keep a high bar (missing many good hires to keep out 1 bad hire) than to conduct more than 5 interviews.
The one thing I've wonder is - if they want the top 100 computer scientists in the world to work for them, will this process produce that? Or is there another process for them?
I think the most effective way to get a job there is to build a small company and get acquihired.
[0] I don't work at Google, but I've researched the process in anticipation of an interview.
Well I know one mistake they may have made in hiring. Guy I used to work with had a totally unclear design process and couldn't complete his work. He would design flawed algorithms that made no sense to anyway and then he asked for lead a project which he dug himself into a hole and had me pulled in to help him and then abandoned me and left the company. Spent 3 months cleaning up his mess. I wonder how he is working out for them...
Ah, they are very unlikely to get the top 100, but very likely to get e.g. 100 of the top 200? Now I think I understand the trade off they are going for (e.g. Getting 100 of the top 200 is more efficient and they are "good enough")
2 replies →
Acquihired people still are interviewed.
It's also stressful. To be fair the tree problem he got was easy, but brain freeze can kill you. I flubbed a trivial problem at a FB interview that still haunts me today.
Often it's completely free-form too. So you have to pick the language, the data model, the data structures, the traversal mechanism (recursive vs. iterative), state to track (allow duplicates? prevent infinite loops?) and how to test the example all at once before even getting _started_ with their problem description.
Many of the interviews could actually work if they broke the process down into 8 questions instead of one (how would you represent a tree? a binary tree? how would you find node X? how would you move node X to the other side of the tree?). But, the ability to accommodate understanding takes empathy and human connection, not being a jerk programmer on interview duty who is browsing HN while listing to the interviewee mumble on your speakerphone.
Never underestimate the lack of ability in the interviewer and not the interviewee. Except, the company always believes itself to be more competent than outsiders, so you're ultimately left with being condescended to unnecessarily.
Ha, I totally messed up a question for a front end interview today that could have easily been solved with timeouts. I didn't realize timeouts had resets as I haven't used them extensively and bam I'm trying to essentially design a reset for a generic counter. Boy I felt ridiculous. As soon as he said use timeout reset it's immediately obvious what I had to do. I'm not a bad programmer but between brain freeze and whiteboarding, and interviewing day after day for a few weeks, it just didn't occur. Killed me and I hope I don't miss out on an offer from a company I was actually really interested in because of some bullshit brainfart on something I'm not particularly well versed in.
Whatever! They asked me back but it sure is a frustrating feeling even if I tend not to appear flustered until I walk out, introspect, and realize what a doofus I was.
>>To be fair the tree problem he got was easy
They don't just stop at binary trees. Think of it more like memorizing hundreds of magic tricks that could be done using a deck of cards. The tree is more analogous to those deck of cards. The data structure remains constant but the tricks you can do keep changing.
I know of situations where candidates have been grilled whole full hours on tree traversal methods, and then asked to code up perfectly working solutions for them.
Do these people seriously think people who can invent 50 years of CS research by sheer analysis over an hour on the whiteboard, will be ready to work for them to write shell scripts? If not you are only testing memory skills.
In my academic days I used to refer to say "physics-standing-up" is a different subject from "physics-sitting-down" and needs to be studied separately. Some years after I left academia I had the good fortune to get in contact with the person who introduced me to acting at a very young age and thank her for her contribution to my academic career. About 30% of my success was due to my comfort working in front of an audience--even a panel of examiners is "an audience"--and I had a huge advantage over my peers because of it.
One thing that I'd recommend to anyone seeking any kind of job is taking some improv courses--they are pretty common in major centers and even some smaller towns, and can really improve your ability to deal with this kind of nonsensical interview situation, which tests a bunch of skills that have nothing to do with your ability to actually do the job.
Bingo, unfortunately, this does happen. Happened to me at Google interview with one of the rather trivial question.
3 replies →
Yup. I could see myself getting brain freeze on this question in an interview setting.
I'll disagree that these questions require weeks of preparation. I think it's more just unfair because they favor a certain type of person: those whose interests align more strongly with the theory and algorithms and less with building things.
Of course, the irony is that for vast majority of the people they hire, most of the work they do will be building and not much algorithms work. So then what will happen is either you have people who are great at building things and force them to suffer through the interviews or you have people who are great at algorithms but not that interested in programming.
Of course, you might also have people who are great at both, but I wonder how many of them there are..
I don't necessarily agree though, I think if you can reason about a problem, you are infinitely more valuable than someone who memorizes problems and just applies them blindly.
Correct me if I'm wrong, but a binary search tree is a very simple data structure. It has rules, and just by it's definition, and the definition of "inverted", you should be able to come up with an iterative solution, even if it's just walking the tree and re-creating it.
It may not be the best, but it's a solution, it's a starting point.
But if you're interviewing for a job solving problems, shouldn't you be able to solve problems? Even if they aren't the best solution? Genuinely asking here, as this approach seems to have a 85-90% success rate for me.
It depends how your interviewer is ranking/scoring you. One interviewer might be impressed with your ability to talk through and solve the problem from first principles, where another might ding you for not instantly knowing the answer. The former type of interviewer would be happy to give you hints and prompts, the second is a stone wall. I try to be the first -- it helps assess how a candidate responds to coaching too! -- but there's a spectrum between "nudging" and "telling them the answer straight out".
3 replies →
Is a binary search tree a problem that the Dev would have needed to solve? In over 5 years as a dev, I have never once needed to solve a binary search tree. Why not ask the candidate how to perform a kidney transplant.. That's solving a problem too. White boarding algorithms is not relevant to the majority of Dev jobs. It's related, but not particularly valuable as a screener.
2 replies →
Typing "how to reverse a binary search tree" into google is not the same thing as solving a problem.
If these problems were so reliant on individual problem solving ability, there wouldn't be dozens of books with reams of answers to these questions on the market. These questions test memorization and nothing else.
2 replies →
I wonder how much of it is legacy.
Google said early on they want to hire the best and brightest and that was the most important. We got the mantra that passing over a good person is better than hiring a bad one. And they were right. But they're a huge company now. They, and other gigantic tech companies are always complaining they can't find 'good people'.
But how do you make this philosophy scale? Do you say, "This person is smart but lacking some skills so we'll invest in them"?
I have no idea. :(
Smart people will learn what they need to to do a job if they're interested in it.
Google has decided that the only way to tell if someone is smart is by asking academic questions.
Even though anyone with half a brain knows that there are other ways to gauge how smart a person is... such as experience.
Does anyone really think Max can't look up how to invert a binary tree if he needs to do that? He obviously knows how to read and learn. So why is that a reason to reject someone?
Google is filled with smart people.. but their interview process is pretty stupid.
4 replies →
> The gigantic tech companies are always complaining they can't find 'good people'.
The "can't find good people" argument can usually be solved either 1) raising the pay, or 2) increasing the labor pool (i.e. H1B, etc). Raising the pay is what is done in finance because it's harder to make the argument that the required "skills" are lacking in the labor pool. To enter investment banking, and then private equity, it often only requires a B.A. in French literature and willingness to work 90 hours.
1 reply →
They'll do it when they start to care more about how much their employees cost. Screening too narrowly drives up the price.
1 reply →
I agree. I feel the overpowering urge, when asked this sort of basic interview question, to shout back "WHY?". What does inverting a binary tree have to do with software engineering, at all?
Google (and other interviewers) might as well be asking me to name the last 1000 digits of PI. The Kafkaesquen ability to recite how to do the task correctly reflects nothing about the candidate, except the strength of their memory.
It boggles the mind that the field of computer science does not have any standard way to detect the competency of a person. It is extremely discongruous for a company with as many smart people as Google to have such an absurd hiring policy.
This spoof comment is hilarious. The last 1000 digits of π!
At my job, our interview guidelines explicitly say that we don't expect non-graduates to be able to whip out fancy data structures. We want to see that the person can program, how he thinks about problems and system design, and how they deal with being stuck. I've seen people with impressive CVs and PhDs that were unable to solve very simple programming tasks.
Google interviewers are strictly told to ask these data structures and algorithms questions, it doesn't matter to them if they are relevant for future work. I have even read reviews by PhD candidates where even they were asked these questions in the interviews. When I interviewed with Google last year, I remember that the interviewers had a blueprint of the type of questions they were allowed to ask. They hardly concentrate on your resume during the interviews.
At what point during one's career should one simply be hired at face value and be exempt from interviewing? After 10 years? 20? 30?
"I see your resume says you've been writing software for 30 years, and wrote this really well known tool. Wellllll....That's good enough for me. You're hired!"
Background: I worked at Google for 5 years and did a bunch of interviewing for them.
I don't support skipping interviews even for good candidates, but if you were going to it would work the other way around -- you'd value recent accomplishments over more distant ones.
People don't understand that cutting out folks who had their name attached to some big successes but can't solve a toy problem in an interview is usually a really good thing. It's a strength of the system more often than a weakness. You wouldn't believe the number of senior candidates I interviewed who had really impressive resumes but were clearly checked out from doing real technical work -- folks who obviously no longer lived close to the code and either were very rusty or just no longer had the temperament to spend time thinking through a slightly tricky piece of code.
One of the reasons not to skip an interview for a candidate you're confident is good is that a good interview can be a great sales pitch to come work for your company.
I've interviewed and worked with 30 year programmers and for some of them it was obvious could not program and their resumes were concocted. I would never rely on a resume.
When they buy your funky startup
> At a certain point, your resume should speak for itself.
IIRC, a Portuguese proverb states that paper accepts whatever is written on it. One should always take a self-assessment with a grain of salt.
He self-assessed writing Homebrew?
10 replies →
Another way of looking at it is that they do these kinds of interviews particularly because they do want to hire fresh grads (and ideally, the best 5% of those) over experienced programmers. And if that's the case, then it's not really flawed, it's doing what it's supposed to do.
Actually, Max himself said that it "Felt like they would have preferred a fresh comp sci grad."[1]
Investment banks recruit bright young graduates, putting them through a tough selection process (c.f. all those hard-working interns we keep reading about), and select the ones who perform/conform the best. The rationale for bringing in young (as opposed to experienced) people is that they'll work their asses off, can be moulded to fit the culture (i.e. independent thinkers aren't necessarily sought), and (perhaps most importantly) are too junior to present a threat to the incumbents.
If Google's going down the same path, it may be a sign that their corporate culture is solidifying, which would be a bad sign, IMHO.
1: https://twitter.com/mxcl/status/608698037100244992
I think this is probably overall true. I'm a bit cynical, maybe, but the set of tech used by developers here at Google does not necessarily intersect with what is used in the rest of the industry. So much is proprietary, and best practices are heavily codified and well understood. So in reality I suspect that new grads are as valuable or more valuable to Google as experienced engineers since it's unlikely the specific technologies an experienced engineer has under their belt will be specifically applicable here.
For the top elite of experienced engineers that may not be the case, as they will come with some overall good analytical skills that Google wants. But for most in our industry, what we have learned over the years is how to be good in various sets of tech around our platforms of choice... and that is mostly irrelevant to Google, as they have their own platforms.
It always surprises me when people like Pacino or De Niro talk about going for auditions - I'd imagine they had a large enough body of work that directors would know what they can do.
But then it occurs to me that they won't have seen them in -this- role acting -this- way for -this- film/play/whatnot and that's what the director needs. And given the amount of money and risk involved, it's probably wise to check first...
That's true. However In Google defense, they tell you upfront what kind of interviews you're going to get and their process it's pretty well known anyway (with all its flaws). I went through the same pain myself a few years ago and I'm not disagreeing that the chap should have just got the job there, but their process is well known and perhaps he just had the wrong expectations.
How do you practice answering whiteboard questions?
By re-learning computer science concepts you haven't had to use in real life without Googling in a decade.
11 replies →
I found actually using a whiteboard, or pen & paper, is the best.
No computers. Pen only.
For me, rehearsing an answer works out. Then, I try to see how to deconstruct it and apply it to a similar problem I don't know.
I can deliver an answer sounding confident and competent because I practiced an answer. It's a bit of a crap shoot.
What irks me the most is that people are doing the interviews. They can be fooled and persuaded with tones and intonations without them realizing it.
4 replies →
Look at glassdoor.com or careercup.com for questions from a certain company. Practice using paper and pencil.
Have a friend do a mock interview with you.
They all just seem to be varying levels of fanciness over relatively common data structures and algorithms. I was only applying for internships but the whiteboard stuff wasn't too bad when I did (and other questions I practiced online), I imagine almost completely because we'd done 2 related modules at university.
You spot patterns but there's so many different ways they can ask things and things that you just remember from studying it, that I imagine I'd do worse now unless it was close to what I've done since. On the spot I couldn't invert a BST right now.
I suspect you could probably pass a whiteboard interview a few weeks after taking a mooc on data structures/algorithms with enough depth for example.
You might want to check the latest post on this topic on Eric Lippert's blog: http://ericlippert.com/2015/06/01/writing-code-on-whiteboard...
Get a couple books on algorithms, memorize like its CS 101 basically.
4 replies →
This is something I could agree over, Thoughts on technical interviewing. http://ericlippert.com/2015/06/08/interviewing-candidates/
Thanks for the link. My personal favorite http://rajeshanbiah.blogspot.com/2009/01/how-to-interview-ca...
inverting a binary tree is a pretty basic question though, if you understand recursion. i can understand why google would ask simple algo questions
Could you illustrate? I can find plenty of examples of mirroring/reversing a tree (below the root node) but none that really invert it. I haven't even found a definition of what inverting a tree means (aside from some academic papers I haven't been able to read yet), despite quite a bit of googling.
1 reply →
The fact is, that reliably separating bad from good engineers is incredibly difficult at best.
For big companies that want to scale hiring process, there's really not much you can do.
You put difficult questions and you hope that bad engineers will not be able to solve them. Then you absolutely have to commit to not hiring the guys who can't solve the assignment, otherwise it's all for naught.
'Bring in something you've built and we'll go through it' is getting pretty common.
I spent Xmas break reviewing the most recent TopCoder problems, C++ and STL, and read Sedgewick's algorithms book cover to cover. I drank two quad espressos right before the interview. The interview was a straightforward process and I didn't miss a single question. The offer came that evening.
I should have turned it down. I've written on this thread already what a career-churning waste of time my brief stint at Google turned out to be because I was blind allocated.
Fortunately, the skills that got me noticed by Google were in demand elsewhere then (and, ironically, in demand at Google now) so I just exited the building when it became clear HR had labelled me a troublemaker for trying to find a position that made use of my talents rather than opt for the career reboot they seemed to expect of me. Great perks, but the 2nd worst gig I've had my entire career.
What was the worst?
1 reply →
To all of those saying ranting on twitter is the wrong move I couldn't disagree more. Twitter is often the ONLY tool that the average person can use to communicate and/or call out large companies on their actions. This is BS and should be made known. Homebrew is an amazing tool and I'd be falling over myself getting the offer papers in this guy's hands if he came to me looking for a job. The fact that google turned him away only further cements my opinion that google would be a terrible place to work.
My main complaint with the tweet is that it's almost certainly speculation.
1) Most companies (for legal reasons) don't tell candidates why they weren't offered a job. Maybe it was because of the binary tree question, but maybe it was for some other reason.
2) Homebrew is a Mac-only product, so the likelihood that 90% of Googlers use homebrew is very low. Moreover, Google does not track the software its employees download onto their laptops, so there's no way they would even know the percentage.
> 1) Most companies (for legal reasons) don't tell candidates why they weren't offered a job. Maybe it was because of the binary tree question, but maybe it was for some other reason.
So when I was declined at Google I knew people who worked for Google. One looked up my profile in whatever system they used and the other simply asked the interviewer why. OP may have done the same but as you say it's unclear either way but knowing is still possible.
> 2) Homebrew is a Mac-only product, so the likelihood that 90% of Googlers use homebrew is very low. Moreover, Google does not track the software its employees download onto their laptops, so there's no way they would even know the percentage.
Most of the people I know at Google use Macs so I don't see why not. I don't know what the majority of them use but a good chunk at least do.
As far as tracking he could simply be tracking it himself and comparing his results of known Google IPs to employee counts. Not as accurate but might give a rough estimation. He may have further analytics based on data collected (if collected) by each machine.
3 replies →
To your second point, there is an official Linux fork called Linuxbrew. http://brew.sh/linuxbrew/
Granted Linuxbrew isn't nearly as prevalent as Homebrew, but Macs are prevalent at Google.
Really? In the UK companies are legally obliged to reveal why a candidate did not get a job, if asked... in my understanding.
4 replies →
In my experience it goes exactly like this just about everywhere:
job: here is your macbook pro, welcome! you: <install homebrew>
5 replies →
We don't have all the details. You might not hire the best computer programmer in the world if he was also a psychopath. Heck, you might skip on him even if he wasn't a good culture fit. I'm not saying this person is / was any of those things, but there's more to hiring than just talent.
There's also the committee factor. Google doesn't hire/no-hire based just on one person's opinion. If half your committee says, "90% of our engineers use his thing!" and the other half says, "But he can't code on a whiteboard!" then the committee is already kinda likely to take a pass due to lack of consensus. If there's any doubts at all on culture fit, which Google absolutely does care a great deal about, even more so. That said, when I was there, I interviewed someone who was essentially going to be my partner on something and everyone else (who weren't going to be working with this person) ranked the person poorly and I was the sole voice of (positive) dissent. I wasn't on the committee, so I don't know what their logic was, but the person was hired. And they were great. So it's not always even a majority opinion thing with the interviewers. In a nutshell, not only are we dealing with incomplete information here, we're dealing with VERY incomplete information.
Yeah, the twitter rant was a little unnerving. Might not have anything to do with inverting the binary tree.
1 reply →
That's not what happened at all. Google has an interview process that is designed to weed out false positives(incompetent people getting hired). Because this guy didn't have enough algorithmic knowledge he failed their filter. To work at the borg you must learn and play by the borgs rules!
Ranting on twitter is fucking awful. All it gives is nuance-free soundbites, and there are no 'lines to read between' due to it's brevity. Stuff gets taken the wrong way or out of context all the time.
One of the reasons why it's so powerful is because it gives lazy journalists a stream of easy reaction quotes. When else in the history of journalism has there ever been a private company that was so heavily promoted, regardless of the media source? And even then, the react quotes are poor quality, single-sentence shit.
This rant on twitter is absolutely meaningless unless you have a heap of context to go with it. And because twitter is popular, it's dumbing down public discourse along with it.
/rant, that I couldn't have fit in 140 characters.
maybe Homebrew is amazing, but Google can hire the best people in the world. that day they might've interviewed 10 people better than him who just didn't make a popular tool
"that day they might've interviewed 10 people better than him who just didn't make a popular tool"
Are you judging this on their ability to invert a binary tree? People here are ranting about having a problem with interview practices not representing whether or not you are good at your job. That's presumably (IMO) why the tweet was posted.
11 replies →
> maybe Homebrew is amazing, but Google can hire the best people in the world.
Then why don't they? I wouldn't consider "the best people in the world" those that can pass an advanced CS class.
3 replies →
Well how do you define "better"?
Esteemed schools of music probably produce dozens of guitarists "better" (in any way you would measure it academically) than Jimmy Page or Jimi Hendrix per year who go on to a life of producing nothing of lasting worth.
I'll take the guy/girl who has actually proved they can produce something useful every time over someone who is "better" but hasn't.
3 replies →
Has no one stopped to question what Google may have been looking for in a candidate?
The OP has written some great apps, sure, but there is a huge difference between writing a package manager for Mac (among other Mac/iOS apps and utilities) and writing incredibly complex, highly performant algorithms for say search indexing, machine learning, ai, etc...
In that context, knowing CompSci basics like Binary Trees (usually taught to pre-major CompSci students) has a lot of relevance. It's clear Google was looking for a Computer Scientist here, not just another developer.
I am also put off by the extreme display of non-professionalism here. It's like the OP took this personally as an insult. "I've written popular things, how dare you not hire me if I want to work for you!". That's not a professional I'd like to work on a team with. Rather, that's a throw-back to the "Rockstar" programmer that nobody wants to work with.
This boils down to a person who was personally offended a company did not hire them at a drop of a hat, as-if he was "blessing" Google with his presence.
I'd say, Google (and other companies) are better off without this type of ego.
They made the proper choice to weed this individual out.
I used to do interviews at Google, and most likely, the interview process just failed in this case. Typically a candidate will do 5 technical interviews, where the Google engineers can ask basically anything they want to (eg. invert a binary tree in this case) and score the candidate. If the candidate trips up on one of these interviews, that can be enough to reject them. The process will sometimes randomly reject qualified people.
Additionally, I think people have a mis-perception of the skills required to work at Google:
> writing incredibly complex, highly performant algorithms for say search indexing, machine learning, ai, etc...
...
> Google was looking for a Computer Scientist here, not just another developer
This is not really the case. The large majority of positions are for basically "just another developer" to maintain an internal Java tool, or some web UI, or whatever. They are complex in that they have many dependencies and often lots of legacy code, but not all to different from Microsoft, Apple, Facebook, or any company with a large code base. In my several years at Google, 0-5% of my time was spent coming up with complex algorithms.
Then why do they put people through those extreme paces? If you have the chops to get through the Google interview process, you are not "just another developer." If I were enough of a star to get through the process, got hired, and then was put to work maintaining some internal Java tool, I'd be pretty pissed off.
1 reply →
In fairness, package managers can get surprisingly complicated from a CS aspect. openSUSE wrote an elaborate reusable SAT solver library just for the dependency resolution component. Then let's not ignore that a package manager at its core must deal with the finicky nature of contemporary dynamic linking, the OS environment and all the baggage that comes with heterogenous library contexts and namespaces, maintaining transaction consistency, preferably ensuring atomic operations and so on.
That said, I don't think Homebrew is one of these. Always seemed like a quick fix for an OS X deficiency to me, and its competitors MacPorts and Fink being mediocre themselves certainly helped with its popularity. Not to rain on the achievements of the developers, but still.
To further your point, Package Managers have been done... and have been getting done for a long time.
Blazing the trail in machine learning, ai, etc... that's new territory where there are no knowledge bases or places you can go to source information about how to do it.
That's a different ballgame, and requires a scientist, not an engineer/developer.
1 reply →
If you follow the twitter discussion, it says he applied for iOS tools. I don't know what tools they write but I'd be surprised if someone who manages to write a (pretty good, actually) package manager can't solve the problems in this position.
Google doesn't hire for specific projects like this - they want people who can work all over the company.
1 reply →
> If you follow the twitter discussion, it says he applied for iOS tools
We cannot just assume that since he applied for iOS something at Google that he's the best fit and what they were looking for.
Maybe the tools Google needs built are very CS heavy (hence the "Build us a Binary Tree" question)? Maybe during the interview his arrogant attitude was on full display? Maybe the interview team dug up past episodes of explosive arrogance like this very one we're discussing right now?
Even if they were looking for someone that matched his profile exactly, his post-interview display of non-professionalism is sure to hurt his chances of a re-interview anytime in the future (and quite possibly at many more companies than just Google).
He conveyed several things with this display, none good;
* he's incapable of handling rejection
* he feels entitled
* he feels he's better than everyone else
* he's unwilling to admit his own shortcomings
None of these are good qualities.
3 replies →
There is no slander in his tweet, he reported the FACT, may be a tad-bit dramatic, but FACT none the less. I just cannot understand why people think, Job seekers should cower down in public in fear not getting a future offer. To the hell with it, speak your mind, live like a boss even it means you make a little less financially, its better than being a rich coward.
The only facts in this tweet are:
- The guy made Homebrew
- The guy interviewed at Google
- The guy was not offered a job at Google after his interview.
Anything else is unconfirmed and, speaking as someone who's thrown quite a few frustrated hyperboles onto the internet, sounds like frustrated hyperbole.
Frustrated hyperbole should not be taken at face value as fact; sometimes there's truth in a smaller version of what's said, but not always.
For example, there is no fact established that Google hired him because he can't "invert a binary tree". In actual fact, we don't know that Google even asked him to invert a binary tree (at least not specifically). It could be that they asked him a question that he thought was as irrelevant as academic datastructure exercises.
And we don't know that his answer was the reason he got turned down either. This is the part of the hiring process (and really any human interaction) that takes the maturity of recognizing that people and their motivations/reasoning are more complex than we reflexively flatten them out to be.
> There is no slander in his tweet, he reported the FACT, may be a tad-bit dramatic, but FACT none the less
What facts are you talking about? The "facts" coming from half the parties involved? The "facts" coming from an upset and irrationally thinking person who's caught up in the moment?
All that you say is true, but there's another side of the coin.
Nobody wants rockstars in teams, because rockstars are bad team players. That's the reason why they're rockstars. Nonconformity (sometimes) leads to innovation. Like it or not, a lot of the tools and libraries which we use every day and on which the internet runs, was written by lone-wolf 'rockstars' too weird and too eccentric to work in large corps.
You don't want your whole army to go over those mountains, you send scouts. Scouts are terrible soldiers, but they are quick to find a path between the trees and rocks and they come back with new information, new ideas and concepts of how to optimally win the battle. Then and only then you bring the whole army and win.
A company, imho, should always have a small number of rockstars - impossible characters, crazies and lunatics with universe-sized egos, who have a track record of successful projects in the wild, working on insane things, alone or in very small groups, carefully managed by someone who can earn their respect - usually a lone wolf turned general.
They might be terrible programmers, they may have no education, but they have this unusual ability to see into the future and come back with interesting ideas and prototypes, which the 'soldiers' - people with solid fundamentals - can polish and transform into profitable products.
If a company innovates 'from the top', then it's trend is going to slowly be downwards towards irrelevance, because true innovation comes from the trenches and is done by the rockstars nobody wants to work with.
being able to invert a binary tree makes you qualified to develop machine learning, ai, etc code? that's a pretty low bar. If that's the level of knowledge you need to do that, then can it really be called AI?
If that's really what they intended for him to develop, then why not ask questions about machine learning or AI?
You think like a Google interviewer.
> You think like a Google interviewer.
The OP is the type of person that, six months from now would be demanding special treatment because "he wrote Homebrew".
Writing a package manager (been done before, a lot of times) is far different from writing machine learning algorithms (new field, blazing the trail for the industry). One requires an engineer, one requires a scientist.
The OP flamed out because Google was looking for something he was not. Instead of taking it like a professional, he decided to retaliate.
The tone he took in his post is appalling, and I cannot believe HNers are defending him. "I'm special because I wrote something popular (and make absurd claims about 90% of people using it), so you better hire me or else" is what he just laid down.
That's not the type of person I'd want to hire or work with... and I'd wager most would agree.
8 replies →
I didn't agree with you at first.. but after thinking about it I think you're absolutely right.
Getting rejected from one interview at Google isn't the end of the world. The right and mature thing would have been to go home and figure out the problem that you got stuck on.. and then try again. We all go through this process, why should we expect anyone else to get a free pass?
I recently watched an online game of chess between a grandmaster and an anonymous individual.* The grandmaster got caught off guard and got lured into a trap. Instead of getting defensive, he sincerely thanked the other individual for a great game and spent the next few minutes after discussing the intricacies of the trap.
Shouldn't someone as accomplished as the creator of Homebrew feel the same way about a problem he got stumped on?
* https://www.youtube.com/watch?v=Voa9QwiBJwE&feature=youtu.be...
He applied for an iOS developer role.
They reached out to him - he mentioned it in a tweet, and they've skipped the phone interview . Also, he would not be the one writing the machine learning, search indexing, but rather the app itself. All of those would be handled by other non-ios developers.
[Ex-Googler here] Truth be told this is a trivial question to be asked during an algo interview and as an interviewer I'd consider this a warm-up. Otherwise it's a rather poor question since either you know how to do it (ie, you have an idea about recursion) or you don't - there aren't too many shades of grey or possible follow-up questions that I can ask to probe the depth of your knowledge.
That being said if I asked this as a warm-up and we'd spend the whole interview trying to get that done then of course my verdict would be No Hire. As an interviewer it is not my job to look at your GitHub profile - instead I am assigned an area to check and I try to come up with the best understanding of the candidate in that area. While failing to reverse a binary tree is a total failure in algo/ds you can still be hired since there are several interviewers (if you make it to onsites, that is), each probing a different area.
My biggest problem with Google style interview process is that it's easily passed by folks who already passed it in a different company. After having interviewed hundreds of Google's candidates I moved to another big company with the same interview type and the experience was really surreal. On my algo/ds interview I got asked slight variations of the same questions I was asking myself - and over time I've seen some totally brilliant, unexpected solutions. Must have been a strange experience for the interviewer who got his questions each answered in 3 minutes tops. I also made it a sport to solve each one in a different language because why not. Not sure though about validity of the signal the company got from this interview.
> [Ex-Googler here] Truth be told this is a trivial question to be asked during an algo interview and as an interviewer I'd consider this a warm-up. Otherwise it's a rather poor question since either you know how to do it (ie, you have an idea about recursion) or you don't - there aren't too many shades of grey or possible follow-up questions that I can ask to probe the depth of your knowledge.
It is a terrible question.
First, you can't invert a binary tree (as in flip upside down). If you did, you'd end up with multiple roots and since all binary trees are rooted, you'd no longer have a binary tree. It'd be a tree, just not a binary tree.
If the questioner meant mirror a binary tree (swap left & right at each node), then it is a no-op. You do not need to modify memory to do it. Left & right are just labels for two pointers. You can just swap the order your variables in whatever struct defines your node and cast it against your existing memory (or change what your accessors return in a derived class or create a reverse iterator or however you want to implement it) and there you go, a "reversed" tree with zero overhead.
Either way, it is a terrible question unless you wanted to see if someone understood the difference between how a data structure is drawn on a whiteboard for humans vs. how it actually works. Maybe they were actually asking that question, but that seems highly unlikely.
And if they actually meant for you to recurse down and swap left and right on everything, it would dramatically lower my opinion of them because it would make me wonder if they knew the difference between how a binary tree is drawn on a whiteboard vs. how it is laid out in memory.
> First, you can't invert a binary tree (as in flip upside down). If you did, you'd end up with multiple roots and since all binary trees are rooted, you'd no longer have a binary tree. It'd be a tree, just not a binary tree.
Inversion is a transformation that maps directed graphs to directed graphs. Binary trees are a subset of directed graphs, so applying inversion to them is not unreasonable. That subset is not closed under inversion, so you can get results that are not binary trees, but I see nothing in the question that implies that the interviewer was asking for the output to be a binary tree.
That may even be one of the points the interviewer wants to see the candidate address. Since the output no longer has a single node from which all other nodes can be reached, in addition to just inverting it they may want the candidate to mention the need to have some new auxiliary data structure to keep track of the multiple root nodes (and perhaps note that in the inverted tree each node only has one outgoing link, so if we are inverting in place each has room for two, so we can use that now available second link space to make a linked list of the roots, so we don't need any extra storage for the new root list data structure).
> if they actually meant for you to recurse down and swap
While only the person asking this question knows for sure I'd assume that was the intention.
It's not a _terrible_ question - it's just a recursive equivalent of FizzBuzz. You would treat this as a way of making a (good) candidate gain some confidence. And that alone is extremely important since the more at ease the candidate is the better the signal that you're getting. What I was trying to say there was that if I asked that as a warm-up and didn't get a satisfactory response very very soon I'd realise that your man has no clue about recursion and would move to the main question, choosing one that does not involve it. It would be something easier than I'd ask otherwise and would be closer to real-life scenarios - like first solving a simple problem, then parallelising the solution and correctly managing concurrent access.
> First, you can't invert a binary tree (as in flip upside down). If you did, you'd end up with multiple roots and since all binary trees are rooted, you'd no longer have a binary tree. It'd be a tree, just not a binary tree
Just because someone wrote on Twitter with limited number of characters that the problem was to "invert a binary tree", does not mean there were no clarification from the recruiter.
> And if they actually meant for you to recurse down and swap left and right on everything, it would dramatically lower my opinion of them because it would make me wonder if they knew the difference between how a binary tree is drawn on a whiteboard vs. how it is laid out in memory.
If you're thinking about making a real structure, I believe you should recurse down and swap. If you don't do this, rotating, joining etc, could be a real pain.
If they said "swap left & right at each node" it would have been easy. But they used a term that doesn't even yield an example in google searches - what kind of "inversion" do they have in mind? It's as if everyone is on the same page but me.
2 replies →
Would a multiply-rooted tree still be a tree? I thought a single root was part of the definition of a tree. Would it instead be a graph?
Sorry for the elementary questions. I'm bad at algorithms and just trying to get a grasp here.
4 replies →
Exactly. This style interview doesn't find the people I think are valuable - people who ship code. Instead, it validates people who spend time thinking about interview questions.
A lot of people require a github to get an interview. But nobody wants to look at what's on the github.
I've interviewed hires before, and if I ask for a github, I'm going to take the time to review some of the code, otherwise why would I ask?
The link between the content of your GitHub and your ability to ship code is unclear at best. I knew a guy who had a really awesome GitHub profile but turned out to be a mediocre contributor to the codebase. He claimed that coding style guides we used were hurting his creativity to the point that he did not enjoy coding and would avoid it if possible. He'd fix bugs and make small-ish contributions but would never ship major features or libraries "because of the style guide". While I understand the sentiment I always found his attitude juvenile.
1 reply →
This is about Google, which does not require a github.
1 reply →
WTF is "inverting a binary tree?". The smattering of search engine results points to some seemingly operation that basically generates garbage by destructively manipulating the tree into a DAG in which the leaves of the original tree are roots, which point downward the parents. The original root node is returned, and still points to its children. Unless you return some aggregate (e.g. list) of all the roots which are not direct children of the original root, or it is understood that something elsewhere holds reference to them, they are leaked.
Be that as it may, if the interviewers hand you a reasonably detailed specification of what "invert a binary tree" means and you can't whiteboard it, I don't see how you can expect the job.
If you're expected to know what it means, and get no hint, then that is just stupid. "Whiteboard up an implementation for something we refuse to specify, beyond citing its name."
I agree. I have no idea what "inverting a binary tree" means, or why I would want to do it, so I'd need some context from the interviewer. Chances are, I'd ask some very pointed questions about whether a binary tree is really the best underlying data structure for whatever the "inversion" process is intended to accomplish. The interview would probably go downhill from there.
My guess is that the potential leaking of some nodes is one of the points of the question. A lot of people would not notice it.
Note that in the original tree each node needs storage for two pointers. After inversion only one is needed. You can use that now unused storage to link together the multiple roots to solve the leak problem.
But note that only consumes the second pointer storage in the roots. Interior nodes end up with some free storage after inversion.
Since inversion is reversible, the binary tree and its inverse contain the same information. Does this mean we should only need one pointer's worth of storage in the binary tree nodes?
Is there something for binary trees similar to Knuth's xor trick for doubly linked lists?
If you invert the tree such that each node points to its parent, and there are no child pointers, you lose information. Namely, the order among children is lost. A given interior node still has two children as before, but it is not known which is the left child and which is the right child; there is just a set of up to two nodes which point to the same parent.
The binary tree inverse specifications/implementations I have looked at preserve the information by selectively using the left or right links. For instance, given:
The inverse would be:
Both children point to the parent. But the left child uses its right pointer, and the right child uses the left pointer. That's what preserves the information about which child is which.
'Reversing a binary tree' [1] is the more likely actual question.
[1]: http://stackoverflow.com/questions/9460255/reverse-a-binary-...
Sorta ironic, but remember that the point of an interview is to determine how well you'd do in the environment that's hiring you, not how good a developer you are. Because Google tends to reinvent the wheel for basically everything, algorithmic knowledge really does matter. Package management only matters within a few very specific subteams. If you're interviewing for a general SWE position, you could be Mark Zuckerburg and still not qualify for it.
FWIW, I find Facebook turning down Jan Koum in 2009 and then spending $19B to acquire his company even more ironic.
That may well be, but if you're considering hiring a guy who's an expert at writing package management tools, don't you put him on one of the specific subteams that needs that skillset? Surely it's something Google deals with?
The problem is that Homebrew is very different from the sort of package management tasks that Google deals with. The design goals for Homebrew include: make it easy for users, make it not require root, make it work on Macs, handle dependencies robustly. If he were at Google it would be Linux-only, he'd be using Linux containerization extensively, he'd be deploying packages to thousands of machines instead of one, it'd be a virtual guarantee that some of the machines would fail during the installation process, there would be little or no user intervention and if there was a user it'd be a trained SRE, and the installation procedure would probably need to be an order of magnitude more efficient than Homebrew is.
I don't want to take away from his accomplishments as a programmer - I use Homebrew too. But my point is that it's very easy to see "Good programmer, of course he should get hired" from the outside, while the reality is that it may not be all that similar to the tasks he'd be doing.
7 replies →
Sure would've been nice to have a package management expert working on Go.
1 reply →
I might be wrong, but I'm pretty sure Mark Zuckerberg can reverse a binary tree.
Probably cheaper than starting 1000 $19M projects and dumping the ones that aren't wildly successful.
Very good point. It's like, why do you want to work for Google if you aren't into algorithms?
I failed my third google interview. My problem wasn't that I couldn't solve the problems. I just wasn't fast enough because I didn't spend 3 weeks beforehand training speed in programming brainteasers.
other then search and maps, how many of their products use algos heavily though?
many projects i have worked on over the years required very little knowledge of algos.
5 replies →
I'd like to present HN with a challenge. Come up with an interview process that matches _all_ of these requirements:
Objective - the process avoids human bias (this guy was in my frat, therefore is awesome).
Inclusive - someone doesn't need extensive past knowledge in a particular area of coding to do well in the interview.
Risk Averse - Avoids false positives.
Relevant - it properly tests the abilities needed for a coding job, and not irrelevant ones (like the ability to write an impressive resume).
Scales - this will be used for tens of thousands of interviews.
Easy-to-do - this will need to be done by hundreds/thousands of engineers, who would probably rather be coding.
It's easy to poke fun at what is perceived to be a flawed process. It's much harder to propose a solution that satisfies the above requirements. Google has done extensive research on this topic and has done remarkably well with it compared to other companies of similar size.
Xoogler here. I can't meet your challenge. IMO the very premise of a company-wide unified interview process for all software engineers is wrongheaded.
How can you make the interview relevant without knowing what the position is? I was asked the typical CS-type questions in my interview, but the team I ended up on required no theory.
How do you define false positives before you know what the candidate will work on? A superstar in one team will be a dud in others.
And let me add another bullet point to your process wish-list: gives the candidate a sense of whether they want the job. This is impossible when the interviewer is a random engineer from an unrelated team, unable to speak to what the candidate's work life will be like. A Google style process gives candidate very little information.
I would instead propose something very old-fashioned: teams hire for themselves. The usual reply is that this results in an "inconsistent hiring bar", but so what? Teams have different requirements and need engineers with different skills, so why shouldn't the hiring process reflect that? We are not fungible engineering units.
Create an online game/project/test that people must solve in order to get an onsite interview. The game can be customized for individual teams to have more appropriate domain challenges. Spend the onsite interview walking through the code the people wrote for that game. Devil is in the details, but that's the broad strokes of what you are asking for.
It may be hard to find a solution to the full interview problem. I still do not prefer whiteboard interviews; would be happy to code using my own laptop, projecting the session for everyone else in the room to see.
To be fair, inverting a binary tree is a pretty easy question. Google also tells you BEFORE you start the interview process that it'll be very data structure/algorithm oriented and asks that you please prepare (and take as much time as you want doing so). They even say that they want you to prepare because they know a bad candidate that prepares can look better than a good candidate that doesn't prepare - then want all candidates on a level playing field so they can make accurate judgements. All that being said, I still think that there is lots of room for improvement in the process.
edit: really good english skills
I am dismayed by the way all the reactions on Twitter are piling on with outrage and/or relating similar experiences.
Inverting a binary tree is pretty easy. It is not quite as trivial as FizzBuzz, but it is something any programmer should be able to do. If you can't do it, you probably don't understand recursion, which is a very basic programming concept.
This isn't one of those much-maligned trick interview questions. This is exactly the kind of problem one may have to solve when writing real software, and though you may never have to do this specific thing, it is very related to a lot of other things you might do.
I run a small software company and I very likely would not hire a programmer who was not able to step through this problem and express a pseudocode solution on a whiteboard.
> If you can't do it, you probably don't understand recursion
No, I can't do it (don't even understand the question) but I certainly understand what recursion is, and can solve problems and make things work far more reliably than many of the more academic programmers I have worked with.
3 replies →
I'm a CS major, and I'm not even sure exactly what they're expecting. I mean a binary tree is just nodes with no more than 2 children. A linked list is a binary tree. Do they want a search tree? Do they want a self balancing tree?
Can you confirm that actually inverting a BT or solving other similarly probs would have been part of his future job at Google?
If so, they were consistent in disqualifying him in spite of his awesome track record, fame or "street cred" but if not, I can't really justify or defend this type of ceremonial or bureaucratic gotcha interview questions as they are just useless and can be abused by the interviewer to reject applicants they dislike for any reason or whim they might have at that moment.
6 replies →
What does it mean to invert a binary tree? I'm not familiar with this operation on binary trees. Does it mean to swap parents with child nodes? Or to swap siblings?
I have a feeling that the question is not really about whiteboard coding or solving graph problems. This is a blatantly ambiguous task. Maybe it was meant to force the interviewee to demonstrate how they communicate to the interviewer that they needed more information about the problem before starting.
Pretending you understand or blindly assuming what the interviewer meant is more of a red flag to me than requiring a few rounds of clarification.
In my opinion, an ideal interviewee would communicate that they don't fully understand the requirements and possibly offer a brief set of possible interpretations. Once the interviewer has clarified, my ideal interviewee would restate the clarification to demonstrate competence and verify their new interpretation of the requirements before proceeding.
In this case, it means to reverse the binary tree, so that you get the largest item by iterating down the left branch to the bottom of the tree. You would do this by breadth-first scanning the tree, swapping the left and right pointers as you go.
Oddly enough, Google shows me interview questions where "inverting a binary tree" means something quite different — for example, flipping it upside down, and making the left leaf the root, the right leaf the left leaf and the root the right leaf.
If this was really about "reversing" the tree, as you mention, the question seems more likely to address how the candidate approaches the situation. Like, he should start by making sure they both agree on what the question actually means.
Once that's out of the way, it seems relatively easy to come up with a naive solution, without having memorised any algorithms. It seems more like a case of brainfreeze to me, which can be sort-of fixed with practice (which in turn many candidates refuse to do: the dreaded "If I have to cram for the interview, I don't want the job" statement.)
So maybe he really wasn't a good fit for Google, despite apparently being a rockstar developer. Hey, startups need rockstar devs too.
3 replies →
Depth-first would consume less memory for balanced trees.
I wondered this as well! As far as I can tell - I asked google and looked at what it came up with :) - it means swapping children.
I don't even understand why you would ever want to do this. You could just invert the input or output at the beginning or end (depending on what the binary tree is used for) for super cheap. It's not uprising that no one has done this in practice, though it also seems trivial (visit each node once).
1 reply →
Yeah I checked Google as well, but swapping children seemed too easy for an interview question. I'm wondering if it means restructuring the tree so a different node is the root. Trees have the property that any node can be the root and it is still a tree. Not sure just wondering if anyone had more info.
1 reply →
I took it to mean mirroring? It has an elegant recursive answer.
Interviewing seems broken to me too. I have spent the last few months trying to get a job out of college and everyone seems to be interested in how well you can regurgitate CS fundamentals.
They are seemingly less interested in seeing how you solve problems and work through the process of software.
I would be more than happy to see this process change, I am just not sure what it entails.
Devil's avocado: if they're truly CS fundamentals, then they should be baked into you good and deep during the course of your college education. It shouldn't be painful at all.
I took CS 101 classes almost a decade ago, and since then, I have never once needed to write a binary search tree outside of an interview.
I think "CS Fundamentals" are really just "abstract concepts used to teach programming", and calling them fundamentals is disingenuous.
9 replies →
I think the real issue is that most programming jobs aren't computer science jobs, so CS fundamentals are almost totally irrelevant.
1 reply →
I graduated this spring and I don't know how to do that. Now, I am not a boy genius but I doubt it is a CS fundamental.
2 replies →
Especially as a fresh grad. Reviewing for a week or two if you've gone to a good school/actually did your work instead of 'consulting google' is definitely enough...
If you are trying to get a job straight out of college and you didn't have many relevant internships, there really isn't much to judge you on other than what you learned in college. This isn't a fault with the interview process.
Some companies give take-home assignments (small projects that can gauge how well you learn). I tend to find that these are smaller companies. You can always try there.
Also, the most important thing that they don't teach you in school is that getting a job is all about connections. Email some people that you've interacted with to see if they know of anything that might be suited for you.
I guess it depends on where you're interviewing and what their expectations are of you. Since you've just graduated they may expect you to be very junior and just want to make sure you have a good CS foundation. They should ask problem solving questions but it wouldn't be weird if they just focused on what they think you know.
I've phone interviewed with Google a couple times. I wasn't really interested in working there, but wanted to see what it was like. Both times, the people who interviewed me were decent, friendly folks and we had a good chat. They then dug into algorithm questions on topics I hadn't seen since my undergrad (I'm about 20 years into my career) and haven't touched since then -- though I've done a bit of algorithm work outside of that they weren't particularly interested in that.
I reached into my way-back machine and tried to derive some approaches where I simply didn't remember the answer (and I was very open about it). I made it to call backs both times, but they declined to move forward, probably because they wanted a younger person who remembered their big-Os off the top of their head, but I was okay with it. I told all the interviewers I had fun and I did.
Even if I had made it in, I'm not sure I would have taken the job at those times. So my lack of motivation ended up turning what could have been stressful into a fun look at their hiring practices.
However, I can see for people who are really dead set on working there, it can be a harrowing experience.
Humorous answer: Maybe I can't invert a tree, but watch me flip this table.
Serious answer: Companies that pull this crap deserve to starve and die.
What specifically are you objecting to? That specific question? Writing code on a whiteboard?
How would you interview software engineering candidates?
If you rate engineers on their ability to memorize something they could have looked up on Google in 5 seconds, what are you really actually testing?
If you're not at Google's scale, a take-home test that involves them producing a working solution to a problem in their own time, that you then expect them to be able to discuss, reason about, justify, and so on is a much better tool; even at Google's scale, where you might be worried people who copy answers off the net, have them bring the laptop they used in, and then get them to expand upon their solution.
All that said, I'd be surprised if that was the only factor at play. The Twitter comment itself seems to indicate a - uh - cultural fit issue. Additionally, and with no actual knowledge of the insides of HomeBrew, that a piece of software is widely used isn't evidence that the author is an excellent (or even good) developer.
8 replies →
Interviews break most people's intellectual context. Talky/show-me interviews are designed around interviewing MBA "how well can you present yourself" roles, but it completely fails to evaluate a technical person.
Doing a blind and "surprise me with a clever (or traditional) algorithm" whiteboard interview is a teaching skill, not a coding competency. You have to illustrate, explain, make your self vulnerable while understanding the problem, and work in front of someone while being judged confrontationally. It's not sane. (and glob help you if you don't wrap your entire brain around the problem in the first 5 seconds, then you're clearly subpar and are worth less than dirt even with your 15 years of experience shipping products to millions of users.)
Google is happy to have 1,000 nerd projects and only one thing that makes money. As long as they continue to interview smart people on technicalities instead of well-roundness and ability to actually contribute or move the company forward, they have no need to fix their insultingly irrelevant interview process.
Why not just take a chunk of code the candidate has written that was interesting and talk about it?
The main problem with interviews [imo] is it grabs stuff the interviewer is familiar with and throws it at the person in the more stressful position of being the interviewee. Its also [often] a very non-standard way of communicating. I don't know about you but all of my communication is via text or graphic, not whiteboard.
And, honestly, do you care more about the fact they can invert a binary tree from memory? Or that they can learn to in the next hour and implement it?
My guess is for 90% of jobs, its the second.
1 reply →
I think the best way is to give them access to a code base, give them 48 hours and have them submit a pull request for a feature. That way you can see that they can learn the codebase and implement the feature in their own time. During the interview, you can discuss their code and the reasoning behind the implementation details.
6 replies →
Demonstrating one small part of a real working software engineer's job, by solving an artificial problem in an artificial environment under artificial time constraints, while one or more people with no pedagogical training look on and (sometimes) interfere. The amount of information gained is less than the amount lost from having poisoned the entire rest of the interview environment.
Number of times I have had to invert a binary tree in my 25+ year career: 0. Number of times I have been asked to invert a binary tree in an interview: 0. What I would do if I had to invert a binary tree: look it up.
So, you can only solve problems that somebody else has solved already?
It may surprise you, but in the real world very few people get paid to find new primitive methods of manipulating fundamental data structures. Google may do a lot of that, but they are an unusual company. The problems a working developer is asked to solve are far more likely to involve higher levels of abstraction. The one I worked on most recently was coarse geocoding (find city/state) of free text. But a couple of decades ago I did sort of invent a use of BSP trees for searching RGB palette space (http://www.drdobbs.com/cpp/vga-palette-mapping-using-bsp-tre...). Well, probably not, but I still think I should get a cookie.
>Number of times I have had to invert a binary tree in my 25+ year career: 0. Number of times I have been asked to invert a binary tree in an interview: 0
Well, if you wanted to pull that card, it would have been nice to mention the sorts of problems you've worked on in those 25 years.
>What I would do if I had to invert a binary tree: look it up.
Unless you're already good at algorithms, it would net you a mediocre solution.
For e.g. You would only know that there are multiple ways to implement an algorithm when you've actually done the work dozens of times and noticed that some implementations won't be appropriate for you needs. Like with many things, its about having experience, knowing whats a good fit, and knowing why something similar isn't a good fit.
Certainly - every single time you choose an algorithm, and then decide on a particular way to implement it - you could in theory, implement each algorithm in 10 different ways and then choose the best one after benchmarking. But that would be a huge drag on productivity. And if you had to choose 5 algorithms for 5 different tasks then it quickly becomes a quadratic complexity time sink. It would be far better to just know via experience. Its kind of like in chess - the better players just KNOW that certain paths lead to less favourable winning odds. Well, novices do take those paths and eventually find out the hard way !
>> Well, if you wanted to pull that card, it would have been nice to mention the sorts of problems you've worked on in those 25 years.
Quite a range of stuff, unsurprisingly. I started on an HP3000 mainframe in 1976, if you want to go back to the very beginning, writing BASIC programs on a teletype or one of the two early CRTs, and storing my programs on paper tape.
Since then I've worked in DOS, 16-bit Windows, 32-bit Windows, 64-bit Windows, Ubuntu, iOS, and Android, using Pascal, 8086 assembler, C, C++, C#, javascript, Python, and Java. I've worked on applications in multimedia, telephony, banking, insurance, pharmaceuticals, cosmetics, health care, and I'm sure a few other things I've forgotten.
All of which will mean jack squat if, tomorrow morning, the most important thing I have to do is invert a binary tree. But I'm fairly certain I would be able to figure out what I needed to do, and I am fairly certain I could manage to implement it well. It's what we're supposed to be able to do, and if you think that having studied up on it so that you could pass a Google interview means that, a few years down the road when you actually need it you'll just whip it off the top of your head, then I think life may hold some surprises for you.
3 replies →
Another instance where silicon valley favors the young... he probably would've nailed this question if he'd been only a couple of years removed from school.
He also would've nailed it had he been given 10 minutes to do some research to refresh.
Silicon valley (and the numerous companies that mock the interview style) are testing for the wrong thing when they hire, then complaining about not being able to find good engineers.
You're given weeks to refresh your knowledge ahead of a Google interview. They tell you the basic CS fundamentals that are going to be covered. Binary trees are MOST ASSUREDLY on that list. They just don't have time during 45 minute interviews to let the candidate go on the Internet to look things up they should already have come prepared for.
Anecdotally, at a previous company, we tried an "open book" (i.e. you can use the web) interview policy for a few interviews. It was a train wreck.
I just don't get it why companies assume you can spend so much time to refresh and memorize topics just to prepare for an interview. Especially when this knowledge will only be used in the interview process and then forgotten about.
1 reply →
Most people who work 9-5 jobs just don't have the time to memorize books of algorithms.
>> You're given weeks to refresh your knowledge ahead of a Google interview
Begs the question, doesn't it?
>> Binary trees are MOST ASSUREDLY on that list
Sure they are... and my intro to CS textbook was ~500 pages. I'll bet I could find something to trip up just about anybody, especially when coupled with the pressure of doing it in front of the class ^H^H^H people that have $$$$/power over you.
Out of curiosity, can you elaborate why the open book interview policy failed?
2 replies →
A project manager at Google was upset that my 'bot literally ran circles around theirs (it was 2010, Android based robots were just starting) and told me that I was just a hobbyist and my project did not exist.
So I gave him one of the spare logic boards (open design anyway). And wrapped my hand around his. And squeezed. And asked him, if it doesn't exist, why is it making you bleed?
He watched impotently as the people who had been invited for the presentation played with my robots and ignored his as two of his guys tried to get it to work.
I finished the two projects I was doing with Google and did not call them again.
(Before you downvote: Yes, there is some video, and I consider the small amount of pain I inflicted that day a kindness compared to the much greater amount of pain that an engineer is in danger of enduring if he says things like "This thing that is in front of me, it does not exist", especially if he works with big machines).
I think you need to work on your people skills.
I get that a lot. Very occasionally, it's after "thanks for saving my life / my job". There's no shame in being an asshole but there is shame and dishonor in being insincere.
or the other guy could work on his ego skills?
3 replies →
You do realize you're coming across as a literal psychopath, right?
No, a psychopath would've done something out of revenge.
I was doing something to remind an engineer that the physical world is of paramount importance.
A bit of bleeding and embarassment in 2010 as a reminder that things that are there, are indeed there, is better than being pulped by heavy machinery that "shouldn't be there" but is anyway in 2018.
I am looking forward to seeing that video.
https://www.youtube.com/watch?v=CP0wSvw_qKk Here ya go!
Interviewing is stressful and all, but if the guy's reaction to not getting hired is to flame on twitter, not hiring might've been the right call.
I'm sorry but Twitter is one of the few (if only) megaphones most people have to call out corporations for their actions. This is exactly the sort of thing that Twitter (IMHO) shines at, a platform to call down the goliaths. If I didn't already want nothing to do with working at google I would have been pushed further away by this tweet which is exactly what should happen. If google has the right to say no to someone that wrote an extremely valuable tool that 90% of their employees use then he has the right to inform the general public. Popular opinion seems to be one of the few things that can cause a corporation to change their minds or at the very least acknowledge the situation and he is expertly wielding it to his purpose. I applaud and support him in making this choice.
Edit: typo
Playing devil's advocate here (because I, personally, wouldn't have done something like that), but I can see the insult. Here's someone with a very public proven track record (that they're fully aware of, if 90% of their engineers use his software), and they're asking questions like this. They're the wrong questions to ask in this case, surely? It's fair enough to ask them, but I can understand this person's frustration if that was genuinely the reason he hasn't hired (which we have to take his word for, since we didn't witness it ourselves).
This guy can clearly ship software. The questions should have been what do you want to work on and why do that with google instead of yourself?
I don't think that it is unprofessional on his part. He is merely highlighting the absurdity of the hiring process at large tech companies.
I think everyone knows that this is not a problem exclusive to Google.
I think both you and the post have a good point.
From his perspective, I bet he's frustrated for the reasons he point out. If he never talks about it out loud, how would any one know? Keeping people silent about this issue is in the company's interest because they'll not have to really change, and they'll hire someone eventually.
I mean, I know I sometimes choke on problems I'm trying to solve in the privacy, quiet, and comfort of my own home on projects I really care about.
I don't know what went on in the interview but given what he said, I think I would be upset, too.
Too hard to say, tbh.
Why? He's under no obligation to Google. It's not like they hired him and he has to sign an NDA or be polite. He had a frustrating interview process and vented about it online, it's a pretty human thing to do. Why would that make him a bad employee?
Well, not that I agree with the sentiment, but corporations likely have incentive to hire individuals that are easier to push over and keep quiet as long as they have the skill set needed.
If you were a corporation trying to keep PR positive, would you hire someone that has shown themselves as an outspoken public mouthpiece and tip-toe around them to keep them happy, or just avoid the problem?
If the tweet is accurate in its implication that he didn't get hired because he couldn't invert a binary tree (honestly, I don't even know what that means) on a whiteboard, then I'd say the tweet is totally justified.
On the other hand, if it was a complex and reasoned decision that he's summarizing badly, then yeah, good call on their part.
Context is king here, and we have little.
Slightly off-topic but I always found it infuriating to call binary trees "binary" when some vertices have a degree = 3. :P
1 reply →
If occasionally venting on Twitter makes someone unhireable, most of us are fucked.
That is a pretty liberal use of the word flame.
And I'm pretty sure this is EXACTLY the type of guy you want to hire, I would strongly suspect writing mild mannered complaints about not getting hired on twitter has very little correlation with job success.
Actually, I think this is exactly what we need: higher-profile people willing to speak out publicly about the broken interview process.
I also somewhat laughed at the poster who stated "Apparently my GitHub wasn't enough."
Well, he is the author of numerous widely used open source projects. It is a bit redundant (and useless) to give him a "homework assignment when he has such an impressive portfolio that speaks for itself and of which you can assess the quality.
To be fair, though I know the situation in question: Company A wants to acquire Company B, because their product integrates well and also adds value to a particular niche of their customers. Person is one of the lead developers of Company B's product, and together they have also open sourced one of the single biggest components of their product.
i.e. "You want to buy us because of this, and a decent part of this is on GitHub, running every day, but you'd rather not look at -that- code but -this- arbitrary homework assignment".
He is doing both Google and people who were rejected by Google a favor by pointing out that Google's interviews are not indicative of real world performance. He might have hurt his own chances a bit in the process, but overall this will undoubtedly have a positive impact.
For him individually, I might agree, but the bigger issue is how one of the largest tech companies is hiring this way. I don't think it's worth focusing on this guy's understandable outburst to the exclusion of that.
In my office, opinions are 50/50 on this.
Interview with Lazlo Bock on Google's hiring practices:
http://youarenotsosmart.com/2015/06/08/yanss-051-how-google-...
Some of the claims Lazlo makes:
As large organizations grow, their workforce trends towards mediocrity. Google * takes special care to counter-act this effect. * researches their hiring/interviewing practices just as much as their machine learning. * publishes their methodologies: https://www.workrules.net/
The algorithm in question is discussed in Coding Interviews by Harry He. http://www.apress.com/9781430247616
I feel the original tweet conveyed a bad attitude, was emotional, reactionary, and ultimately a bad career move on the part of OP.
In my younger days I suspect I would have done something similar. I'd like to think I would see the experience as a learning opportunity and be able to react with humility and maturity, but who knows? Hopefully I can think of OP and not tap the tweet button.
Wow.
Really? Pretty much everyone recognizes that google style interviews weed out perfectly good people. What Max went through is just an example of one such obvious case. It's very much a case of the google hiring algo failing. Lot's of people would have no doubt that Max can cut it when it comes to iOS dev.
That's all it is. Now, if you are going to read "tweet conveyed a bad attitude, was emotional, reactionary," into a perfectly human tweet, holy crap you are judgmental.
>> ultimately a bad career move on the part of OP.
Not at all. I've done a lot of interviews and basically none of them required us trawling twitter. I think it would have to be something pretty heinous for me to not hire someone based on their social media crap. Definitely not something as mundane as this. This sort of hilarious cowardice about expressing feelings just makes me angry. At what point do we stop acting like these trivial, humanizing glimpses into a person are somethign that is a bad career move?
I had a big comment here, but I erased it. I think one story proves my point. When talking to google engineers one thing I noticed was that they considered youtube to basically be a joke. The reason why is that youtube has a messy python codebase. I asked them what they worked on while they were at google. They had rewritten an internal web portal for a support tool. From everything I can tell it was literally a mysql crud app.
If this is how success and failure are determined at google, it's no surprise how many of their products that people actually use come from acquisitions.
I don't know if I would rant on Twitter, but I would be as frustrated as well. Those 'tests' are very academic and I am not an academic person. I've not even officially finished high school. This test will not properly judge how well I can code or design software. I've been doing just that for 20 years now, and launched a few start ups, but I would fail that interview at the door.
I interviewed once for Google (at their request) and failed. For some reason they interviewed me for a networking position instead of a code one, so questions about TCP internals were not really my forte. I was just launching my second start up at the time and would have declined the job had I gotten it. I admit it does sting a bit to be declined - not just for Google, but for any position - even those you would decline yourself.
As others said, much more than 10% of Google's engineers don't even own an Apple machine. So, even if Google's Mac management team somehow uses Homebrew to manage the employees' machines (which may or may not be true: I have no idea, even though I used a Macbook in Google until recently for years), the percentage of Google engineers using that software is nowhere near 90%. The percentage of Google engineers knowingly using that software is certainly closer to 10% than 90%.
I think there is some validity to the general point, but I'm not commenting on that.
Just quibbling: I don't think anywhere near 90% of engineers use homebrew? Google development is done on Linux, and Homebrew is a Mac thing AFAIK. I have never used Homebrew.
Android development can be done on Macs but I doubt they use Homebrew. Certainly not for anything important.
Re: "and Homebrew is a Mac thing AFAIK." -> FYI There is a fork of Homebrew called Linuxbrew now. http://brew.sh/linuxbrew/ FYI.
> I don't think anywhere near 90% of engineers use homebrew?
Its just good ol' hyperbole man. No small children will die because its not exactly right, it just helps make a point.
It's funny because the guy actually thinks having built something popular equals being a good software engineer. Wordpress, PHPMyAdmin and so forth are all really popular but the code is shit and though it's used by millions of people, a _real_ software engineer will shudder looking at its source code.
Now, I have no idea what the code quality of Homebrew is, but just because he built something popular doesn't mean he should get a green light in every company. If Google is looking specifically for top-notch software engineers, they are probably filtering them very well with their practices.
Maybe they are only good on paper at that moment and don't have something like "Homebrew" on their Github, their knowledge is sufficient to perform work at Google. So why pick someone who has fame to his name, probably wants to get paid accordingly and thinks he is a hotshot because of his Twitter and Github follower count over someone who proved himself in an interview?
The first is not necessarily better than the latter.
And then you could've been just cool all about it: http://www.businessinsider.com/facebook-rejected-whatsapp-co...
This. @brianacton's response was super classy.
I strongly believe that the best kind of technical interview is to talk with the person about things they have done in the past, go into details and see if they are telling you bullshit. If the things are interesting, at least somehow relevant to what the company is doing and the person knows what they are talking about, it's a good hire.
One problem is that only experienced developers can do these kind of interviews, because you need wide experience, be able to talk about various technical topics and tell whether the other person is telling you stories from their own experience or some quickly learned facts.
It's funny, but the best experience I had interviewing at Google and Amazon was talking with the managers.
This is especially ironic given how much Google has complained they need more H1-B's because they can't find enough good devs.
Was it really because he couldn't do the problem, or was it that he didn't handle himself well in the interview? At two different interviews I was given logic puzzles just so they could watch how I went about trying to solve them.
> At two different interviews I was given logic puzzles just so they could watch how I went about trying to solve them.
That's usually what they say, but I've found that if you don't solve the puzzles, you don't get hired ever.
That experience doesn't mean that's just what they're saying. It could mean in those cases the person a) didn't solve them problem, and b) didn't demonstrate an approach to solving they problem they were looking for.
1 reply →
I did solve both puzzles, but I was told by the second company that they were quite surprised.
This just gets back to the question of whether you are hiring based on interview skills or coding skills. If someone has shipped code that shows high coding skills, why would you reject them based on interview skills, if it's a coding job?
You could still interview an experienced person. On the technical side, you could see if they're familiar with your specific stack, and know how to handle version control etc. Aside from all that, you can make sure they share the team's goals, are willing to use version control the way the rest of the team does, stuff that's not about skill.
a little bit more info
https://twitter.com/mxcl/status/608698037100244992 https://twitter.com/mxcl/status/608687283869503488
> https://twitter.com/mxcl/status/608687283869503488
That is the killer right there. The 23 year old recruiter responds to your rejection with: "The interviewer thinks you'll be better if you get another 6 months experience. Keep practicing! We'll loop back around to you next year!"
Thanks, I've been doing this for 15 years. I'm sure another 6 months is all I need to meet your delusional standards of ineffable ability.
I had very similar experience. This was one of the main reasons i decided to create this: https://github.com/sagivo/algorithms
Personally I don't really care about Google's hiring process. It's unlikely I'd ever want to work there anyway.
What does bother me is that other companies, who are not even in the same league as Google, start to copy their hiring process.
I remember interviewing with a digital ad agency a few years back and I swear, these guys thought they were Google. The number of academic trivia questions that came up, it was ridiculous.
In a way, I think Google has done a lot of harm to the industry in general by making others believe that everyone should have a hiring process like Google's.
I've been there as well. I interviewed at a design agency a while back. I nailed all of their puzzles pretty easily only to get there and realize I was going to be doing Wordpress hacking and other CMS work from 2010. I left after a few months because of how trivial I realized the work would be in the long term.
On the exit meeting it was relayed to me that they were having trouble finding people because no one could pass their tests and I was beside myself because I couldn't understand how they would expect someone with that technical ability to want to bang out Wordpress sites all day while there are 100s of people who would love to do that job and be very successful without ever even knowing what basic recursion let along the stuff they had in their test. Bizarre.
Also - a big motivation for work is learning. Didn't someone say "never apply for a position your qualified for"?
1 reply →
i had a similar experience with ita software, later acquired by google. i'd submitted a solution to one of their puzzles (which was actually very close to their business) which exploited a symmetry in the data and my solution produced results significantly better than anything else that they'd seen (per the engineer that managed that puzzle)
interview was brutal - lots of whiteboarding very artificial problems totally unrelated to the business and i just couldn't get excited about it and didn't end up getting an offer
hiring is tough, these things happen
You just have to know the basic data structures and some algorithms for them. Liked list, binary tree, Hash map etc... In the worst case, set up the data structure, then derive the algorithm. Do this in Java FWIW and make your life easy.
This is like knowing math and/or stats and applying it to a word problem.
Actually my pet theory is this: Interviews for experienced folks are more meant to keep them in their current companies rather than to filter the incoming new ones. This acts as a gentleman's agreement between the giant companies to keep their own talent pool semi-intact :) /s.
I mean imagine the amount of extra work someone has to put in to start interviewing. Take a break from your current work, Prepare your CS basics again, Prepare from interview question dumps online, read up / analyze everything the new company is doing and form reasonable opinions, practice white board coding / coding without an IDE, allocate time for any homework projects given, Psych yourself up if you are introverted etc. The alternative is just to stay in the current role and hope stuff gets better. 90% of the folks I know choose the alternative over the dehumanizing process of interviews. So many folks I know are good engineers get chewed up in interviews (both in my current company and elsewhere) because the process is pretty cooked. We are trying to see how this can be improved, but yeah - I just keep going back to my pet theory :)
I do agree with one of the commenters here though: At one point your resume should speak for itself. These are the kind of problems I would like LinkedIn to be solving instead of finding ways to spam me with recruiter deluge.
It's interesting the amount of hate and either rumors of bad experience or bad experiences directly. I interviewed for an SRE position last September and they were clearly trying very hard to make it a good experience no matter the outcome. I flubbed a couple of questions and they didn't make an offer, but the impression that they cared about my experience as an interviewee lasted. I wonder why my experience was so dramatically different from many here.
I've been invited to interview at Google three times. And they've declined to hire me three times. The last time I interviewed there the quality of the people that interviewed me was much lower than the earlier two times. I was still rejected, but I felt much better about working somewhere else.
I'm sure Google is still a great place to work, but its reminding me more and more of 1999 Microsoft. In fact the similarity is spooky.
Firstly, you're not entitled to any job you want just because you wrote Homebrew. If you accepted an interview with Google, then you accepted the fact that Google will judge you based on your problem solving skills, just like every other person was asked.
Secondly, I don't think this is a hard interview question; it's certainly fair. Did you expect to be asked knowledge-based questions that Google knows you're already good at? Questions specifically geared towards you? Or questions where Google can watch you solve a problem and be comfortable with the fact that you are able to solve coding problems? Did you think Google would hire you to write Homebrew? Or solve problems on teams Google has?
I think this person is just being unreasonable.
If 90% of Google's engineers use his software, it's reasonable to expect to be hired for continuing to work on that software.
That may be somewhat true, depending on how crucial and dependent Google is on Homebrew. But 90% of Googlers don't rely on Brew for work.
It is just a figure he made up to make a point about how popular his software is. Using his software outside the context of our jobs is no means to justify a hire. He should go through the same interview process as 90% (much higher than that actually) of Googlers.
1 reply →
just playing devil's advocate, but how do we know the reason for the no-hire was the reason the OP thinks it was?
It seems that almost everyone here knows better than Google how to hire employees for Google. Given that you can see why it is trivial to see through hours-long hiring committee decisions in just two seconds.
Edit: as pointed out by others, the hiring decision probably does not take a few hours, but under an hour. Still, the point is valid.
I'm pretty sure the hiring committees do not actually deliberate for hours on one candidate. Maybe in very rare cases.
1 reply →
Don't be silly. As hedbo says, it's obvious google just doesn't know what they are doing.
If their goal is hiring from industry, as opposed to from schools, I think I could credibly defend an argument that they don't.
(I think what they do now makes sense if they want the top of their funnel to be comprised mostly of recent CS grads, and I think that industry people with really high profiles, or that internal people really want, get to skip a lot of this evaluation.)
I have a lot of respect for Google (how could you not). That doesn't mean they can't be a bit clownshoes with recruiting.
2 replies →
answer: it wasn't, cause it's never just 1 reason.
Well, this thread escalated quickly! Am I wrong in my understanding that when a company rejects they don't specify why and hence "rejected due to failure to invert binary tree" may be a guess here?
"I never commit to memory anything that can easily be looked up in a book." Albert Einstein
It seems like this tests a) how much you want to work at Google and b) how good you are at memorize things.
A pair of good articles on just this kind of thing: http://www.unlimitednovelty.com/2011/12/can-you-solve-this-p... http://sockpuppet.org/blog/2015/03/06/the-hiring-post/
Nowhere near 90% of Google engineers even use Apple, let alone use this person's software for it.
As Google bragged in 2013 that it managed a Mac fleet of over 40k and with a workforce of 55,419 in Q1 2015 (not just engineers, 2013 numbers were about 10k engineers), that's 72%+ of Google's workforce using Macs.
Homebrew is at least one of the best package managers for Mac. I would be very surprised if it was not at least near the 90% mark...
Don't we have Universities for this?
I mean - what's the point of spending 3-4 years in an Academic environment that proceeds to then test and grade students on exactly how good they are, at the time - then only to perform the whole process over again some number of years down the road, with fuzzier results?
Seems dumb to me.
I've worked with people who could likely do very well on algorithmic tasks - (of which most software projects require precisely zero) - but actually deliver something of use... not so much.
When I used to interview people (I wasn't a manager, but I was senior enough to be entrusted to the role), I'd just ask about projects they had placed on their resume (to get a feel for their contributions) and then the rest of the interview would be focused on what the job was and how that matched with their career goals, why they thought they'd want the job, that sort of thing. The latter part was a bit harder because people are naturally defensive during an interview, so they can't be like "well I want an entry level web developer job so I can parlay this into something better in two years" (which is, IMO, totally an acceptable answer), but you can generally politely get the idea. Maybe I'm weird, but I just sort of think interviews should be more about determining fit than giving someone a lie detector test.
I get the puzzlers or whatever for a phone screens (quickly weed out people that are obviously unqualified), or if you're hiring someone junior who doesn't have work experience, but if you're at the point where you're bringing someone in you probably think they're minimally qualified, so it should really be about determining if goals are aligned IMO.
I like the spirit of this, but he may well have not been hired for a variety of other reasons besides this -- including how he attempted to solve the problem or how he handled not being able to solve it on a whiteboard in an interview.
I hate whiteboard programming questions and I don't give them when I interview someone - I give them a laptop with 10 different languages on it, and some data to munge -- I think it's a pretty decent thing for both parties.
Is it possible that technical impression was not the sole reason somebody isn't hired?
I, for one, agree with this kind of hiring process.
From my own experience - people that do well in such interviews are good generalists. On their own they will start discussing performance improvements and ways to parallelize the solution, it's a pleasure to have such an interview.
It's about enjoying problem solving and willing to keep your brain fit. It has nothing to do with memorizing solutions to some existing set of problems.
I've always wondered if during an interview with Google you answered a question with "I'd Google it" what the reaction would be.
The response would be "I want you to come up with the answer yourself."
>you answered a question with "I'd Google it" what the reaction would be //
"We don't look kindly on trademark genericization."??
These interviews are biased towards new grads ...
GEORGE: You know what I do at the Yankees, when one of these old guys is breathing down my neck?
ELAINE: What?
GEORGE: You schedule a late meeting.
This thread is weird.
The people vilifying Max or saying "duh you didn't get hired, Google requires awesome people" seem to have a totally warped sense of exactly what Google engineers do day to day.
Blows my mind that there are so many people defending this (well-known and pretty much taken as a trade-off) lapse in the Google hiring algo and instead making it seem like Max's fault.
I don't think loudly (and impolitely) complaining about being rejected at a job application can, ever, be the smart thing to do.
It is not. IMO it's a pretty ballsy and idiotic thing to do. That's partly why I am not too active on Twitter. I have a lot of controversial, unpopular opinions that I wouldn't want a potential employer to get a whiff of.
Google really does only hire individuals who are strong in theory.
Maybe we are jealous. We wish we had the brains of the people getting into Google. I can say personally that I envy these people.
The fact that they don't mind being treated as numbers maybe says something about these people too. They are cold. Their ego must be pretty big too if they make it into Google.
Someone should do a study...hehe.
I remember a story from college graduation. A friend contacted an alumni from the university. The alumni worked in the semiconductor business. One of the questions he asked the alumni was: "How does he select a great employee?"
Alumni's response that it is exceptionally tough. He shared an anecdote about one of his best hires.
The alumni wanted to test the interviewee's knowledge in different areas. He asked a question on diodes - it might not have been diodes, but for the sake of the story let's stick to diodes. The interviewee replied: "Hold on, I am not one to know about it."
I have not worked at Google and I do not think I'd pass its interview process. It is unlikely that I be diligent enough to make Homebrew. Nevertheless, I am inclined to the idea, that being knowledgeable in all tested areas would not reveal the personal fit necessary to make a great team.
It seems that google wants to have code monkeys instead of creative software engineers. This is a common problem of big companies. IMO it is one of the reasons they get stuck with innovations. Of course also the interviewers don't want to hire people which are smarter than they are because of their own career.
As someone who struggles to learn by rote as opposed to learning by practical means and has been both hired and declined by the Google recruitment process. I can't help but agree with his sentiment.
The recruitment process (at least for experienced engineers) should be little more then "can I work with this person". The 6 month probationary period that follows the hiring process should be used for "can this person do the job well". But that's just my experience, and it seems to have worked well.
Regarding the same academic questions everybody gets asked in every development interview, I feel Einstein said it best with "[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."
Google is about monoculture (certain type personality) - and from their business perspective it seems that approach works. Why to change it?
If they try to invent something new or in different market they might need different type of people but as of now ads business is cash cow and they would be crazy to try change it.
Without commenting on whether this is a good interviewing strategy, surely the point is to sacrifice some potential good hires in favor of definite good hires. In other words, you might be able to write pretty good code even if you can't solve problems on a whiteboard, but, given a choice, why wouldn't we just choose the people who can do that, too?
I think the stated philosophy of interviews like this one is that a false positive is worse than a false negative. Every single one of the responses to that tweet either misses that point or sounds like little more than defensiveness in the wake of a bruised ego.
You might disagree with that interviewing strategy, but you're not addressing it directly.
More or less agree with this. I'm also a Google reject (didn't make it past the phone interview). I didn't take the rejection personally. I don't see how the interview process could be drastically improved. They get a lot of applications and they need some way to filter - there is a standard and it has to be met. With the sheer amount of applications that Google gets it's a virtual guarantee that there will be a subset of people taking the piss regardless of what the interview process is like.
I don't doubt that the engineers who manage to jump through all those hoops are sensational. Personally in the end it just dawned on me that I didn't want to work at Google that badly.
The whole Twitter exchange is a pitiful sour grapes circle jerk, and I'm surprised that it's provoked such a massive response.
> why wouldn't we just choose the people who can do that, too?
I agree with your overall point (why not both?) but how does the interviewer know they can do both if they are only tested on their ability to solve problems on a whiteboard? I don't have a solution (that scales) to this problem but I tend to agree the types of whiteboard problems typically seen in interviews are a bad way to identify good developers.
This guy sounds like a tool. Sure, he's accomplished, but his website and linkedin are dripping with self aggrandization. "Splendid Chap" -- cringe. My hunch is that they didn't hire him because he didn't seem like a cultural fit.
How can we see if this technique works? There are two methods try to know something: deduction and induction.
First a little deduction. Let's try to be explicit about the theory behind this technique.
It's safe to assume that the job will NOT consist mainly of cranking out binary tree inversions on whiteboards while being watched over. So obviously we're hoping to make a correlation with something else. Assuming the candidate was not tipped off and learned this particular puzzle, perhaps we are correlating to an ability to rapidly create novel solutions of long-solved algorithms without reference tools.
But is that what the new hire will be doing? Probably not.
We could continue down this path, identifying ever more removed correlations until we get to something that the job actually demands. This probably involves solving hard problems like naming things. [1] But by now our theory stands on pretty thin ice indeed.
In any case, all of this deduction is theory making. It's not knowledge until we attempt to falsify [2] it via induction. The human mind constantly induces hoping to verify our deductions. We reason, observe, conclude and repeat. We're good enough at it to survive, but that's about it. Lucky for us, science came along. Today's technical hiring is at best alchemy.
A interesting company called TripleByte [3] is trying to apply induction (first for YC companies). They specially shun on white board coding and puzzle solving tests in general. I will be interested to see how they fare and whether their learnings are adopted more broadly.
[1] http://martinfowler.com/bliki/TwoHardThings.html
[2] http://en.wikipedia.org/wiki/Falsification
[3] http://techcrunch.com/2015/05/07/triplebyte/
It is pretty well known there are a lot of false negatives in the hiring process since it is so much worse to make a bad hire than it is to not make a good hire. Sounds bad and it is, but no one has a better solution than try again in a year.
IMHO, I don't think it requires any practice to be able to invert the binary tree. It is so trivial that it only requires a very basic level of programming skills. I agree whiteboard is generally broken, but for this particular case, I don't think Google is doing wrong. We can think another way, if some company hires people based on his reputation instead of the ability of doing actual work, I don't think it will survive. In this particular case, you just didn't show your ability of doing actual work, that's it. I am glad to see that Google prefers ability of doing actual work to reputation.
What's the due diligence like on the hiring side during an acquihire by Google?
In my very limited experience? None. They just trust the company they acquired to have filtered you properly. They do ask for references (like academic records and so on) but that was about it.
Without discussing too many details, I believe the issue with Google's recruiting process is it was designed when the company was smaller and it follows the philosophy that anyone that goes through the hiring process should be ready to be thrown into any of the many Google projects and be able to function immediately. That's not strictly true anymore.
You have some divisions that are extremely hardcore or require very good knowledge of a particular field (think Google Cloud Platform vs. Android Kernel vs. Chrome vs. Search, all completely disparate projects), but there's also work for people that don't need to hold a PhD from MIT (think front-end development.)
Hmm, it depends a lot on the size/type of company and reason for acquisition. If it's closer to a acqui-hire where the employees of the "acquired" company cease development on whatever they were doing and eventually just get staffed on a Google project, then they will MOST LIKELY do technical due diligence on each team member. It's common for only part of the team to get an offer to join.
Good engineer you didn't hire is not much of a cost to the company (other than resources wasted on hiring process and perhaps some bad publicity).
On the other hand bad engineer will stay at the company, lower standards, damage morale and set bad precedent to other engineers.
Being engineer myself, I feel much more motivated working in an environment where you can just assume, even before meeting, that the other person is intelligent and motivated. You trust hiring process to filter everybody else so you don't have to subconsciously distrust every person you meet.
This comes at the cost of situations like that.
I dont want to be an ass but how do you not know how to invert a tree? Anyone who knows how to write a tree and traverse it should be able to do this. If you ran out of time coding it then that's different.
Not even. If you know what a tree is, and you've written a couple of recursive problems on trees in your life, then you know most of them are approximately 5-6 lines of code.
If you're spending 45 minutes writing 5 lines of code, it is not definitive, but certainly a red flag.
Nobody in this thread has even been able to define what inverting a tree means. (Reversing or mirroring? Sure.) My search for how to invert a tree led to a bunch of fairly hairy academic papers.
If you have a definition, please elucidate.
An Indian eCommerce company wanted to test my mathematics while interviewing me for a VP of Marketing role. I had to tell them I won't fit into their company culture, let's not waste time further.
My 2cents here - I respectfully declined to answer any JavaScript/CSS questions prompted by a recruiter.
Being a front-end guy, I proactively request for hiring manager or a senior front-end engineer from the team.
What's the practical point of performing such an operation?
It's similar to reversing a sorted array, though I can't think of a reason I'd ever do it.
We're trying a different approach at Sourcegraph. In addition to looking at a candidate's prior work in open source if available, we ask them to complete tasks that approximate the job as closely as possible (i.e., coding on a computer): https://sourcegraph.com/blog/programming-interview
Would love to hear people's thoughts and feedback!
Yours sounds like an approach that measures how well someone codes in a vacuum, instead of how they operate on a team. It very much skews the results...
Not to mention for a qualified professional candidate, it feels an awful lot like you're asking them to work for free.
In addition to asking them to write some code, we also have each member of the team interview them onsite to get a sense of how they'd interact as a member of the team. The challenge does take a few hours, which is longer than a typical phone screen or single onsite interview, but because it lets us focus on getting to know the person onsite rather than go through a gauntlet of whiteboarding interviews, we think it actually saves time for everyone and is a win-win. Obviously, every candidate is different; we think of this not as a rigid template, but a better default option than whiteboard interviews. Thanks for your thoughts!
If I write working code, do I keep ownership? If you use my idea for improving your product, will I be compensated, even if you don't hire me?
From your blog post:
> The code is reviewed by the interviewer > but probably never run.
This is what surprised me during an interview with Facebook. I tend to write a little code, run it to test it out, write a little more, test again, and so forth, you know, rapid iteration or whatever the fancy industry term is these days. The interviewer gave me these silly little shell scripting problems (silly in that they ought to have been easy and clearly had nothing to do with real life work) but instructed me _not_ to run the code. How the heck am I supposed to know if I've solved the problem? How will I know if I even have the right approach? I don't consider myself an expert software engineer and so probably not a fit for the position, but that style of interview definitely hamstrung me.
For what it's worth, being able to run programs "in your head" is a very common skill required of Computer Science undergraduate programs, where you're required to write programs of medium length on paper during exams. You should be able to write out, follow along with, and reason about the correctness of a program that can fit on a single piece of paper without having to run it. Programming hyper-iteratively is not really a good thing, especially not in environments where rebuilds or test runs can potentially take hours.
Another reason not to have candidates run the code is that they tend to get really hung up with debugging trivial errors. I've conducted a fair number of interviews either way, and the white board interviews were usually more pleasant experiences for all parties than the interviews where the interviewee was expected to execute the correct solution in front of me. The latter almost requires giving them some kind of web or library API access, which then just makes the distractions worse. I don't want someone worrying about what the exact name of a sort function is; that's not what I'm trying to evaluate in an interview.
I would never do a take home test for an interview. I did that once and it was such a waste of time.
i've done three over the years, complete and utter waste of time.
i also had some wierd binary tree questions when i interviewed at yahoo, was a total turn off as i was interviewing for web/front end related job. which probably would not have used any of this type of logic, ever.
The problem with google interviews and tech interviews in general is that it is almost impossible to capture what makes a successful candidate in a couple of mini interviews. They don't even pretend that what you do in the interview is what you will be doing in an actual job there. Most of a developers time is spent in meetings, understanding their problem domain, writing documents, or reviewing other developers documents.
I don't even bother responding to any of the Big 4 when the reach out every few weeks. They all ask these ridiculous questions.
Wrote a blog post about exactly this problem: optimizing interviews for fancy algorithm solving, when the position's daily work is nothing like that:
http://www.developingandstuff.com/2015/05/why-i-dont-do-codi...
Can someone please help solve the problem? I have created a bounty: https://www.bountysource.com/issues/21606252-please-solve-bi...
Anybody noticed an istx25 stalking each tweet-job suggestion and ultimately getting busted[1]? :D
[1]: https://twitter.com/markmcerqueira/status/608914346706657280
Doesn't this contradict an interview with Senior Vice President of People Operations
http://www.wired.com/2015/04/hire-like-google/
This was years ago but a google interviewer asked me a make a complete copy of a directed graph (i have to do cycle detection). I was given 45 mins total and I failed. I cursed myself for not being good enough. I haven't forgotten it yet.
Google, if you have really smart people working for you then make a new problem solving question for each person you interview! The current interview standards highly promotes memorizing stuff which is pathetic.
I wonder what an interview process at Google with Linus Torvalds or Theo de Raadt would be. I take for granted that the interviewer would not had a clue about their accomplishments.
Would they manage to pass the process?
Personally, I'd prefer to work at a company where 90% used pkgsrc.
At least he didn't get put off because his CV had the wrong font. It was actually a technical question. They probably have binary trees that needs to be reversed everywhere in Google :P
the tech interviews are so broken.
who does dynamic programming on a white board during a work day?
it's like you are recruiting an army, but testing people's gymnastic skills. they should test street fight skills.
I don't know, inverting a binary tree seems like a pretty easy task. If I were hiring a senior developer (to code as a primary task) I think it's a reasonable fizzbuz.
Hiring/Interview process is broken and not only in Google
Was hoping to gain some insight to improve interview cycles here but instead just have agita.
Jobs come and go, great work is always great work, but friends are what I remember most.
yep, hiring is broken.
https://news.ycombinator.com/item?id=9689232
Let's hope he makes a product that google wants at some point and then pays him millions (or more) for it. (like whatsapp and facebook).
He sure has an awful lot of his self-worth wrapped up in whether he gets a job offer from one specific company. It reminds me of being interested in a particular girl in high school.
At a certain point, you learn that there are other jobs out there, and maybe the one with the biggest name isn't the best one. I certainly wouldn't be the least bit offended. Not when the market is flush with high-paying-jobs-a-plenty, particularly for someone with his background.
Probably could have just Googled the answer.
I took my google interview as a gift from them to me. It showed me that I was mistakenly interviewing to become a cog in a terry gilliam-esque corporate machine, and that made me think hard about my path in life, and what i really wanted out of a career.
The best part is that someone important at Google say this and no matter how they respond it's just funny.
change the license, add a clause saying google can't use it, and sue them tomorrow
I know this was supposed to be a joke, but he can't retroactively change the license for the current released version. Any license changes will only apply to future releases.
i didnt understand can some one explain TLDR ?
guy made Homebrew, an OS X app, interviewed at Google; guy was rejected; guy rant on twitter
Last week I walked away from a Google offer that included a 70% raise. A large portion of this was a rather dehumanizing interview process, along with the realization that the process doesn't select for people I want to work with, and weeds out most people who I do. I managed to do just enough in my interviews to squeak through, but in doing so realized that it wasn't for me.
Walking through the cafeteria made me feel like I was back in CMU CS again, in a bad way.
I think you may have left with the wrong impression. If you ask Googlers or Xooglers alike, most agree that the people here are actually the best thing about Google. Like anywhere else, there are some bad apples, but compared to most other places the people here are on average more talented, nicer human beings and more helpful. Certainly compared to your typical startup or other BigCo.
In my nearly 3 years here, that is my experience as well. I've also spoken to many engineers who have left who lamented the quality of their fellow engineering talent at their supposedly 'hot' startup, compared to their former team at Google. Or having to deal with way more unprofessional (or crazy) management, prima-donna teammates, etc.
As far as my specific interviewers are concerned, I liked 7 of the 8 as individuals, which is great. What I didn't like was the company felt like a monoculture. Same schools, same majors, same pre-education background. Everybody looks the same, dresses the same, etc.
The process, on the other hand. Ugh. I have zero respect for Google as a company after that.
It starts with the standard phone screen/day-long onsite/hazing ritual. Then come phone calls with teams, and teams saying "yeah, we want you", and me saying "sure, sounds good". The recruiter basically said "time for the higher-ups to rubber stamp this, and here's the $$ to expect". Someone up the chain said "well, we're not so sure, let's haul him back here for another round of onsite interviews". Which I did, it went through the same process, and the response was "well, maybe not you for this role, but lets set you up with more teams".
All of this finally goes through, and I get an offer. Then there's a negotiation that goes something like:
Me: I'd like 4 weeks to think about it while a couple of other applications come back (keeping in mind they've dragged this on about 2 months longer than it needed to be).
Google: You get 2.
Me: I'm at a conference week #2, but I'll do what i can to get a decision to you Friday.
<Fast forward to monday of week #2>
Google: Have you made up your mind yet?
Me: I'd like to look at my options, and I'll get back to you COB Friday
Google: It's really important that we hear beginning of day Friday
<Fast forward to wednesday>
Google: Have you made up your mind yet?
Me: No. One of the options I was looking at is now off the table.
Google: So WTF are you waiting for.
Me: The other options
<Fast forward to Thursday>
<Phone rings while I'm at the conference>
Me: You can't pay me enough to deal with this.
Maybe no individual involved is a prima-donna, but the ego showed by the company as a whole through the recruitment process is stunning. It felt like I was dealing with the star quarterback who never considered that when they asked someone on a date, they might get turned down.
6 replies →
In my experience pretty much everyone is excellent, apart from the lower level non-engineering managers. These tend to be grads from top schools who have zero previous work experience. I encountered at least three or four in my time at Google who were just out to prove themselves and get promotions and regularly threw their teams under the bus.
3 replies →
> Walking through the cafeteria made me feel like I was back in CMU CS again, in a bad way.
Really smart people who are really insecure about their intellect?
>Really smart people who are really insecure about their intellect?
Condescension. Condescension everywhere.
It is people who are at the top of their game that are the nicest. My old CEO, who is head of a company everyone here probably knows about, was such a chill and friendly person.
And that insecurity manifests itself as a facade of arrogance and condescension?
4 replies →
That sounds great. Can I have your 70% instead? I'll put it to good use.
Maybe this guy wasn't quite arrogant enough to work at google, I mean he seems pretty arrogant, but I think you really have to be extremely arrogant and up on a moral high horse to work at google.
As goes the recruitment, so goes the employment.
If you wanted to work for an organization where everyone likes to show off their skills to one another in the interviews, you'd have gotten the job, and you'd be one of them.
The best interviews I find are like a first day of work (but unpaid). Your experience and skills are established by resume and portfolio. The interview shows whether you can work with the team and wrap your head around the org's problems. If you're having to show off- well, that's how your work will be, too.
Google's interviews convinced me, years ago, that there's no way I'd ever want to work there. And that feeling hasn't changed one bit. Much like FB, it's an org whose coding needs are really pretty trivial and the real work was done and finished a long time ago (but there's plenty of need for debugging, egos especially). If you want to work there and surf the gravy train, cool for you.
> Much like FB, it's an org whose coding needs are really pretty trivial
I was with you till riiiiiight there. Google isn't just a search company anymore they're working on lots of very interesting non-trivial things all around the company.
> Google isn't just a search company anymore they're working on lots of very interesting non-trivial things all around the company.
Right. And I really doubt that people like Andrew Ng or Geoff Hinton or Sebastian Thrun were asked to invert binary trees....
And Google engineers aren't the shit either. Their Java libraries are large and unwieldy. They would learn something by taking an example from the apache libraries - clean and straightforward, focused and small. I hate working with Google code.
Maybe he was applying for the role of Lead Binary Tree Inverter. The astute will notice that he repeatedly ignored opportunities to confirm or deny that the position for which he applied was indeed, Lead Binary Tree Inverter.
Google Interviewer: "so, how would you do X, Y, or Z?" Ruby Developer: "errm.. gem install X, gem install Y or gem install Z?" Google Interviewer: "next!"
Am I missing something? Are we talking about getting a left-to-right mirrored version of the tree? If so, I'm amazed. This is a technical community, and people who presumably know how to program are moaning that this is some kind of "academic" question? Are you guys for real?
Why is his profile picture the attractions road sign as seen in Scandinavia? :-)
Perhaps he's a fan of Susan Kare :-)
I don't get the message you're trying to send by this reply... and yes I know who Susan Kare is.
1 reply →
big ego, looks like they made the right choice then
Max should add code in Homebrew to check if hostname contains "corp.google.com", and exit with a message that Homebrew can't run inside Google.
Petty, but fuck em. They don't want him, they shouldn't get the fruit of his work.
Disclaimer: GoogleFanBoy here, feel free to ignore or downvote.
So, I've interviewed with Google twice. Once was 3 years ago, the other was like 2 weeks ago. They contacted me. The way I see Google's interviews is like referee in Football(soccer or "Futbol"). Sure, you need a certain amount of skill to play in the World Cup but you winning or losing can, and often enough does, come down to a controversial referee call. You end up losing out to a team that did a handball - https://www.youtube.com/watch?v=-ccNkksrfls , but that's just how it is. What makes me like watching soccer so much is the same thing that excites me about Google's interview process. Yes, there is heartbreak and anger. Just like World cup fans get angry when their team loses because they were denied a point for an off-sides call even when the player was nowhere near off-sides.
--- Is Google's interview process fair? Nope.
--- Would I subject myself to their futbol-referee style of judging candidates again? You bet.
--- Do I think they should make their process more fair? Nope, let the drama and _justified_ rant posts continue. Just like I want the unfairness in futbol to stay as is. I was one of the people against putting the microchip inside the ball to know for sure if it crosses the goal line. I want the drama of a ref having to call it and sometimes getting it wrong.
I know people, especially on HN, love reliable & repeatable. I do too, except when it comes to dealing with humans.
Great, another self entitled engineer who thinks Google owes them a job because they are sooooo good (Which, maybe they are good at some things)
But how about Google didn't give them a job because this is how they handle failure, embarrass an entire company on Twitter to punish them.