I remember feeling like I had done fairly well, sans one interview. The interview in question was around development experience in C. The interviewer, very early on, asked how to redirect stdout. I suggested using freopen, and he said that wasn't allowed.
Well why the hell not?
The answer he was actually looking for depended on the knowledge that open() returns the smallest possible file descriptor number -- so close stdout, and simply call open() again.
I didn't happen to know that particular detail at the time. It derailed the entire interview. He was fixated on this one very specific piece of knowledge. And the worst part is not only does his approach make your code less clear, there are also contexts under which it wouldn't work.
I don't know if that particular interview was the reason for my not being offered a job.
I did end up hearing later on about hiring from a couple of Google engineers at a tech conference. They said that it is quite common that Google makes you interview two or three times.
I suspect the reason is to make you feel a sense of gratitude for being hired. And so you don't quit.
That should never pass any code review.
It's the kind of thing I might do but I'd freaking TELL you, and in time so that you know how to handle the rest of the interview.
I don't think it's wrong to have a test that exceeds the range of the tested. Really no one should ever ace any test, else the test is insufficient. Thermometers don't just go up to room temp. So a sneaky question that only a truly insightful and thorough person might get, and ballsy enough to challenge the interviewer, and with good enough judgement to know when it's right to talk back, that I myself might not get, is fine. But it's there to identify the exceptional, to provide room in the plot for the spikes instead of clipping, not to kill everyone else.
I sometimes give people way too much credit though. I bet it was all face value.
IMHO, that's what makes writing interview questions so hard: you really have to know the topic inside and out to know (or at least recognize) all the answers. If you only know one, your question is shit and you might as well have the applicant play guess the number.
If I as an interviewer ask that same question and get the freopen answer, and let's say its not one I'm familiar with I can just simply say "I'm not familiar with freopen, could you tell me more about it?" And then I listen to what they say. A competent developer who is worth their salt will be able to summarise the gist of it quickly. Then if I want even more info I might describe the solution I know about and ask the interviewee to compare the two solutions, describe the pros and cons as they see them. What I would be looking for is the proof that the person I'm talking with is able to communicate complicated things clearly, and can think about code.
These skills are exactly what one needs in their everyday work, so why not use the opportunity to evaluate them? Does anyone really think that the goal of an interview question is to query if they know that specific trivia you happen to know?
And besides if I have doubts about that they are just hoodwinking me with this freopen I can just crosscheck what they told me with the reference. If it turns out to be not a thing at all, that's not a good sign and I will not recommend them to be hired, but otherwise they passed with flying colours.
If you just fixate on your specific first solution and choose to dig in and argue over it despite your interviewer not liking it, it's not a good sign you're someone pleasant or frictionless to collaborate with.
Trivia questions like that are absolutely awful for demonstrating any of what you're talking about. There isn't any creativity involved. And it's not like the guy followed up with something like "where would you go to determine the answer?"
There were 6 or 7 other interviews I went through that had interesting, open-ended questions that allowed me to bounce ideas off the interviewer and share my thought process. This particular interview was not one of them.
That sreet must run both ways or it's an invalid charge. If you're reasoning is valid and the interviewer doesn't provide better arguments, then it's the interviewer who is not pleasant or frictionless to work with.
In my younger years I remember being in awe of the simple fact that a recruiter from Google actually reached out to _me_.
A decade changes a lot, though. I don't think I would ever want to work at Google now. I'd be curious to know if my shift in perspective on Google is common, and if they're even aware of it.
This changed. I interviewed 7 years ago and they have fixed this, judging by the questions I got and the interviewer training I received. Using trick questions and fixating on "the" solution was explicitly called out as bad.
Of the questions I received two were open ended design questions and the rest was about algorithms and implementing them.
I did very well with data structure questions, and had one difficult interview and one question about sharding a globally scaled system. I had never dealt with anything on that scale, and didn't even know how to think about it.
I realize that there was a gap in preparation, and I'm confident that that one interview out of 8 is what nixed my chances.
I had a similar, but not the exactly same issue recently, and about 2/3s through the interview I was stopped and the interviewer kinda poked at my resume and successfully deduced that my prior work experience was just not at the level/scale the company was looking for. How do you prepare for that without having actually worked on that scale. Oddly, I ended up getting an offer for a different position after that though.
I can read about subject X all I want, but I would never be confident enough in an interview at just that. And large scale applications isn’t something I can just something I can replace with a side project.
This is one of those cases where you can be proud of a criticism rather than embarassed by it.
There are better ways to gauge knowledge competence, but this is an easy way, so people do it.
This sounds like a really bizarre and very specific question for the interviewer to fixate on, unless it was particularly relevant for the position. Knowing the details of how to best do the redirect doesn't seem relevant for a generalist interview; this is the kind of thing you end up, well, googling when you need to do it. I suppose a kernel developer is supposed to know this though, were you applying for kernel development?
C only came up because I was asked to provide a list of languages I knew, and rate on a scale of 1 to 10 how well I knew them. At the time when I interviewed, I said I knew a little C (I had used it in a bunch of my CSCI coursework and some small personal projects).
So yes, it was an absolutely stupid thing to focus on.
… but that’s exactly how conversion to string works, so handrolling an algorithm would likely be around the same speed.
I don’t know enough about the question, but it’s possible that the interviewer wanted to test this specifically. I’ve had interview questions which were literally “implement itoa.”
In this case where itoa was part of a larger question, if I was conducting the interview I would let you convert to string for now so you could continue, but I would let you know that I wanted to revisit the digit conversion later.
This interview was not the highlight of the interviewer's day. They most likely didn't overthink every angle and every word. They probably were on autopilot looking for some pre-defined criteria - and could care less if the candidate was qualified, accepted, or rejected.
This keeps coming up but is worth repeating – the goal of any large company's recruiting process isn't necessarily to hire the best possible candidates 100% of the time. There are always trade-offs. Every interview takes time away from employees. There is no way to predict 5+ years of performance from a 1 hour interview slot. Education, credentials, experience are all valid data points but again not a great predictor of success. Hiring is ultimately an exercise in balancing many different priorities and hoping for the best result. Some able candidates miss out, which sucks, but that's factored in. It's also much more important to keep a bad candidate out than ensure every possible good candidate is hired.
Every single one of these articles/tweets/anecdotes boils down to "Google didn't hire me and I'm very smart so their system is totally broken".
In other words, google's success says very little about the quality of it's hiring process.
That's such a huge difference from their hiring practices now.
Beyond that, there's no point. You won't discover whether the guy who passes is the kind who writes undocumented spaghetti, or if he doesn't know how git works, or if he doesn't know how to assess an OSS library.
What seems to always work for me, having hired dozens of people over the years, is a technical chat. Tell me what's interesting. What's the difference between this language and that one? Why did you make the choices that you did? You talk, not me.
Someone who can say substantive things about different techs has spent the time. Someone who has formed opinions has spent the time. Someone who's spent the time won't run out of opinions.
I will concede that while this has worked for me, a hiring manager in small financial teams, there's a fair chance it won't work for Google. For one, nothing I've just recommended can be measured. It also can't be taught to junior interviewers, and thus relies a fair bit on the reputations of the firms on the CV for filtering. Finally, and perhaps most importantly, there's a big difference between the decision maker doing the interview and someone who is just an advisor (ie an agent) for them, in that the agent needs to have something concrete to say to his boss as well.
I feel like this is a very bruised ego here. I'm not saying any interview process is perfect, and I think a lot of them are very, very bad at accessing the capabilities and value someone provides, but same for University.
No. That logic is just superficial pattern matching.
The point of university is to spend the time and energy to master the subject, test or no, and the knowledge gained is usually valuable in and of itself. The kind of interview prep in question is basically learning how to jump through some arrogant company's hoops, which likely has little to do with anything, including their actual job.
Really? I think most people go to college to get a good job before all else. With that line of thinking, an interview is just another of these “tests”.
But you make a good point about these arrogant companies administering tests. College faculty are never arrogant, but always humble like this guy in the article who just can’t chalk his failure up to being a human being.
People are accustomed to jumping through hoops to pay an already rich institution several thousand more dollars.
In contrast, you study for Google's exams, and if you pass, Google ends up paying you.
It's reasonable for universities to have that expectation because being a university student is considered to be a full-time occupation. It's unreasonable to have that expectation for working professionals. But Google and other big tech do it anyway because there are thousands of people waiting in line to interview.
People rail against these because they are not only brutal, they are a waste of time. We also suspect they have little correlation to actual employee performance once hired.
Steve Yegge, ex-googler, also mentioned the common phenomenon of the interview anti-loop that used to happen at Google: two interviewers in your queue would not have hired each other, so the attitude/knowledge which would satisfy one of them will actually get you rejected with the other.
By contrast, interviews are extremely condensed and an interview doesn't guarantee you a job in the same way that completing degree requirements guarantees a degree. Employers also have the option of firing you later.
Btw, be totally clear, this has been a bad outcome for Google. Google's failure has been well-hidden by the fact that they have a monopoly product that is a cash machine requiring low/zero marginal investment...once you start from that premise, you realise that management has destroyed monumental amounts of capital (your comparison with university is very apt, Google is functionally a bureaucracy operating like a 11th century monastery, you have to spend years studying pointless trivia to get in, a totally institutional mindset).
When I've had power over the interviewing process it's always been enlightening to ask the interviewer to take their own interview. I'd be willing to bet most professors can pass their own exams; the same hasn't been true of interviewers.
This is the cost of fighting professional standards for the industry as a whole. I'm not necessarily for that, but I don't know what the sensible alternative is to inter-corporate pissing matches and job titles that are practically meaningless. Nobody who knows how to build a house or fix a car is going to spend months playing puzzle games about those topics. They are just going to find an opportunity to do the work they enjoy somewhere else.
Edit: to remove unrelated rant.
On the other hand, I get the sense from people who've been through the Google treadmill that the problem isn't so much that it's hard like university courses are/can be but that it's arbitrary.
In the long run you might end up with better results if you don't even try to identify the one optional choice and only focus on weeding out false positives, leaving the rest to a diceroll.
(I'd be surprised if what happens at Google wasn't a weird compromise Frankenstein of both)
I never hear reasonable alternatives to this. Surely you'd rather a coding exercise than a take home coding practice you never feel will be complete enough for people. Or to do what Basecamp does and work for 2 months only to be given the boot.
Once I'm in the university and enrolled in classes, I'll know what to focus on and I'll be willing to study hard for tests.
I know some people see it differently, but I've always considered multiple potential employers simultaneously and I definitely haven't been willing to play the "devote weeks of your life to try to get hired by a specific company" game. On the other hand, some people find that worthwhile, and more power to them.
Companies pay me to work.
They are welcome to pay my consulting rates of $300 per hour for interview questions.
- Google Foobar to get someone to notice my resume
- First form that asked for general information
- Second form that asked weird behaviour questions like "Do you think people can change"
- First interview with regular leetcode questions
- Second interview was waved because of foobar
- Third form to write your interests/motivation for matchup with a team (No guarantee of having an internship at that point)
- Dropped the whole process because I got an offer somewhere else
The whole process spanned maybe 3 months.
The year after that I re-did the whole process and was ghosted by the recruiter after the first interview, I assume that was because I did not rank high enough and they were waiting to see if I'd make the cut or not.
This process (and the big version for FTE) works to weed-out candidates that aren't motivated to work at Google and I just don't see how else they could be doing it. People have to understand that recruitment at FANG is painful because you will get thousands of SDE applications and you can't really take the time to treat everyone "right".
It does suck.
> "It just never seemed to get through. They were so focused on whatever categorization they had chosen and it was fixed," he said. "I think something in their processes meant they weren't really looking for a fit between a person and a job. It felt to me that they probably had a recruiter who was looking for a certain role. Once they put you in the pipeline, that's the role you're in."
Didn't Google at some point decide a guy who developed a VM or interpreter or something that they were using in-house was only good enough to be a sysadmin for them?
You're probably thinking of Max Howell, the maker of the Homebrew package manager.
https://www.quora.com/Whats-the-logic-behind-Google-rejectin...
> You're probably thinking of Max Howell, the maker of the Homebrew package manager.
My memory is very fallible, but I don't think that's it. I'm sure there are several similar incidents, and the one I'm thinking of definitely involved a sysadmin role and maybe even an offer. The issue was that the role was an insultingly bad fit, not that a talented person got rejected.
I interviewed for javascript vm/browser runtime stuff multiple times and until the last interview cycle I kept getting assigned to interview with people who worked on android apps or cloud storage infrastructure. Complete mismatch. I don't write Java, dude.
SRE is an odd department inside Google because they want people with an unusually wide mix of skills. They want a lot of people who are software developers and have those skills but who also have networking, UNIX sysadmin and maths skills. The requirements and interviews are/were more intense than for regular SWE roles. My interviewers tested all of those and more. At the end even if you just want to write software you get an offer that boils down to "it's SRE or nothing" because frankly, not that many people want to do SRE work, so they have to be a bit muscular about it. Normally they point out that after a year or two you can transfer if your job performance is good enough, which is what I did.
Anyway this Watt guy sounds like he's blaming Google for not giving him a free choice of roles. That's not a demand made of any normal company. Usually it's understood that companies have particular needs and are looking to fill them.
The kind of folks that can plow through hacker rank etc want to show everyone how good they are, even candidates. Google's process may result in selecting good SWEs, but it also selects for bad interviewers.
I hated those type of interviews when I used to interview (as an interviewee) for programming positions. I am the kind of person that cannot multitask at all: I sometimes even have to close my eyes when I am thinking something before saying it.
Nowadays I am on the other side being the interviewer for programming positions. I make it really clear at the beginning of the coding part: Feel free to shut up and think, focus on writing the code you'll write, and we will talk about it once you have finished.
Each time until my last interview cycle, they seemingly assigned me interviewers at random and they were usually a terrible fit. I'm a games/systems programmer, so think C, C++, C#, etc. Console games (PS4), PC games, etc. Never shipped a mobile app, don't have much Linux expertise, don't list them on my resume. Haven't written Java since the J2ME era.
So naturally, I kept getting assigned to interview with people who worked on the Android Play Music app, or people who wrote Linux cloud storage infrastructure (think talking to storage hardware directly, etc) in Python and C. Inevitably, it was impossible for us to have an in-depth technical conversation without a lot of overhead because the disconnect was too big. Sometimes they'd ask me to whiteboard and there was no appropriate language for me to use that we both understood. At the end of each day I came away having had interesting conversations with people but it was consistently a failure of an interview process, so it wasn't a surprise that they never made me an offer. You could tell that this messed up interview process was also an issue for interviewers - I had a couple different interviewers get really combative or frustrated because of the disconnect, in one case borderline abusive.
Then finally a team that really wanted me (the NaCL/WebAssembly team) looked at my interview history and just stacked the deck so that everyone interviewing me was actually qualified to interview me. It was a breeze. Sure, it was challenging like any good interview, but not a complete waste of anyone's time.
While I can't speak to this personally, I also have heard from current/former Googlers that in the past it was extremely hard to hire Linux experts (kernel devs, etc) because they kept giving those people the same garbage screen (let's talk about Java!) and then rejecting them in the same way. Apparently the fix was a special interviewing process for people like that, presumably that's the treatment I got eventually.
None of the people who interviewed me are still at Google.
The whole exercise was pointless for assessing whether or not I'd be a good hire for the role.
Cool, man. Now I work for a major global agency pulling about the same compensation, and we won't recommend Amazon Ads for our clients b/c the product is well-known to be shit.
Works out.
Light grey text on white background with the menu constantly open and half transparent.
Google gets tons of applicants. The point isn't to prevent qualified applicants from being rejected, it's to prevent unqualified applicants from being hired.
They can do whatever arbitrary, unfair filters they want as long as they still have at least some applicants left, and as long as those people are adequate.
It might lead to some problems you don't have in the old nepotism ridden systems, but it also solves many of the problems the old systems created. So you can't say it is failing just because it doesn't do everything right.
Every time there is a thread on HN where people are debating the right way to filter applicants, the premise that goes unexamined is that there is one optimum, whether it's Google's procedures or something else.
But it's not just Google that can't hire everyone qualified. It's every employer.
Say, for simplicity, that any employer is only able to hire 1% of their applicants.
If they all used some optimal procedure, then they will all be fighting over the same 1% and the other 99% will be unhireable and start a revolution or something.
This is inescapable, I think, no matter what the so-called optimum is. It's like...a Doomsday Schelling Point.
Each company can disregard the fate of those filtered out, but only if their methods are sufficiently diverse.
Or, they could be hiring developers that, although qualified by the standards of the hiring process, are in fact unsuited to implement things Google needs to retain customers and stay profitable, but that's something we'll find out later.
In either case, the assertion that the system is correctly separating the qualified from the unqualified is unproven.
