An acquaintance of mine applied for a product management job, did two interviews in NY that went fine, then was flown out to MTV for a series of interviews.
When this person got there, two of the people they were supposed to meet with were traveling on business and hadn't notified the recruiter. A third was out sick. The supposed-to-be fourth, now first interview walked into the room and said, "Look, I don't have any idea how to interview product managers, so I'm going to ask you calculus questions", and proceeded to start to write equations on the board. The fifth interview was the first and only that happened AND dealt with product management.
When they got back to NY, this person was notified that they'd been rejected, then notified this was a mistake and they'd have to come back to MTV to redo all of the interviews, including the two that had happened.
Obviously, at this point they told Google to go scratch and went on to do really good work elsewhere.
I've interviewed at and worked for a number very very large companies before, and none of them have been as disrespectful at interviewing and hiring as Google sounds from these stories.
I feel for your friend. I went through two phone interviews, flown to Mountain View for all day interviews, and was told by the team that they wanted to hire me, but first my candidate packet had to be reviewed by three different hiring committees. I made it through the first two, but in the third hiring committee I was turned down because my GPA was not at the new 3.7+ hiring guideline.
I was heartbroken, and I am sure other people have experienced the same thing.
Same exact thing here. Overall the experience was okay, but I ended up getting mixed signals at the end. Yes? No? Huh?
Was never asked about GPA. I have no idea why the "no" in committee, but I get the impression that they approve more people than they hire. Moral of the story is probably that the initial approval is not a yes but it just means you passed the technical test.
I have mixed feelings. Would have been a cool place to work, but there are lots of alternatives.
And they can do all of that just because everybody still wants to work at Google. Let's say the have 100 applicants for a position, out of which 10 are qualified for it. Then they can still screw 9 of them and hire the one person that for one reason or the other had the luck of interviewing with the right people and talking to the right recruiters.
Whenever a company shows a too-big-to-care-about-candidate-experience attitude it's a symptom of their weakness not power. It's the sad aspect of scaling the organization without establishing a strong culture.
Exactly. This entire thread is an illustration of why, out of all of the things that startup founders have to worry about, the fear of being outcompeted by a megacorporation (OMG! What if Google/Apple/Microsoft is working on the same thing we're working on?) should not be one of them.
Yes, they can fill their spots, but the reality is that hiring bullshit means that over time their candidate pool progressively filters to "the people who will put up with bullshit", and while it takes years to filter through, in the end you up becoming Microsoft.
There was a time when Microsoft was the bee's knees and was the elusive dream employer. Then they started various HR initiatives and it became a place that only a certain type of person wanted to work, and the result is the malaise and technology lack of leadership that Microsoft now evidences.
HR as a profession is often a scourge, and the more influence HR has at a company, the more inertia pushes towards decline.
I agree that HR is often a scourge. . .however, in my previous job I was elated with the way HR improved the hiring process in my department. First, they looked at the incredibly high - and quick - turnover in our department. They actually paid attention to the exit interviews/surveys. They told the management that people were leaving in droves because the jobs/roles/responsibilities/autonomy described during the interviews were radically different from what employees actually experienced - and employees were not happy about that. HR forced more "truth-in-advertising" and "truth-in-recruiting". HR forced them to include more SMEs in the process and to require that all of the interviewers - especially the non-SMEs and managers - to know best - or at least better - practices for interviewing. . .
Ironically, Microsoft eventually got sued by employees a couple of times, cleaned up their "HR initiatives", and are now generally known as a fairly nice place to work, even when they're not cutting-edge.
Because if engineering takes over, you'll become like Google was before the Google+ initiative.
They were doing just fine making things like Google Reader.
I suppose now Google is more balanced and their stock is much more valuable but their long term direction has changed significantly. They can now be disrupted.
Most people joining big web giants I know are generally the kind of people who don't do any great real work but practice hours daily and spend insane amount of time on interview sites, take huge efforts in achieving expertise in one thing and one thing alone 'clearing interviews'.
I've interviewed at and worked for a number very very large companies before, and none of them have been as disrespectful at interviewing and hiring as Google sounds from these stories.
I'm not defending this practice at all, but I think I can understand it.
It sounds like the typical problems involved in scheduling 10 people to all perform together at once. Nobody can prevent people from getting sick. Going out of town and missing an interview is pretty flaky, but it happens. You can look it as "Google is evil and wants to torture candidates" or "people are flaky".
It's certainly human nature to be bitter about someone fucking up an important day for you, but ultimately, bitterness gets you nothing. It's no problem if you want to complain to your friends or on HN, but why not come back for the second try? Your friend could have had another free trip to Mountain View to actually be interviewed properly, and maybe get the job he wanted. (They do pay pretty well at Google, after all; the interviews aren't for some volunteer position.)
(As for the calculus interview, that sounds like fair game. PMs are supposed to have some PM interviews and some SWE interviews, and math is a perfectly acceptable area to ask SWE candidates. It's not where I would spend my time, but that's part of the process that people hate; different interviewers have different preferred questions. I would probably have asked "how do you test that", which would probably raise a few eyebrows in a story like this too. But ultimately, having that understanding is something I value in future coworkers, so it's what I'd ask about in interviews.)
Finally, if you have any questions about the hiring process at all, feel free to send me an email, jrockway AT google.com. I'm not a recruiter, I'm a programmer who cares about making the process work, but I'll try to help you out!
You're focusing on the details. The huge, blaring point is that some person was flown across the country, probably took time off work, etc. for an interview that was utterly hopeless from the outset and thus pointless. It's Kafkaesque in its absurdity. Make no mistake, this sort of conduct is a black mark on Google.
Funny how the only people in this thread defending it are people currently employed by Google. The world viewed through Google Glasses sounds awfully distorted.
> Going out of town and missing an interview is pretty flaky, but it happens.
Sorry, "it happens", is such a callous sentiment regarding someone's future. "We booked and agreed on a time and couldn't be bothered doing it and couldn't be bothered telling you, either" is outrageous.
It's interesting to see that the Google employees commenting in this thread are OK with people being treated this way. It reveals a lot about the culture. No wonder you fail so badly at customer service.
Maybe you have been at Google so long that you don't realise it, but this is not a normal or decent way to treat somebody. I can't think of anybody I know who would want to work there after going through that interview process even if they did get a job offer.
Interviewers not being on site I can see yes, that can happen and I agree we can attribute that to 'flakiness' if it's a one off. (Although I have to say I can't imagine it ever happening at anywhere I have ever worked, and I've worked in local government, a bumbling bureaucracy if ever there was one).
But failing to return calls just about every single time? Waiting months before getting back to tell somebody they progressed to the next stage or didn't make it? Having to call a friend at Google to find out if you passed the interview or not because they didn't bother to call back? Making snide remarks to the candidate? Just about every account in this thread reveals a similar story of waiting for months to get any reply, not getting replies, not being told how the interview went, not being told why they were turned down. That is systematic and reveals a hiring process that treats people like shit because you can get away with it.
From my perspective, the naysayers (including you) are personifying google to make them look worse. Two interviewers leave on business trips without notice, and the people remaining scrambled to get something together. The system couldn't handle this exception, so everything got screwed up. It's not like they lead him on only to harass him.
Actually, no, it doesn't just happen that people go out of town and miss an interview. Not in normal places.
Now, let's say there was some royal but completely understandable cockup where this guy completely spaced that this day was the interview or whatever. Fine. Where was the recruiter in this? Who was in charge of the process, and why didn't they realize that an interviewer was unavailable sometime in advance?
If I get an interview with a company and then just neglect to show up, odds are they will not give me a second chance unless I had a good reason, something more than just "I forgot". Why should things be any different if the roles are reversed?
Exactly. The job of the recruiter is to send - days in advance - invites to everybody involved, ensure they are not busy and they affirmatively accepted the invite. Even if somebody doesn't keep one's calendar up to date - if invite wasn't confirmed the recruiter should have known and should have done something about it. Looks like serious quality problems in that department in Google.
you say flaky, I say assholes who don't respect others' time. And way to move the goalposts re: your friend would be happy comment. I think what would have made his friend happy is to be treated with respect. Similarly with your bitterness comment; it's not bitter, it's letting the world know you and your colleagues believe it's right to treat people this way (because if you all didn't think this was ok, then you wouldn't do it).
I'm not defending the hiring practices at all; on some level, we lose out on a lot of qualified candidates who would do great work and would be great to work with. I'm not a recruiter, but I try to help out however I can; people on HN regularly email me asking for advice, or to ping their recruiter, and so on, and I'm happy to do this. I want to work with you, and I don't want the intrinsic flakiness of people to adversely affect your experience. But ultimately, I can't control other people, I can only control myself.
All my other comment is saying is how to think about the problem from another perspective. You have a lot to offer Google, but Google is not exactly coming up empty on its end. Therefore, I think it makes sense to cut Google some slack. But if you don't, that's your prerogative. I personally don't aim for 100% perfection 100% of the time, but some people do, and that is respectable.
(Oh, and I don't think complaining about the interview on your blog is bad at all. What's "bitter" is refusing to come back for a second try, even though you still are kind of interested in working at Google.)
You described it as a "free trip to MTV" as if it were some kind of a perk. It's wasting two days of somebody's time, and apparently showing no remorse. At that point the ball should have been clearly in Google's court, surely they could have figured out a less painful way of gathering any extra data they needed. I mean, the guy was in NYC! It should have been trivial.
It's well known both inside Google and outside it that many parts of the hiring process are badly broken. Suggesting that people should just grin and bear such abuse just means the process will never get fixed. While if people just stopped the process if it got silly enough, somebody's bonus would be in sufficient jeopardy to cause some action.
(When I worked at Google I never referred any friends unless they asked me to -- the chance of them having a bad experience was just too high. And recruiters were always pretending to be shocked that anyone could think the process wasn't working properly.)
> As for the calculus interview, that sounds like fair game. PMs are supposed to have some PM interviews and some SWE interviews, and math is a perfectly acceptable area to ask SWE candidates
I upvoted you because it's not fair to down-vote people who are on topic, but you're not correct when you assume that of all things calculus (!?) should have anything to do with hiring a PM.
I honestly fail to see how solving some Cauchy sequence-related stuff 10+ years after you finished your studies has anything to do with managing a bunch of programmers. And I'm not saying this as an I-hate-maths guy, in fact the only A+ I got in college was in calculus, but were I to be given such a question during an interview I would have just left.
The OP says his friend was interviewing for "product manager", which is not that. Product management is basically coming up with ideas for new products and seeing them through to the end. That includes helping design the actual computer program, which is why they ask software engineering questions.
(There are a ton of jobs called "PM", but they're all very different. None of them manage engineers, though, that's just "Manager" or "TLM".)
Sorry to barge in, my guess is that Google looks for the best of the best with a slant toward academia. So maybe a PM from a top notch b-school knows his calculus?
That does seem to be their line of thought in most things, but in what universe is calculus in any way a measure of your ability to manage a product, even as a proxy? It's barking mad. I could be great at calculus but terrible as a PM, I could be a great PM yet terrible at math, and so on. I can see the point if I was applying to be PM for Mathcad or the like, but otherwise....
Working in this industry is just distressing. There are so many really clever people in this industry that cannot reason in any practical way (absolutely not calling you out, bubbleRefuge!!!) I work with a team that cannot figure source control out. People ask interview questions which a seconds introspection reveals will not measure real world performance. It goes on and on.
Sorry. I think I just realized I need a vacation. I deleted a much longer string of absurdities at the end of the paragraph above. My non-ranty point is that clever!=smart, and clever != job performance. Google has admitted in the press that their recommendations from interviews perform no better than chance. I don't get why that was hard to forsee. If you aren't measuring what you are trying to assess, chances are your results will be noise. "I wonder if this person is creative and can think up new product ideas. How will I determine that? Think, Roger, think. I know, I guess I'll ask him the math behind Cauchy distributions, and follow up with a problem in Hilbert space. That makes sense!" ;)
Roge, you are a 100% right. It all begs the question, why are we so obsessed with working at big box companies? The reason this inefficiency in hiring exists is because Google can get away with it. If the short-term survival of G's business depended on hiring, they would have to do a better job.
>>As for the calculus interview, that sounds like fair game. PMs are supposed to have some PM interviews and some SWE interviews, and math is a perfectly acceptable area to ask SWE candidates.
Lets leave the managers alone for a while.
When exactly was the last time, you as a programmer used 'calculus' while writing programs.
Your statement shows everything wrong with hiring programmers these days. Which is to demand expertise in totally irrelevant areas, and when the persons fails to the test declare him incapable of doing his actual job.
And then when you hire people experts in irrelevant areas not being able to do the job, start complaining that good programmers are difficult to hire.
How will we find good programmers when we are not even looking out for them?
Well, it's nice to hear from someone trying to defend the logic. Again, this wasn't my experience, so I can't assign motive to anything like that, but let me try to add a little context:
I'm not defending this practice at all, but I think I can understand it. It sounds like the typical problems involved in scheduling 10 people to all perform together at once. Nobody can prevent people from getting sick. Going out of town and missing an interview is pretty flaky, but it happens.
Except it doesn't at other companies. Or if it does, it's corrected before a candidate shows up at the door. In other words, you value a candidate's time. I interview people all the time, and if I have business travel come up, I look at my calendar and make damn sure I don't have any interviews when I'll be out of the office (and if I do, I reschedule. If an emergency happens, I get someone equally qualified to cover). Heck, I even send personal apology emails when I have to reschedule phone screens.
You know why? Because it's polite.
It's certainly human nature to be bitter about someone fucking up an important day for you, but ultimately, bitterness gets you nothing. It's no problem if you want to complain to your friends or on HN, but why not come back for the second try?
Again, I can't ascribe motive to someone else's actions, but it's because it's disrespectful. It's not like, btw, google was apologetic, or said, "You know what, let's do these next round of interviews over video chat", or "We're going to make this up to you in some way". If I recall these events correctly, it was, "Sorry, you didn't get the job because you didn't do well in your interviews". Then a few hours later, "Oh no, wait, you have to do them all again". That's just disrespectful.
Your friend could have had another free trip to Mountain View to actually be interviewed properly, and maybe get the job he wanted.
Who wants a free trip to mountain view? Bear in mind, this isn't a college grad who is just excited to get to go to california, this was someone who was already an experienced product management executive in a leadership position at a middling-size startup. Going out to mountain view messes with their schedule and their work, and again, it's disrespectful.
As for the calculus interview, that sounds like fair game. PMs are supposed to have some PM interviews and some SWE interviews, and math is a perfectly acceptable area to ask SWE candidates.
If the questions had been in the technical area in question, even from a software engineering perspective, I'd be in agreement. But arbitrary knowledge of calculus seems unkind and unnecessary. That's clearly a style preference, though, as you say.
The point I'm generally trying to make isn't about my friend's experience exactly, it's just to add on to what many many people here have said: that google as an organization may treat employees very very well, but treat candidates very poorly.
Coordinating interviews really isn't that hard. Tracking candidate progress isn't that hard. And when you as an employer screw up, picking up the phone and making an apology isn't that hard. Failing at all three shows a fundamental lack of respect for the people you're hiring. You can't just say, "The system is broken".
Google recruiters will tell you whatever you want to hear, including things that are not necessarily true. I was assured that a minor issue in my background would not be an issue multiple times (I have email proving this), then Google hired me and let me work for more than two months. I got comfortable, I moved to Mountain View, began real honest work and set about making an impact.
One Monday, I had just finished a feature for an internal monitoring tool and was discussing it with a teammate. HR scheduled a meeting 30 minutes in the future on my calendar, then informed me that my employment had been terminated because of the issue in my background. You remember, the one I disclosed and discussed repeatedly during the hiring process, before I even signed the offer. Two people in upper management at Google who had never met me fired me because of something seven years in my background, two months after hiring me with the assurance that it wouldn't be a problem.
I bet my teammate wonders where I went. I didn't get a chance to explain because they threatened me if I told anybody on my team what happened while I was collecting my things. The same woman had a hearty laugh earlier in the firing meeting after joking, "I bet you didn't expect your afternoon to go like this, huh?" Felt like I was back in grade school.
Two weeks after firing me, a Google recruiting coordinator attempted to connect with me on LinkedIn. Read into a company's competence what you will based on that.
I can never, ever recommend that anybody subject themselves to working at Google based on my experience. And that's even before discovering the absolutely clueless direction that company is taking. You think G+ is annoying now? Just wait.
The real victim in this is my family. I've never subjected them to no insurance coverage in my career. Thanks, Google.
You may have a legal case for moving expenses and lost wages. Something along the lines of fraudulent inducement -- especially in California. I'd talk to an employment lawyer if I were you.
And blacklist myself entirely from this career? This throwaway comment is pushing it already in terms of burning bridges, not to mention getting fired from Google itself after my extended network congratulated me on the position. Who, in this incestuous valley, would hire the guy that sued Google for an employment issue?
I've seen it happen, no way. Right to work, too, sigh.
To be clear I moved from the Oakland area down here, so it's not like I came here from Cleveland. Also, I have no ill will for Google and just hope I can move on with my life, while warning people what they're getting into.
I've dreamed of working at Google since I was a teenager. Finally my career trajectory lined up and I got there. Then I have to come to terms with my dream company acting like an incompetent fast food chain in terms of HR. Tough enough without a lawsuit.
No, any settlement would almost certainly include a mutual non-disclosure agreement and mutual non-disparagement agreement. Complaining about it here makes it more difficult to get those, though, and any settlement in general.
Moreover, that's not how it works in SV. Assuming you do good work, nobody will care if you sued Google and settled except perhaps Google. I know plenty of engineers who were fired from companies like Facebook and Twitter for perfectly legitimate reasons and are now working at similarly-awesome companies as engineers. And this is a situation where the termination was 100% warranted and broadly known in "the incestuous Valley."
I would have fired them had they done the same and I would have also hired them at another company, assuming they learned their lesson and otherwise seemed like people with integrity.
I appreciate your thoughts and haven't taken them lightly.
That's the thing, is this stupid college mistake on my record undermines my integrity. Never mind that I've been employed at multiple companies and been trusted with user data far and beyond what Google would ever trust me with.
I would have hoped that after a five year history in this industry, I would have demonstrated some integrity. Not even my character references, who will happily vouch for my integrity, can sway these people.
Remember folks, HR is not your advocate. They are risk mitigation.
Ok, well, here's how I'd approach it. There are three classes of companies: those that will ding you for your past, those that don't care about your past, and those that will embrace your past.
One strategy is to try to hide your past, figuring it won't hurt you with the latter two and might incrementally help you with the former. I wouldn't adopt this strategy.
Instead, assuming it truly is "minor," I'd own it. Write a blog post about how your past has made it harder for you to find work. Talk about what you did, specifically, and all your feelings about it then and now.
Don't name names of companies, but perhaps share some (anonymized) stories. Whatever you do, it can't sound like sour grapes. You have to be magnanimous to the last drop. You have to swallow every last bite of indignation you have. You need to say and believe things like, "If I'm honest with myself, I can understand why Company X made the decision they did even if I felt they handled it inappropriately and ultimately made the wrong decision for the wrong reason."
Try to tie it into a larger story, perhaps raising questions about whether the tech world is really a meritocracy, e.g., "Silicon Valley is a Meritocracy, Unless You Broke the Law as a Kid." Maybe try to reach out to other folks who have had similar experiences, e.g., "Are you an engineer whose past makes it hard for you to find work? You're not alone."
The response on this thread alone should be good enough evidence that folks would be interested in the story.
This will do a few things. First, it gets you exposure. Second, it immediately gets the attention of folks in the neutral and positive camps. The former will go, "WTF? We don't care about this. How stupid of people to reject a candidate for those reasons; let's interview him." The latter will go, "Holy shit! This is our kind of guy; let's interview him!"
You have nothing to lose, really, because this information is going to come out over the course of any interview no matter what. Turn it into your armor rather than resign yourself to having a sword in your belly.
I'm toeing the water here anonymously, if it's not obvious, and have thought of that precise thing. Perhaps a mailing list or advocacy group of engineers with problematic backgrounds, and assistance to companies that don't deal with this often.
This is a community of hackers in both senses of the word. Computer Tampering is a felony on the same level as manslaughter in one place I've lived. I like your thinking.
I've also e-mailed you, and appreciate your advice, yet again.
It may be worth a free half-hour conversation with a lawyer about whatever is on your record, even if you don't want to sue. Maybe they can make it go away.
If you have the evidence you say you have, I'd bet a good attorney could get mid-five figures out of them along with an agreement not to disclose the settlement.
I don't see what harm there would be in getting a professional opinion, anyway.
I've never been in the GP's position, but my thoughts on such things have always been that there's usually not much point in suing your current or former employer, barring something really extreme that somehow cost you 6 figures or more. The only real upside to it is a one-time payment of a few tens of thousands, which sounds like a few months of salary at any company in the industry. Why spend the time with lawyers and courts and risk possible future issues with then and other companies for that? You're probably better off in the long run to just forget about it and spend your time getting a job at a more sane company.
>Who, in this incestuous valley, would hire the guy that sued Google for an employment issue?
I would. Unfortunately I'm up north in Sacramento. I don't know how long ago your ordeal was, what your situation is now, or your engineering background, but feel free to ping me.
Appalling behavior on Google's part. Amazingly, I know two other people to whom this exact thing has happened (neither of which are you based on details in your story). One was so determined to work for Google that she reapplied after getting the incident expunged from her record (and got rehired -- based on their hiring practices who knows if they had any idea she was the same person).
I'm moving out to the Bay Area next year (for non-work-related reasons) and while I hear plenty of good things about working for Google, I would never do it. For me personally, choosing to work for them would be an implicit endorsement of their hiring/personnel/privacy/politcal practices, which I can't abide.
If you're at liberty to share : did your acquaintances also disclose the incidents during the hiring process, only to be terminated randomly once employed? If so, that is utterly appalling.
Bad enough that it should happen once (to the parent), but repeated incidents would point to some gross organizational dysfunction.
I heard back -- the incident in question for the other person occurred as a minor, so they could have it removed from their record, but had not yet done so. They explained this to the recruiter (a Google employee), who told them it would not be a problem, and so they didn't get it removed. Then they lost their job. Grotesque.
I asked the HR Manager point blank if Google made a mistake here, waiting two months to act upon information available to them before they extended me an offer. She countered that I was the one who had made the mistake in 2007.
I served my probation sentence and am beyond tired of being punished for the same thing. If hiring people are reading this and understanding just that last sentence that I typed, then I'm happy.
Sue them on grounds that their negligence caused irreparable damage to your future earning prospects. Settle for a hundreds of K's. Use the money to launch a contracting career. Incorporate, do C2C contracts. Background checks are uncommon. Been at it for 2 years now and love it.
This. It's crazy, but criminal record can make or break us white collar workers. It's sad that people and corporations don't have a forgive and forget mentality towards convicts. I think that the only way out is to be your own boss. When people buy a product (software or better yet hardware) they are much more removed from the people producing it.
I'd be interested in how you are handling all this. And how common you think this situation is among white collars. Good luck in your future.
This isn't the first I've heard of extreme and unconventional background check requirements in Google hiring. Has anyone determined what does and does not get you blacklisted?
I wouldn't want to work in a company where people just disappear and nobody is allowed to talk about what happened. That sounds a bit too dystopian for me.
I'm sad that that's the way things are. I think that once someone has paid their debt to society through the justice system, that this should be acceptable to society.
Another incident demonstrating that "the system" (more than just the criminal justice system, as it extends to subsequent civil and commercial life) is neither about justice nor about rehabilitation.
A further corruption: I've read that, even when there is a will to "take a chance" (aka employ and treat as a member of society) people with a criminal record, businesses can face obstacles -- sometimes insurmountable, for a smaller business -- to do so. One particular one: Insurance companies audit for such employees, and either cancel insurance or raise it to unaffordable rates.
No, there isn't. Convicts are one of the last remaining class of people not protected by law. Every time any effort begins to make convicted folks a protected class, it makes politicians appear weak on crime and is quickly silenced.
For people who live outside the US, you may want to consider that "convicts" include random drug testing (medical marijuana, poppy seeds testing positive for opium, alcohol/diabetes issues, HIV) – and of course, sexual preference.
Yes, there are laws and court cases that should change the outcome, but that means a lawsuit.
In other words, US employment frequently comes with a lot of implicit assumptions about your lifestyle.
Edit to add: fortunately random drug tests aren't very common in the tech industry.
That's what really bothers me about the legal system in this country. Any brush at all with the legal system, no matter what it was, how minor it was, whether you were actually guilty or innocent, or what you say about it now, gets you blacklisted in a huge swath of the professional industry.
Sorry. Does google do something like a 6mo probationary period? Did yo have to return things like signing bonus or relocation expenses provided by google? Did they offer some settlement?
No, you are a full-time employee from day one. I received neither, and no, I was not offered any severance, concession, or consideration, though I asked.
I am requesting this with the companies currently courting me for employment, and have made clear what happened at Google to each of them. I have found other companies' recruiters to be extremely sympathetic and willing to adopt a nontraditional "let's get the legal review out of the way first" hiring approach with me.
I signed a nondisclosure agreement and upholding it is part of my demonstration of integrity. I would never go back on an agreement that I signed, and were the legal framework not in place anyway, I'm not a "fuck me? Well fuck you" sort of person. I only mentioned it at all because most of those motions have been expressed publicly.
I think this is very unfortunate. I've seen a lot of good candidates get rejected for no obvious reasons. The lack of communication seems driven I think by the sheer deluge of the number of resumes/interviews going on at Google, and what appears to be, a reliance on temps and contractors as part of the process.
I had a friend who interviewed at Google, who is an excellent software engineer I've worked with for years, but who got rejected with extreme prejudice because he was interviewed for the wrong position. He was going for software engineer, they interviewed him for networking/systems reliability, and asked him all of these sysadmin/network-admin style questions. Even after he told them they had set him up with the wrong set of interviewers, they still kept the schedule.
Given the sheer size of Google however, I'd expect lots of false positives and negatives in their filters.
Also recognize that regular Googlers are selected to do these interviews, and some of them have little training in giving interviews. If you're unlucky, you might get a bad interviewer. I consider myself a relatively poor interviewer and I usually decline to do them unless they intersect my subject area (compilers, GWT, etc)
This happened to me! I'm a software engineer. Someone at Google thought I'd make a good security engineer and called me in to interview for it. Why not, right? Sure, I'll give it a try.
When I got there, I was greeted by my first interviewer who started asking me questions about SONET. I stumbled for a moment then commented that I could try to guess a few answers, but I didn't have any experience with optics. The interviewer looked back and forth between me and his paperwork a few times, got flustered, then asked if I was interviewing to be a network architect.
No, I didn't expect to be.
Well, that's what they had me scheduled for. He asked me a few more questions about things I'd never heard of, then we sat back and chatted about valley life for the rest of the hour.
The trip to MTV was fun, but it would've been more interesting if I'd gotten to interview for a job I actually knew about.
"I had a friend who interviewed at Google, who is an excellent software engineer I've worked with for years, but who got rejected with extreme prejudice because he was interviewed for the wrong position. He was going for software engineer, they interviewed him for networking/systems reliability, and asked him all of these sysadmin/network-admin style questions. Even after he told them they had set him up with the wrong set of interviewers, they still kept the schedule."
Unfortunately, I've read similar anecdotes on HN. Pretty disrespectful of the candidates time.
Why don't more people walk out of interviews? Especially if someone set you up to fail, quite literally: interviewing for the wrong job. It's a waste of my time, it's a waste of your time as a company.
On top of that, if you're going to throw out dickish comments like the article states (paraphrase: "ask your friend, he'll know the answer"), I wouldn't stick around. Is that the atmosphere at the company? Agree or disagree with the interview style, comments like that would piss me off to no end. Start a game of needling and insults? You know what, I've had enough.
Because then your interviewer does a hatchet-job on you in a feedback form and you get shitlisted from interviewing at Google forever.
That's the problem with large companies. There are companies where I would just walk out of an abusive interview, because the brokenness represents their whole company. Then you have massive, mega, ultra-sized companies like Google where even though this particular team is beating you with the interview bat, you may still want to work for other teams.
This is probably confirmation bias speaking, but by far I hear the most "primadonna interviewer" stories come out of Google. I'm not sure if that's just my impression or if there's really something going on there.
Funny that there seems to be a consensus that Google can effectively black-list people, and yet it seems they can't even keep track of who they are supposed to actually interview or who they have previously contacted about interviewing.
If you are blacklisted, then someone needs to check the blacklist just once for your process to get terminated.
If you are scheduled, many people must refrain from screwing up.
It even took them months to figure out that they hired an ex convict, after he personally disclosed the fact multiple times.
I had great hopes for Google to innovate in sense of culture. I saw Larry Page and Sergey Brin as intellectuals. Turns out they just went and built a high school elite club, for geeks. Another bloated company ran by a corps of smug geeks that like to claim how they are holier than thou.
Sourcers are under a lot of pressure, and I've noticed it not limited to Google. Rackspace set up a flight to San Antonio for me then cancelled it the evening before after their lawyers waved them off me due to my background (discussed above).
A couple months later Rackspace cold called me to work there. It's a usual thing, I think, and I don't hold it against them.
I get that, from your perspective, this is a forgivable thing.
But if I'm Google or Rackspace, and I'm reading about this process from your side, I have to be asking myself "why am I paying these clowns?"
Hiring is one of the most important things companies do. If they are this disorganized, and if their cultural commitment to hiring is so poor that people are regularly brought in and interviewers are not present or available or confused about why either of you are there, then there is a huge amount of waste going on and there's a huge amount of missed opportunities.
I don't know you, but let's assume you are really good at what you do (and going by the number of people you had recommending you, you're probably pretty good at what you do). The fact of the matter is that Google totally missed the boat here and burned a lot of extra money in the process. Beyond that, for the two years or so that they were jerking around, you could have been a part of the team, making solid contributions. Instead, you were elsewhere making solid contributions that they may have had to defend against. So, the real waste is in the opportunity cost.
What I'm getting at is, if I'm a senior executive at one of these companies, I have to be looking at my hiring process and going "WTF?". Because that's what it deserves. Something is seriously broken and it is potentially a strategic threat.
As someone who's had to conduct some interviews, that's the opposite of my reaction.
If I show up to an interview slot (for which I'm spending my 15-30m), and the candidate speaks up about a mis-scheduling or whatever, and convinces me it's not worth our time to meet, I'll be happy to regain my time and complain to the HRbot/hiring manager about scheduling issues (aka please don't waste the my/company's time by messing up the scheduling).
Ah, but you don't have to just walk out telling them they wasted your time. It only talkes a moment to check you muted phone and'OMG - there is an emergency at home/with my child/spouse etc. So very sorry but you have to leave right now to take care of it. Hopefully they understand and can reschedule after the emergency is taken care of."
End of story and if you catch them early enough in the interview you can be back at work happily coding the latest story in current sprint.
You should do what's best for you but understand why the folks on here are defending google; it's a big place and they are mostly powerless when it comes to direct influence or manipulation. Understand that and it will give you insight into how to hack their system for your benefit both before you are hired there AND after multiple interviews when you find that right team when but need to deal with ingrained systems; which rules must be followed and which rules everyone ignores, when to ask for forgiveness later and when and how to cover your ass from the start.
That's definitely a fair point, especially about bigger companies. Personally, I value my reputation (real-life, not with whatever HN points says) very, very highly, so I'd imagine doing something like I described would be an excellent way to really leave a stain on your resume.
They freak out. I got blacklisted at a cellphone company for doing that a couple decades ago. I found that out via a friend on the inside. Basically I was looking for, and applied to get a lab bench job (basically a spectrum analyzer / communication analyzer jockey, beneath my ability, but it was an exciting growing company etc) and they wanted me to be a junior roving field tech, basically I'd help the real field techs carry heavy stuff into the building and then (literally) mow the lawn while the real tech worked. And I went to school for X years to run a lawnmower... uh huh...
If you think its mortifying for the candidate, imagine how the HR rep looks when you walk out, thus making a fool out of them. Note that I wasn't sarcastic or caustic or anything when I left, after all, I had lots of friends / acquaintances on the inside and telecom is a very small world. Lots of hand shaking and "you have a nice facility here but I'm not interested in the position" and so on. I got word from my inside contacts that the HR girl was fuming with rage and swore after I made a fool of her by walking out, that my resume would never pass her desk again in any capacity, etc.
Companies are always doing stupid stuff, just hopefully not too often, and they're at least partially interested in how you'll respond. So imagine you work there and someone in upper management makes the worlds dumbest presentation to the division, they're terrified you're going to laugh at them and walk out.
When I was younger and (even more) stupider, stuck at an interview I decided I didn't really want, I started flirting with the attractive HR staffer, which didn't work out, but it was fun at the time. Times were different back then, now a days politely asking a woman out at work would probably get you fired or arrested.
Asking someone out to a date the first time is perfectly legal. The moment you ask again when they say no is considered harassment and then you could get fired, but I doubt you would have any real issue the first time you ask.
I am not a programmer. The OP mentioned that in a number of the scheduled interviews that he had face to face, the interview finished quickly, and the interviewer talked about working at Google. Does this strike anyone else as 'palliative interview'?
I was actually going to bring this up. I have a lot of friends who are interview pros. They say if an interviewer decides earlier on you're not going to get hired, they basically fold up their sheets and ask non-related general questions to pass the rest of the time.
My experience has been the opposite. I've received offers based on interviews where we talked about: the local radio landscape, the best local lunch spots, the most ridiculous internet-bubble perks we'd seen, or color choice in 1950's suburban housing. I get the feeling that it's the idle chatting at the beginnning and end of the interview that matters most when the interviewer is asking him/herself, "Will this person fit?"
As an interviewee, I have, more than once, thanked my hosts for their tea and cake and left early when I detected that the interview was turning into a chat.
Would a collegiate interviewing model not work better for an intellectually driven organisation like Google? Each team interviewing for their own positions, but with some form of 'tenure track' process for the longer term?
Amazon does things this way (the hiring team does the interviewing) but there are some major drawbacks to it as well. If your team is grossly shorthanded (say, 30% of seats open), you have your team doing a ton of interviews rather than covering for the headcount shortage, which means you're even more underwater or behind schedule. (And you might have to screen dozens of candidates to fill a seat.) Also, there's a strong incentive to just "fill the seat" so they can stop interviewing people, which Amazon does try to avoid by having at least one "bar raiser" on the interview circuit who is from another team.
At a broader level, the problem with this is that the delays inherent in doing a lot of hiring and relocating people means that you can't have teams doing their own hiring and then waiting for people to arrive and come on-line - there need to be candidates in the pipeline before the exact seats open up. Otherwise you're talking about a 3-6 month delay from when a seat opens to when there's an engineer sitting in it, which sucks.
Okay, that just makes a ton of sense. I've never worked for a big company like that, and hadn't considered the latency issue that can be worked around by general interviewing.
With that said, it doesn't change my opinion of it being a time waste for me. I have a career, I know, more or less, what I want to work on next, and I have no interest in devoting a month (seriously, Google recommended taking that long to come up to speed on interview questions) of study to interview for who knows what position, especially when the whole system is gamed towards rejecting false negatives.
> Otherwise you're talking about a 3-6 month delay from when a seat opens to when there's an engineer sitting in it, which sucks.
Welcome to reality in most of large corporate america. I've seen insane 6-9 month interview processes at places like Cisco and that's not even a successful hire. Likewise at other large SV companies.
If you can get it down to 3 months, it's below par and better than the competition.
I'm really surprised that's not how it works at Google, both from their perspective, from the perspective of the candidate. I would be extremely hesitant to interview or accept a job at Google if didn't know what I'd be working on, and it seems like you only find that out when you show up the first day.
This is true only if you are hired for a generic role. Most people are, but for sufficient specific jobs (like mine), you will know exactly what team you are joining.
Also, with decent performance you can transfer after a year, occasionally even earlier if another team really wants you.
It would certainly make more sense. Sure, have one or two screening calls, but the main interviews should really be done by the team you're going to be on. Not some expert in algorithms who deems your solution to a question not good enough. I mean, how many times have you heard an engineer say, "It's not pretty, but it gets the job done." ??
The 'tenure track' is a great idea. How would you implement it though? Just curious.
"The 'tenure track' is a great idea. How would you implement it though? Just curious."
As I said a few levels above, I am not a programmer. I'd imagine it might work like academic departments, a series of short contracts (well paid!) leading if successful to a more permanent place with some ability to direct own work.
I get the impression people are dealing with firehoses rather than trickles (talk of 'recruitment pipelines' like in a tyre factory) so perhaps the collegiate model just won't work.
I almost did once. The interview was at Ebay and the entire process was disastrous from the very first contact. Terrible management during the entire time. During my final interview with some manager, I was ready to just get up and walk out. My frustration was showing and undoubtedly contributed to me not getting an offer. The only thing that kept me from walking was my professional and the fact that they paid for my flight. The organization was so poor, I would not put it past them to cancel my flight if I walked out.
The people interviewing you are real people too and sometimes very interesting people. They don't choose what job you are interviewing for, they just get told to show up at a time/place and get a resume/job spec.
Microsoft has more employees and the three times I interviewed with them (and got accepted) it was a great experience, with perfect communication from their recruiters and interviewers. The one time I interviewed with Google (and got accepted, but I rejected them for MS) I pretty much went through a similar experience as the blog post, although the interviews themselves weren't bad, just the recruiting process.
When I was at Google, I was told over and over again that blind allocation was necessary because no other method of placing employees would scale to Google's size.
Whenever I pointed out that the bigger the company, the more teams there would be to absorb and place incoming employees, the googlers in question would just ignore the response and emphasize that blind allocation was necessary because no other method of placing employees would scale to Google's size.
I always love it when people make appeals to scale when they just don't apply. For it to work, there has to be some kind of non-linearity at play. In any circumstance where the total cost rises in proportion to the total size, it's just nonsensical.
I interviewed at Microsoft quite a while ago, and the process was fairly pleasant. My only complaint was that eight hours of straight interviews is a little long.
Microsoft's HR departments are completely siloed by business unit, and they don't share notes. If the rec you're applying for dries up, they do F-all to guide you into a new one. Each time you engage with a different BU you're completely back to square one.
It might be because each time I interviewed was for a new hire position or internship position...and their university recruiting is pretty solid. Google's on the other hand...
My recruiter failed to call me at the scheduled time. Twice. I wasn't too terribly dismayed, as I was already home at the time anyway, but that put me in a pretty bad mood to begin with.
I failed the first phone interview spectacularly because he asked about data structures and estimating powers of two, and I haven't done any of that after 4 years in the industry. I guess fair enough; if that's what they expect of their employees, I'm not their man.
This is typical for all of the big "A-tier" tech companies I think. I used to do a lot of interviewing when I was at Amazon, and invariably the interviews leaned very heavily on CS fundamentals.
I'm all for CS fundamentals, but in many places it's clearly being used as an approximation of good-code-shipping-ability.
I think part of the problem is that you're not really allowed to interview people in a way that holistically assesses their ability, so you end up doing cargo cult-y things that sort of, kind of sounds like they're relevant. For example, when I was at Amazon, we specifically were disallowed from using real-time typing/sharing tools to conduct coding questions.
Nowadays I find that pairing with someone on a limited-scope coding problem, as well as talking deeply about software design and architectural decisions, is the best way to assess. But then again, I'm also no longer interviewing complete newbies - which I think Amazon/Google/Microsoft's recruiting systems are heavily optimized for.
When faced with a candidate who has a dearth of real-world things to dig into, of course you fall back on data structures and algorithms. When you apply this to experienced professionals, who have a long track record that they can talk in depth about, it becomes silly.
My interviewer called me an hour after the scheduled time to ask if I would be able to call me back in a half hour because he was busy.
When he eventually called back and started the interview, he did not even seem to respond my answers to his questions - it honestly sounded like he was playing a computer game on the other end of the line...
It was blatant disrespect towards me and my time. I'm glad I found an opportunity elsewhere.
Low cost, high reward. Like I said, I was always home from work anyway (different time zone from Google), so I was just sitting in my room when the call didn't come. If an opportunity to work at a company like Google comes along, I'm willing to put up with some minor annoyances.
They have a post-interview review process, and I gave the recruiter an appropriately negative review.
My experience of those interviews that ask CS or “puzzle” questions is that they are sincerely trying to determine that you are capable of dealing with inherently novel/theoretic problems or problems you've never seen before. Unfortunately this notion is misguided because the problems aren't real problems, and the context in which the problems are solved is entirely different to what it would be in the actual workplace. As someone who cripples under observation (sort of like how hearing a siren takes up 50% of your brain power, the pressure of being observed does similar to me), I am simply incapable of performing in those types of interviews, despite being competent for the job. I once crumbled so badly that I couldn't do simple arithmetic, and the interviewers tried to “break things down” for me and continue despite my obvious state of stress. I resent those interviews sorely, and will avoid interviews in the future if I find out ahead of time that they involve approaches like this.
You're not alone. Although it's never been as bad as not being able to do arithmetic, I can't seem to get a job doing those kinds of interviews. I was close once at Microsoft, after having done 8 hours of coding and linear algebra and other math (that I wasn't expecting) without a slip up, and what I thought was pretty great performance, but alas that wasn't enough either. Most of the time I freeze up and can't think in those situations though, I don't know how I pulled the strength to get through that interview. In the process, due to stress, I developed a huge canker sore in my mouth where there's still a scar. Interviewers dropping hints just makes it worse, it's not that I need hints, it's that I can't THINK when you're sitting there judging my performance, while having to keep explaining my thought process out aloud. Some people are just not built for that.
It's great to see comments like this. I thought I was alone. The jobs I have gotten so far is either behavioural only, talk about past projects, or written technical (they give you some questions on paper and then leave you alone for an hour.)
> capable of dealing with inherently novel/theoretic problems or problems you've never seen before
To be fair, these were "Data Structures 101" type questions. One was literally design a graph structure and write a deep-copy procedure, and that's it. Not exactly "novel." Since I haven't done these in ages, and didn't even pay that much attention when I had the class, I did badly.
Another was a simple string manipulation question that I bombed because I was already stressed out from failing the first so badly, similar to your situation.
Google and other major SV companies are known for heavily theoretical interview processes. IMO, your recruiter should have made this clear and suggested you brush up.
In my experience, my Google recruiter simply did not respond to emails. The only way to get in touch with him was to email HR. Scheduling the first round of interviews? Email HR, wait for the recruiter to email me. Scheduling the second round? HR. Finding out results - you guessed it, emailing HR to get the recruiter to call me. This stretched my process to two whole months.
Just two months? I've been doing the interview 'process' for at least three months, and i'm expecting another month if things go "right".
I was head-hunted by them initially. Had a casual phone interview within the week. Then scheduled and re-scheduled a technical interview (their fault, three more weeks). Then two weeks later I had another casual phone interview. Then waited two weeks for the on-site six-interview bonanza. I finished those 4th thru 9th interview two weeks ago, and recruiter just told me yesterday to wait for the hiring committee to give a decision in another week.
> consider myself a relatively poor interviewer and I usually decline to do them unless they intersect my subject area (compilers, GWT, etc)
First, given you understand your limitations as an interview, you're probably a better interviewer than most -- including myself :-)
An employer I worked for made it very difficult (but certainly not impossible, implausible, or even socially unaccepted) to stop interviewing altogether. Instead, they'd take a different approach: in addition to trying to match interviewers with candidates, they would also perform analysis on interviewer's previous feedback (e.g., are they constantly voting down candidates that go on to receive an offer after additional review, or vice-versa?) and weigh the feedback accordingly.
I'd be highly surprised if Google doesn't do this.
I do agree that usual "watch an experienced candidate do the interviews" approach to training is insufficient: this is much like expecting one to become a better candidate by watching a strong quickly "get" an algorithmic question with an a-ha insight, it looks easy when you already know the answer. I love the anagrams example from Programming Pearls -- it appears as "aha" problem, seems obvious to those who already know the answer -- but the book describes in detail on how it represents an entire class of problems and how to achieve that seeming insight using a more structured approach.
As an aside I actually finding interviewing others to be much harder than being interviewed myself -- if I screw up as a candidate worst thing that can happen is I don't get an offer, if I screw up as an interviewer people other than myself (the candidate, the company) will be affected. There's plenty of sites that talk about how to prepare for being interviewed, candidates spend dozens of hours before going for an interview, but there's less material out there for individual engineers who want to become better interviewers. Joel and Yegge are prominent exceptions, but most other pundits say only the obvious, e.g., "ask questions that can tell you if the candidate can do the job?"
I had a google interview about a year ago. The thing I found strangest is that some interviewers would walk in the room and throw up a coding exercise without any introduction at all. They literally wouldn't give their names and what projects they worked on. You don't care that I've been working for almost 10 years in the real world and would rather judge me on my ability to solve a linked list problem? Really? If anything is "gameable" this is. Just spend a year playing topcoder in your spare time and you could ace any of the questions I got.
I have a good friend who works at google and compares the recruiting team to being "the hot girl in highschool" (no intended sexism). Since google recruiters are at one of the elite companies in the world, they can treat people disrespectfully. If you don't like it, there will be a million people more people to choose from. I actually didn't get this vibe from them, but I only dealt with a couple recruiters.
The skills being evaluated in Google interviews (and on topcoder) are of minimal use in most real problem-solving environments. They're a proxy for skill - something many skilled candidates happen to have alongside the skills you actually want.
Linked list questions are a favored choice of this class of interviewer despite the fact that 90%+ of programmers will never have a good reason to write a linked list - or even use one, for that matter. It's a CS fundamental and it's important to understand, just like other data structures, but evaluating a candidate's ability to rattle off a particular linked list algorithm on the board doesn't tell you anything about their ability to solve problems customers care about.
> Linked list questions are a favored choice of this class of interviewer despite the fact that 90%+ of programmers will never have a good reason to write a linked list - or even use one, for that matter.
If you can't write basic algorithms to manipulate linked lists (traversal, reversal, etc) on demand, you almost certainly aren't a good coder. These kinds of questions are a good weed-out pass. They don't correlate with many necessary skills of a good programmer (organization, communication, thoroughness), but at least can detect lack of critical thinking or basic coding chops. They also lead to good follow-up questions that further explore a prospect's critical thinking skills.
These questions shouldn't be used to find human compilers. Oversights like minor syntax errors and the like should be ignored. Answers should be interpreted generously. Even then, you might be surprised how many candidates I've seen that were beyond incorrect. They weren't even in the right ballpark.
You shouldn't be expected to know Floyd's algorithm [1]. But reversing a linked list? Come on, the solution is 50-100 lines of code, 90% of it boilerplate.
I get the impression you didn't read the part of my post where I said these algorithms are useful.
The problem is expecting a candidate to have them memorized and be able to rattle off a particular algorithm from memory in a 15-30 minute interview window, when in the REAL WORLD if you don't remember the exact details of an algorithm, you look it up or grab it from a library instead of writing a busted implementation yourself.
That's why these questions are unrealistic: They're evaluating a candidate's ability to do something you almost never want them to actually do.
Yes, a candidate who can't understand linked lists is probably a bad choice. I never said otherwise. It's lazy to make the leap from that to 'thus, asking a candidate to write a complex data structure utilizing linked lists on the board in 30 minutes is a good idea'. Only if it's something they should actually be able to rattle off like it's no problem...
There are lots of ways to evaluate critical thinking and problem solving skills that don't rely on a candidate having memorized the contents of a CS textbook.
A better interview question is one that focuses on solving a real problem for a hypothetical customer, because that's what most engineers actually get paid to do. If the problem happens to be optimally solved with a linked list, you can see if the candidate arrives at that conclusion naturally, or guide them towards it if they don't.
> The problem is expecting a candidate to have them memorized and be able to rattle off a particular algorithm from memory in a 15-30 minute interview window
I get the feeling that we're talking past each other. It certainly seems that we have different kinds of interviews in mind. I'm referring to about an hour long session where a candidate is asked to solve a basic problem with a linked list. The candidate shouldn't be expected to have the algorithm memorized. Competent developers should be able to work out simple algorithms manipulating a linked list given an hour's time.
> you look it up or grab it from a library instead of writing a busted implementation yourself.
Usually. Sometimes there is no library. The point is the candidate should be able to write the library themselves if needed. The beauty of many linked list questions is that no reference is needed to work out the optimal answer (Flynn's algorithm being a notable exception).
> There are lots of ways to evaluate critical thinking and problem solving skills that don't rely on a candidate having memorized the contents of a CS textbook.
Again, I don't think that linked list traversal and reversal require some kind of arcane CS knowledge. Interviewers shouldn't be asking for e.g. on-the-spot implementations of Dijkstra's algorithm, the Hindley-Milner type inference system or the max-flow problem.
> A better interview question is one that focuses on solving a real problem for a hypothetical customer, because that's what most engineers actually get paid to do.
This is a good complement to a basic algorithmic / coding test. But it doesn't replace such a test.
My PoV is that even if you have the hour or so that it should take for an average candidate to arrive at Floyd's algorithm or something, is that really the best use of the hour to screen the candidate? If your goal is simply to see whether they can solve problems using linked lists, that's noble, but making a candidate spend the majority of an interview trying to arrive at a solution for a new problem from scratch is a questionable decision, especially if each person in the interview pipeline is going to do the same thing with another problem.
For reference, the first time I saw the cycle detection problem it was in an interview, and I had to derive Floyd's algorithm myself. It indeed took about an hour, so your estimate's probably not that far off. The problem is that it's the least optimal environment to solve a new problem for the first time without any assistance or context, which is what you're basically requiring. The candidate is basically left swimming in the deep end of the pool and you watch them flail around and at the end of it, maybe they've come up with a solution to the problem. Maybe they're really close and haven't hit that flash of inspiration yet. Maybe you accidentally misstated one of the problem's constraints and they're never going to figure it out as a result. Pretty lame.
For basic stuff like reversing a LL I agree that no reference is needed to work out the optimal answer, but on the other hand I strongly believe those questions are worthless as a way of evaluating competence. The kind of LL stuff I've seen in interviews skews much more heavily towards Floyd's than simple stuff like list reversal, most likely because the simple stuff is easy.
A good interviewer can certainly detect that a candidate just isn't familiar with LLs, and move to a different problem. I think that's an adequate method too: Attempt to screen out the people who aren't competent at logic and recursion and similar concepts, but without filtering out people who have just never been exposed to a particular class of problems.
On the other hand, if you think having a candidate flail around for an hour (whether they solve the problem or not) is a good idea, there's no convincing you otherwise. I just think it's a pretty poor choice if your goal is to make the candidate and interviewer come out of the experience looking back on it positively with lots of useful information.
function mklist(v, ...)
if v==nil then return nil end
return {value=v, next=mklist(...)}
end
function listeq(a,b)
if a==nil or b==nil then return a==b end
if a.value==b.value then return listeq(a.next, b.next) end
return false
end
function revlist(list, sofar)
if list == nil then return sofar end
local next = list.next
list.next = sofar
return revlist(next, list)
end
function test()
assert(mklist(1,2,3).next.next.value==3)
assert(mklist(1,2,3).next.next.next==nil)
assert(listeq(mklist(1,2,3),mklist(1,2,3)))
assert(not listeq(mklist(1,2,3),mklist(1,2,5)))
assert(not listeq(mklist(1,2,3),mklist(1,2)))
assert(listeq(mklist(1,2,3), revlist(mklist(3,2,1))))
assert(not listeq(mklist(1,2,3), revlist(mklist(1,2,3))))
end
> You shouldn't be expected to know Floyd's algorithm [1].
Bob Floyd had more than one algorithm named after him. I thought you were referring to his beautiful algorithm for sampling without replacement [1], described by Jon Bentley in his CACM "Programming Pearls" column in 1987 [2]. If you don't know that one, it's worth studying for the techniques it reveals.
Yes, but some interview questions are more important than others. I was asked this question before. I didn't know the answer. I still got the job.
A year later, I'm asking the question. I obviously don't hold it against interviewees if they don't know the answer. I see it is a "bonus points" question, not one that will make/break my opinion of a candidate.
Asking about cycle detection in linked lists can be informational even if the candidate doesn't know Floyd's algorithm. Like simpler questions, often the interviewee's thought process is more important than their final answer.
Why do you ask questions that don't influence your hiring decision? I find these kinds of questions quite annoying because I suspect the interviewer is not trying to measure me appropriately - and I have turned down job offers where I thought the interview questions were poor.
Why ask a question when you have empirical evidence that you can perform quite well (I'm assuming you are a good engineer) without being able to answer the question? It makes no sense to me.
> Why do you ask questions that don't influence your hiring decision?
Every question influences hiring decisions. Some questions just carry far more weight than others. Also, the answers often aren't as important as the thought process.
All else equal, the candidate that knows Floyd's algorithm would get the job over the candidate that doesn't. But we're talking about people here, and it's really rare that all else will be equal.
> Why ask a question when you have empirical evidence that you can perform quite well (I'm assuming you are a good engineer) without being able to answer the question?
We don't tell the candidate "write out Floyd's Algorithm". We say "how would you detect cycles in a linked list". If they can't derive SOME solution, that does count against them (and I'll be bold enough to say they probably aren't a good engineer). Someone who derives a decent but suboptimal solution to the problem isn't far behind someone that actually knows Floyd's.
In the end we're ranking people here, not objects. Many things factor into the final decision.
>>Doing a year of such training would raise your actual skill.
Hardly,
Building something would be your actual skill. Taking a product from an idea, finishing it, having some real users use it. Selling the product, and monetizing.
Those are the skills that matter.
Coming to storing trivia in your brain. Any decent guy who gets things done can read and work on such stuff. Its an utter waste of time to spend years putting text book knowledge in your brain, unless your profession is teaching.
So I signed up for an account, yet I was still unable to decipher what exactly it is. It says its a network 100K strong of coders and has the occasional competition. But I'm not sure what content is there to occupy time spending a year "playing top coder".
I think the main page seems confusing because much it is targeted toward businesses looking to have the site's users develop projects via contests.
If you click on Community->Developer it gets a little less confusing and shows a variety of contests. You can find some algorithm contests at Competitions->Algorithm->Single Round Matches->Launch Arena.
When I try this, I get an error message related to Java. When I last used the site, I ended up installing Java WebStart, downloading a JAR file for the arena, and running the JAR file from the commandline.
Overall TopCoder seems like more of a hassle to get started with than it should; fortunately, other sites like YC-funded HackerRank exist, although I'm not sure how the actual content and community compare.
Unfortunately your experience is all too common. I personally interviewed two times at google. The first time I never made it to their offices, but made it through 4 phone interviews, that all went well. After I had gone through the 2nd phone interview, I had started interviewing at another company (well, I needed a job afterall). Within 3 weeks the new company had given me an offer. I meanwhile went to two more google interviews over the phone, and had been stalling on accepting the other job offer, because the prospect of working at google, was exciting. Well 2 more weeks went by, and finally the job offer at the new company was going to expire, so I had no choice but to take it. At this point I didn't see the point of continuing the interview with google, which my internal recruiter at google said would easily last 4 more weeks, as I had not been onsite yet.
Fast forward 3 years, and I had another poor interview experience with google. I flew up there this time, and got to interview in person. It was fun to see the google plex. I had 5 interviews in person scheduled. I felt like I ace'd 3 of them, 1 of them I did OK, and 1 I bombed. 2 days later google informed that that I was not a "culture fit".
I am not sure what the deal was. I felt like I had rapport with all of the interviewers, and I also had 2 internal recommendations. So, maybe that was some canned response way of saying no. Or maybe it was literal.
At any rate, I will never try to apply to google again, even though I too am contacted by a google recruiter no less than every 6 months. Sigh.
I had a very similar experience. I work at an investment bank and was recruited by a large company that does proprietary trading including high frequency trading. I went for the interview which was scheduled to be an all-day thing.
In addition to having been in IT for a very long time I am also very knowledgeable on capital markets having successfully taken CFA (Chartered Financial Analyst) tests. The CFO of the company that interviewed me was shocked that someone in IT passed those tests. The IT people, it was all algorithms and programming minutia. After the interview, they strung me along for weeks and then I just stopped calling them to check up on status and they stopped calling me. Then they would call me every few months asking me to interview again. I finally asked them to stop calling me.
The reason I bring this up is because I think sometimes candidates are excellent candidates for a $100,000 to $150,000 salary position. The only problem is the candidate is already making $250,000 and the prospective employer knows it after you fill out the application. I may be just thinking this to make myself feel better but I just thought the issue with the company was that I made too much. I probably would've had to literally walk on water and bring their dead relatives back to life to justify what they would've had to pay me to steal me from my current company.
I personally have a background unrelated to finance but have a pretty decent tech/math background.
Do you have any suggestions on good entry points into the finance sector, or any advice regarding enrolling in the CFA program/preparing for the examinations?
There's a website called AnalystForum that is very helpful - they can get you started on going for the CFA charter. For Level 1, use Schweser. For Level 2, use Schweser + CFA books. For Level 3, you'll know what you're doing and what works best for you.
The tests are the hardest thing you'll ever do. With little finance background, expect to study about 400 hours for each test and be aware that each test has a 30%-40% pass rate depending on the year it's given.
I went on the subject interview two years ago when I was at the 4 year mark of my current employer. The reason I was looking is because my current employer was being acquired and all of us received a letter stating, "We will tell you in x months whether you have a job or not." It turned out about 80% of my coworkers got laid off but I did not. But I didn't know it was going to turn out that way at the time.
I'm not interviewing now, but honestly they're just trying to figure out a way to cut me out of the picture without torpedoing the business I support. Eventually they'll find a way though realistically it's another year away. I have one fall back company I can go to in a snap at equal pay and I do side consulting about 15-20 hours per week so I'm not worried enough at this point to be interviewing.
Just to pile on here, I interviewed at Google in Santa Monica in 2007. I didn't get hired. The experience was okay, not awful and not incredibly drawn out. Anyway, I brushed it off and moved on. Then, just this April, I received an email from a Google recruiter noting that I'd interviewed in 2007, complementing me on my work since then, and asking whether I'd like to re-engage in a conversation about working with Google. I wrote back saying sure, I'd like to discuss the opportunity. I never heard anything back again. Six weeks later, I wrote again, asking whether there was some issue, and saying it was strange to reach out to me, for me to reply, and then to hear nothing... but still... nothing. No response.
Then, a few weeks ago, shortly after I'd accepted a new position that I'm actually quite happy with, I received another similar email from a different Google recruiter. I wrote her back and told her about the other recruiter that had recently reached out to me and then went silent after I responded. She promptly called me and we talked. She agreed it was strange, said she didn't see anything in the system about it, but she did apologize and - we had a discussion about Google, the interview process and what it's like now (as opposed to 2007). If anything, it sounded like it would be incredibly long, bureaucratic, drawn out, and fairly ridiculous. I said I'd keep in touch with her if indeed I did want to re-apply to google, but I think I do not.
I'm pretty sure that the recruiters are all contractors, and are all fairly independent. I think that's the only think that explains stories like this, as well as some experiences I've had with them.
I interviewed at the New York office for an SRE job a few months ago. It took about 10 months for the whole process to play out. In the end, after a full day interview, I was supposed to get the written up feedback from every interviewer regardless of whether I got the position or not.
Instead, my last communication with Google was a phone call where I was told that one of the interviewers still hadn't handed in their written review. It's now three months later, and that's the last I heard.
That left a sour taste in my mouth. I wasn't expecting to get the job, and really it was just a backup plan in case Algorithmic.ly didn't work out, but you'd think they'd have the common courtesy to get back to me. I'm sort of expecting that 6 months from now I'll hear from them out of the blue...that's how disorganized the process is.
1) Larger companies get away with inefficient recruiting because they can. If the same company abuses you twice, and you go back a third time, what's that say about you? It certainly goes a long way to explain why they can do it.
2) If you're considering going back on an offer, or interviewing just days after starting a new job, you don't have much room to complain about bad behavior on the company's part.
Perhaps another reason that Google contacts many people the same time is their heuristics. They have analyzed what good potential hires look like, and instruct their recruiters (who all use the same few online resources) to screen for it.
Honestly I think GOOG (and some others) sometime interview people to fill time. I was contacted years ago; You want me to do what? What I wanted to ask was "what could possibly inspire you to think that has anything to do with me?" but instead I just said k thx bye. Not a effective way to hire, but a rather effective way to get focused attention. Even though I was kind of laughing, it certainly got my attention and got me thinking, which is great PR.
They're much too busy to do that. In fact they've recently shrunk the amount of interviews per candidate to free up time. The issue you're describing sounds like a recruiter that doesn't understand the subject that they're recruiting for.
>> Larger companies get away with inefficient recruiting because they can.
I would disagree. I interviewed with MS, Google & Amazon multiple times. MS & Amazon are definitely much more organized and very prompt in following up with decision.
I do enjoy this author's flagrant disregard for Google's NDA they require you to sign and promise not to discuss the interview questions. I'm curious if they'll enforce it.
For what it's worth, my one experience with Google recruiting last year was the polar opposite. They were curious and professional, of more knowledgeable recruiters I've dealt with, and timely in scheduling interviews. I had my first and only phone interview within a couple weeks if contract (which I needed and used to go through the extensive list of prep material they provided). Then I had an onsite interview a couple weeks later. Bam. Done.
I did a phone interview with Google last week. I was given the exact same counter problem as mentioned in the article. I can verify that I was not asked to sign any NDA at any point.
Phone screenings do not require signing an NDA (just a "we explicitly ask you not to share the questions you're asked"), but if they bring you on site you will be asked to sign one.
Except when not. When I was interviewing they didn't make me sign one. They rejected me for the original position, but later occasionally called me with some alternate options. These calls usually went like:
- We would be interested in having you at/as ... but before the specifics, you signed an NDA, right?
The phone interviews are not but the in person ones are. I'm sure it has to do with the fact that you are onsite and may oversee confidential information but they explicitly stated to me that it covered the interview questions.
You asked how they would enforce it. You did not ask for a likely outcome, you asked for possible outcomes. If you want specific answers, ask specific questions.
Even in case of success and receiving an offer, I personally have a feeling that you need to be very very lucky to get the really interesting work in these BigCo's.
I know a couple of googlers, talented programmers, but they ended up as "yet another CRUD" python devs there.
That's the thing, if I'm expected to have these algorithmic chops for the interview, I'd better get to actually use them on the job! Selecting for a bunch of algorithmic geniuses just because you're Google and you can, but then assigning them to boring CRUD app projects, is wasteful and makes no sense, but I get the feeling that it happens.
There's lots of interesting projects going on at Google and an internal system for applying to other teams, and usually no shortage of teams asking for people. There's not a lot of CRUD apps with the exception of Corp-IT stuff.
It seems like everything they do are CRUD apps, in the sense that they are concerned with creating, updating, reading, and destroying database records. They are just massively parallelized on the backend to deal with all the traffic.
Sometimes I wonder what all these engineers do every day. Their main apps are not getting exponentially better, and they have fewer of them. Why is all this algorithmic knowledge really needed? Do they spend all day optimizing or engineering and planning new features?
Not trying to insult Google, but I'm not seeing a ton of new features that would justify this kind of indepth theoretical knowledge. The ability to actually code, to do so efficiently and quickly, and to properly unit test and profile it, seems more important than any algorithmic knowledge. Mastery of the toolchain and the language, and that comes down to - "What have you produced?"
Maybe this is why Google hasn't had a new hit product in what seems like awhile. It doesn't need one as long as they maintain their position as search leader, but it doesn't seem like they have one.
I think this is being relatively unfair in assessment. Google hasn't had a hit product in a while? Search and Ads are dominant. Android is the #1 mobile smartphone OS with 80% of the market. Chrome is now the #1 browser. Google Maps is the #1 mapping application. Gmail is now #1 in active users. G+ now has 190 million active posters now monthly now (Twitter only has 110 million active posters) YouTube is the top video site.
Most of these apps listed above are not CRUD apps. The service based ones have significant and non-trivial data processing on the backend, lots of machine-learning, or algorithmic data processing.
Google apps have been getting better over the years, but Google updates them almost continuously and incrementally because they are web based, and so most of the changes go unnoticed like a frog slowly being boiled in water.
Is Google Search the same as it was 5 years ago? No, it has Google Instant, voice search, Knowledge Graph, direct answers, better spam filtering, it's index is far fresher, etc. For example, just the interactive chart knowledge panels (https://www.google.com/#fp=9a975e048e4bd6d6&q=population+of+...)
Google Maps has gotten radically better, and the latest beta maps is probably the most complex and sophisticated web application ever engineered.
Google search within G+ and Drive actually does object recognition with neural networks. (http://googleresearch.blogspot.com/2013/06/improving-photo-s...) This is a huge improvement in image search, and most people are totally unaware of it. It just works and they don't notice that it found it image without even needing descriptive text or tags.
Google apps are slowly getting smarter each and everyday but there's no "Jobsnote" to laud them, so the improvements are invisible.
> most of the changes go unnoticed like a frog slowly being boiled in water.
Believe me, I notice. GMail and GMaps get slower and slower every day. I can't actually use GMail anymore; clicking anything takes several seconds. Wasn't this way in 2005, and I had a crappier computer then.
I would consider Maps, Gmail, and G+, CRUD applications. What does it take to not be a CRUD application? I'm not sure. I think every web-based application in which enormous amounts of data are stored and manipulated qualifies as a CRUD application, even if they involve lots of intelligence and batch processing on the backend. Many of them are CRUD with a Big "R," as they mostly involve consuming data. Maybe my definition of CRUD is too broad.
Knowledge graph and instant search are amazing feats, but with thousands of engineers working all day at Google, each of these products seem to be only incrementally improving, as you say, and I would almost expect quantum leaps forward in terms of new products. But Google probably has all sorts of things in their pipeline.
These products were already incredibly impressive, as well as huge hits, and I use them every day, so I'm not really dissing them so much as I'm noticing a lack of new, hit products.
Your definition of CRUD is incredibly broad and covers just about any application that reads or writes anything to a datastore, regardless of whether the datastore is ACID or some custom storage system for something like a huge graph of geometric data. Do you consider Quake a CRUD application? How about GwtQuake, a web-based version that consumes big BSP files? What about Minecraft?
CRUD to mean has traditionally meant traditional database applications, CREATE, UPDATE, and DELETE, after all come from SQL keywords. These apps are primarily table oriented.
Google Maps isn't even close to being a CRUD application in the traditional sense. How many CRUD applications have you worked on that used Octrees? And why does "web based" make something CRUD? Is a native Android app that does SQL RPC calls and just manipulates a typical entity-relationship database quality as CRUD?
Anyway, back to hit products. Google Now was released only 1 year ago and is a new hit product. How many new hits per year do you want? ;-)
Also keep in mind that Google has moved from launching lots of tiny apps with separate branding, to unifying their various platforms and implementing things as features across app. For example, the neural network based image search is a really a service that appears inside of Drive, G+, etc, just like Hangouts appear in multiple apps, as well as Google Local data.
The general thrust is to get away from launching an array of dozens or hundreds of sites, and to make stuff just "work" within the apps you use already.
To clarify that, the general thrust is to unify everything onto G+, eventually. Should be fairly obvious and I inferred as much even before I joined Google.
Good luck with that. I fear the day when my Apps domain is forcefully migrated to Hangouts. Hopefully there will be an alternative to Apps by then that is actually worth using.
(One of the people present during my firing needed to summon his boss using internal Hangouts. He eventually gave up, went back to his desk and got his laptop because the experience is completely unusable while mobile. It was hugely amusing to watch, and drove home the dogfood drama for me -- you know what I'm talking about.)
That's not strictly true. Google Search itself has inherited the ability to run image search, mail search, drive search, and calendar search within the front page.
Sorry to hear about your firing BTW, hope everything works out. I believe in second chances and I don't think people should be blacklisted for all time for something far in their past, with certain exceptions (e.g. sex crimes and working with children, etc)
Actually, I'm not sure if you are rather not contradicting yourself as most of the more technical projects - or the core technologies used by them, for example, webkit for chrome, dalvik for android and so on - (which the parent was presumably talking about) - correct me if I'm wrong here - were not developed at Google but at other (i.e. the developers of these projects, typically, didn't come through the Google's recruitment process) companies which were later taken over by Google.
It seems disingenuous to have the achievements of those companies be co-opted by/as Google/'s
Most of the improvements in Chrome were wholly done at Google. V8 was done from scratch at Google, as well as the security system, and Google contributed more to WebKit over the last few years than Apple (just go look at the commit graphs). The majority of Android/Dalvik was done at Google after Danger was acquired AFAIK. Google didn't acquire Android ready made.
These days, most software isn't developed in a vacuum. WebKit was a fork of KHTML. Does Apple get no credit for the changes made to it?
Google Maps and Google Earth were acquisitions as well, but the state of those products when they were acquired compared to where they are not is completely different.
If you look carefully most of these big companies have one thing in common. They have one major source of money, and everything else is either acquired or something trying hard but failing to be the mainstream revenue part.
Agreed there have been few home grown innovation from Google, those are all from early days.
Current achievements are all leveraging on their existing user base, and are not necessarily due to the merit of their products.
WebRTC, Hangouts, Chrome, Android, distcc, etc. All very useful non CRUD projects. Google+, the search engine, analytics & advertising have 2nd order projects that are not CRUD.
I cannot make general statements, but it's really hard to move when you are assigned to a project where you unhappy. I tried to transfer to several other teams in my area of expertise. I was quite close in a couple of places, but they usually run out of 'head count' at the last moment. There was just one team that could have taken me, but it was the same kind of boring custom coded BI I was doing in my project. Finally, I just had to give up. The bad part is that I did many 20% projects for these other teams, which hurt my chances for promotion.
It could be that the type of project one is one influences. I'm pretty sure if I tried to join the maps team, I'd be rejected, I have no experience in geo/gis.
But I have had the experience of co-workers transferring off my team to other teams and semi-regular turnover, so it may be a matter of finding the right place at the right time.
"I'm pretty sure if I tried to join the maps team, I'd be rejected, I have no experience in geo/gis."
Ah but from the linked article, if the only selection criteria is ability to answer weird 5-minute-depth trivia questions about data structures, not actually knowing anything about GEO/GIS wouldn't even be discovered, much less an impediment.
Of course, they might have a totally different, less pathological system for internal transfers than for external hiring...
Google's recruiting seems like it must be at least partially the responsibility of short-tenure contractors. Every time I've dealt with people from their recruiting department, even the very nice ones seemed forgetful, inattentive and poor at communication. The actual Google employees who do the interviewing are on average very bright, good at actively interviewing candidates (instead of just rattling off questions), and open to answering questions, even if a couple of them were clearly inexperienced and uninterested in doing interviews.
I'd say the actual experience of the interview can be a good thing, but the process as a whole is a huge waste of the candidate's time - especially if you don't fit the stereotypical niche of what a Google employee is (4+ years of CS education, thinks writing linked lists and trees is exciting, etc. etc.) Their decision to intentionally avoid giving any feedback to candidates probably stops people from gaming the interview process, but it also makes it a net negative for candidates who don't meet the unstated criteria Google is after - criteria that could often be screened for before a candidate ever sets foot on campus. They refuse to interview candidates for a position or a role beyond generalizations like 'software engineer', despite the huge breadth and depth of problems solved at Google - if you're lucky they'll quiz you on the stuff you actually know, but most likely they won't, and the questions will be very mundane. This despite the fact that actual hiring choices ARE partitioned to some degree (as much as they seem to want to pretend they aren't).
Most of the time interviewing with a good company is a 'why not' scenario: The only thing you have to lose is some time, and you'll learn some useful things from most interview experiences (even if occasionally the only thing you learn is 'this company is awful'). Google's interview process feels precisely engineered to avoid letting candidates learn anything whatsoever.
Companies like Microsoft or Amazon or Zynga all at least have a pretense of evaluating a candidate's specific strengths and weaknesses to figure out whether they're useful - if you're a compiler engineer MS will probably have some Visual Studio/DevDiv people grill you with compiler engineering questions, if you're a games dev Amazon will have you talk to people from their games department, and if you're a database guy Zynga isn't going to ask you game design questions. For Google interviews it seems entirely one-size-fits-all, despite the fact that they have core products that obviously depend on niche knowledge and experience.
> Google's recruiting seems like it must be at least partially the responsibility of short-tenure contractors. Every time I've dealt with people from their recruiting department, even the very nice ones seemed forgetful, inattentive and poor at communication.
I had a Google recruiter contact me once when I was actively looking for a job. Her initial email was just the basic, "we saw your CV and thought your skills in XYZ would be a good fit. Would you be interested in setting up an interview?"
I replied within about 15 minutes to tell her I was interested. My next contact with her was almost five months later, and incredibly, she just said, "Sorry for the delay, I've been really busy. Are you free on Thursday?" At that point I kindly told her I had already accepted an offer somewhere else. I wanted to tell her the new company had treated me well over the ensuing years, that I had worked hard and advanced to a respectable middle management position, retired, and was currently traveling the world with my grandkids, but I thought that might have been a bit precious.
Is this something that may be unique to the bay area though?
I went through several rounds of interviews with a couple different startups, and two of them were non-responsive to the point it was annoying. I can understand startups being less "professional", but some of them treat you more like a number than some of the bigger corporates I've worked for.
>>> but it also makes it a net negative for candidates who don't meet the unstated criteria Google is after - criteria that could often be screened for before a candidate ever sets foot on campus.
The crazy thing is they don't give feedback, then call back in a few months and ask if you want to interview again for the same position like the OP said. Talk about completely confusing people. . .
This is not uncommon. I had the same experience with a certain well known communications company in SF. After a bungled interview (my fault, not theirs), the same recruiter contacts me again no less than a month later. By that point I had accepted a position elsewhere, but it was certainly a mixed signal bag.
Yep. You'd think they'd consult their own database on whether it's worth talking to a candidate (or whether the candidate is excluded from interviewing due to their lockout rules...) but their recruiters don't, which is part of what makes me think they must be contractors.
From those questions, it sure seems like their interview process is aimed at choosing among recent grads whose resumes are all essentially the same "B.S. Computer Science from School X".
That's what they tell people too. It's great if you just graduated from a formal CS program because the algorithms stuff is fresh in your brain. Whereas working 5-10 years in a boring bigcorp, doing CRUD apps will kinda make you more "dumb"
Hah, I must be pretty dumb. After over 10 years working on anything from startup to BigCorp, I doubt I could answer a single one of those questions right now.
I did learn that in my last round of interviewing (about a year ago) that to play the game you need to review the junk that you'll never need to keep in your brain, that you know but don't have at command. Sure, you'll most likely never use it at the position you apply for, but that's the rub.
I genuinely don't understand how it's useful to interview someone this way. It basically makes it a game of 'Show us what you remember from CS101/MAE101/etc'. Really why should interviews for people established in the industry be like that? Sure you should know how to do basic algorithms and optimization type questions, but having minute detail style programming questions that every engineer not fresh out of college will have forgotten since their core discipline classes is just silly.
Yeah, I don't know how it's useful. I think you could get just as many bad developers who are brilliant as good developers who are brilliant.
I worked with a bad brilliant developer who just couldn't produce production code to save his life. We all saw where he was going with his code but he couldn't get there. We'd all end up cleaning up his code to get it into a better place. He would've aced interviews like at Google.
Not sure how it could be considered age discrimination though. You tend to forget 'knowledge' like this fairly quickly. I know for my part at least I generally have to brush up on this kind of learning about every six months (or even less perhaps), if I wanted to retain it.
It would be like requiring you to recite all the marks you received on all your assignments in all your classes in your last semester of your senior year of college. I assume that if you had just graduated, this would be easy, but if you had graduated 10 years prior, this would be hard (feasible if you'd kept the paperwork--but hard).
I recently interviewed at a medium-sized tech company in Palo Alto that only had recent graduates on my interview schedule. I really don't know if I could have expected them to ask questions other than standard CS / data structures / algorithms questions.
Why those employees would be put in a position to interview with such a short time frame of professional experience, let alone recruiting experience, is beyond me.
I hate this so much. The interviewer must realize how strange this is when he/she has to brush up on questions they're about to ask a candidate for a similar position to their own.
As someone still in school (in a very theoretical CS program), I still like to skim over a good part of CLRS before before an interview that I expect to be over algorithmic stuff.
To counter some of the negative sentiment here, I had a great interview experience at Google. The only big negative was that the whole process took 5 months. But every step involved was very organized and the people were professional and thoughtful. The in-person interviews were also great and the questions were all appropriate. I did not take the offer for personal reasons at the time, but the process was great (except for those 5 months). As with all big companies though, there is a bit of luck of the draw involved, as the other stories in this thread show.
I was asking myself while reading the article, my god, what kind of job was he applying for, AP test author, programing language standard library author, puzzle book author, or what exactly?
I haven't gone into a cold interview in many years; its always previous relationship based now. Are cold interviews where no one already knows anyone, like that now, focused on weird algos and trivia questions and nothing to do with the actual job?
You're interviewing the workplace as much as they're interviewing you, and I'm smart but I have no idea how to evaluate a possible employer based on their selection of weird trivia questions. Something that at least vaguely relates to the actual job would be interesting.
>>>>You're interviewing the workplace as much as they're interviewing you.
Not nearly enough people realize this. If they're asking you corny questions in the interview, how does that reflect on their company? OP said they didn't even ask him questions about his resume - just these corny trivia questions. If I was there, I would've asked how someone thinks this is relevant to doing my job at Google.
After the past three years I've done a ton of interviewing and have learned the only way to know if the company is good fit is to grill the interviewer on stuff that matters to you. I've had interviews at fortune 50 companies with people who had no idea who their competition was or where they wanted their IT department to be in 5 years. If you're not invested in your company, what makes you think I should??
Interesting idea popped into my head... If candidate is not going to ask good questions about the job and experiences and responsibilities and challenges and the company, should the interviewer torture the candidate with random pages from Knuth until candidate either asks a good question or breaks or runs out of time. (say yes! say yes!)
The other idea that popped into my head is we could develop a new "secret geek code" for HN readers where asking candidates endless queuing theory questions means we're secretly warning the interviewee about long lines in the cafeteria, lots of tree data structure trivia questions means a warning about an intensely hierarchical management style, weird trivia questions about designing thread safe interrupt handling routines means you'll be pestered a lot when you're trying to work which you may or may not be cool with, that kind of thing.
> Interesting idea popped into my head... If candidate is not going to ask good questions about the job and experiences and responsibilities and challenges and the company, should the interviewer torture the candidate with random pages from Knuth until candidate either asks a good question or breaks or runs out of time. (say yes! say yes!)
General etiquette for this sort of sitch seems to be to allow the person with more leverage to lead. Most of the formulaic/cold interviews I've had they'll get to the end and then ask you if you've got any questions.
Hmm... I'm unemployed that means they have leverage, I'm employed and looking that means I have the leverage?
Now that I think back over the years, as a stereotypical break the ice event is at the start of an interview, they usually thank me for taking the time off from work, at which point I mention I burned a vacation day to meet them and I've only got X left this year, at which point I tend to feel a little arrogant, I'm burning a rare limited day off for these guys, they'd best make it worth my while...
I know they're just fishing to see if I'm ethical enough to burn vacation instead of calling in sick, or maybe lying about being currently employed...
Your leverage is something like, 'Everything someone wants that they think you can give them, or take from them, for which they think they have no acceptable, (in terms of their culture,) alternatives that aren't more costly than whatever you'd impose on them in return.'
There's also an aspect of norms to it - most commonly in terms of consistency because people generally want to appear reasonable.
Anyway, if you've already got a job, their position looks worse in that respect since you need them less. Though that doesn't necessarily give you any more leverage in terms of extracting concessions from them since your job doesn't necessarily make you a more desirable employee.
Though, for some reason, companies seem to hang themselves in that regard - placing a great emphasis on whether you're unemployed, (which, personally, I've never found to be a great predictor.) So, while it's not an 'of necessity' thing, it probably does convert into some leverage on your part for a lot of potential jobs.
It is, in a round about way, why it's generally better to try to bargain about wages after you've got some sort of buy-in established on their side. Since you'll have the greatest leverage once they've decided they want you.
Things that you can point to that you can quantify, that's generally a good source of leverage - especially if you're a contractor. Anything I do that I can hang any sort of number on, I write down to use in interviews - not all of it goes onto my CV.
Agreed - I enjoyed my Google interview. HR showed me around the building when I arrived. All the interviewers were friendly and not intense at all. In each interview we did the random algorithm question, and then had 10 minutes or so of talking through my questions. Lunch was good. It was a long day - the whole experience was basically tiring but I wouldn't call it stressful.
Most importantly HR told me in advance exactly what to expect, and that is what happened. I wasn't expecting much discussion of my experience or previous projects - but the algorithm questions turned up right on schedule, and they were on the topics I'd been told to review.
I don't know why people get so bent up over this and write these screeds.
Surely everyone knows the drill by now. If Google interview you, you'll get a bunch of random algorithm questions and you either get hired or you don't and they won't tell you why. Your CV and your experience only serve to get a foot in the door. After that its all down to those algo questions. This is not a secret - I think they are pretty up front about the way it works.
I think Google prefers false negatives over false positives. I know a few extremely smart people who didn't "pass" their Google interviews. Most likely because they didn't have that "totally positive effortlessly nice and socially easy" vibe.
That's probably the right attitude to take in hiring. Bad code is difficult and expensive to discover and fix and a bad hire is difficult and expensive to let go.
With proper code review, I don't think bad code is difficult to discover. I also don't think dismissal is very expensive for large corps. For smaller companies or start-ups, the game is entirely different.
I interviewed at Google earlier this year. It was a complete waste of my time. The questions were unrelated to my skills and the position I was looking for. You go in there assuming they know what they are doing because they are the great Google. They don't. It's completely random.
My interview at Google was a disaster. I passed the phone screens (easy), and then they flew me out to Mountain View. Now, the job was actually programming python for YouTube.. which I could have done in my sleep. I've done similar things for years, for many other companies (even some in the Valley, even though I live on the East Coast). So whatever, I thought it was going ok, and then they asked me a bunch of puzzle questions (which I sucked at.. at least I'm pretty sure I did). (You know, the typical mindless puzzle questions that are completely unrelated to anything remotely resembling the work you you'd be doing). I'm sure it sounds like I'm bitter (I'm not), and I'm sure there are many smarter than I am that do well at those things. But I couldn't help thinking that they should've asked me something related to what I'd be doing, or what I'd done.
I didn't get the job, but now Google keeps calling me for interviews. I keep telling them no, that I'm not 'Google material' whatever the fuck that is. Not me. Love Google, awesome tools, great stuff.. don't think I could work there.
My experience with Google corroborates some of this.
Particularly the unpredictable callbacks and repeated contacts despite being within the 18 month period and complete lack of feedback post-interview.
Additionally, there was plenty of confusion about which position I was being asked to interview for. Initially, it was something completely outside my skill set, later it was a bit more refined, but not at all specific.
I did encounter some questioning where the interviewer seemed to be looking for one rather specific answer, but nothing nearly as bad as "I wanted you to use a priority queue. We will just move to another question." or "Time's up. Maybe you can ask your friend there what the answer is."
Amusingly, a friend of mine who interviewed there not too long ago ended up receiving and declining an offer only to be called and asked about his "start date" months later.
That said, my experience was generally positive and I'd do it again given the chance as most of my difficulties came from the recruiting end.
Just to add my experience with Google to the pile:
After the initial screenings and interviews with two different recruiters (one from Dublin and the second one from Switzerland) I finally get to the first technical interview. I struggled a bit with some questions, but I did get to the optimal solution in the end. I felt I could do better, but the second recruiter assured me that I did really well. He even sort of apologized because he needed to schedule a second phone interview, before inviting me on site.
The second interview, as far as I can tell, went the same as the first. I made some mistakes along the way, but I did get to an optimal solution at the end. The interviewer told me I'll get the results by the end of the week. Two weeks pass and still no word from Google. I decided to send an email to the recruiter, asking for an update. Still nothing. After a month I decided to send a friendly email to my first recruiter asking for an update - I didn't know what else to do. The second recruiter replied the next day telling me it was a "close call" and that I should re-apply in 12 months. No thanks :)
The obvious reason for this approach to me is that Google is leveraging their reputation in order to solve difficult problems rather than actually looking to hire anyone. The answers this particular interviewer appeared to answer seem to be the kinds of things that a developer would want to know but might not be able to see the answer to.
The idea here that Google might be leveraging knowledge from a hopeful dupe, is echoed by their annual code challenges. The company wants to know things. It's hungry for knowledge.
My feeling that leading on applicants is the best way to be ignored when you need one because when you cry wolf, only the wolves answer the call eventually.
"Aside from being terrible at communication, Google implicitly rejected, without appeal, someone with offers for a PhD and someone who owns two checks from Knuth. "
I'm glad that Google doesn't just blindly look at credentials alone. If you got a PhD, and got featured in a CS publication, but couldn't answer their questions, then you probably shouldn't be accepted. That said, OP just had bad bad luck. My phone screen question was FAR easier (I still messed up on it, and got to the on-site too).
Disclaimer: I went to a Google interview last week (got rejected)
It sounded like he aced all of the questions except for the distributed computing ones, where he put up some reasonable answers but not the exact ones they're looking for.
I'd note that when Google was first solving those problems, their luminaries who are now untouchable at the company probably tried those exact same reasonable answers at first until iterating on them into their current form.
Saying "no" is a hard stance to take. Google undoubtedly does have some very smart people and some very interesting work, so it's difficult to throw that away because one perceives them as brain damaged when it comes to relationships and interviewing.
And of course there's always the "if you say 'no', there's always someone who will take your spot happily."
My brother had an interview for their X division. He said it was really strange. They were very very secretive. My brother has a TS clearance and he said Google was beyond the US gov.'s paranoia even. It made it a really tough interview too. He said it felt like they couldn't tell him anything so the interviewers were trying to psychicly communicate with him. Then they took him to lunch on campus which was ok and then sat him in front of another guy who was nicer but still mum. Also they apparently can't talk about the google glasses even though some lady had just walked out the door with them. Its like : 'Dude, you can see them right there.' It seems they need to get hungry again, not be complacent in their domination of our lives.
I had a very similar experience with Google London and Google Zurich. It took them longer than a year to arrange an interview. Quite disappointing -- I'm actually glad I decided not to join them.
Yikes, this story and HN comments sound like disasters.
As a sorta balancing out here, my experience interviewing with Google(June 2012) was fantastic IMHO. We agreed right off the beginning what role exactly I'm interviewing for(Test Engineer), different from what I applied for(SDET) and went with it. Note, that I was holding them off for about 2 years. They'd email/call me every 6-8 months, and I'd say "Hold on, gimme a few more months". Eventually stuff happened that caused me to email them back and say "Okay, let's do this."
I had the first typical phone-screening, talking about myself 'n such, why I'm looking for another job, why Google, etc. They gave me a bunch of blog links to "Life as a TE at Google" 'n stuff. 2nd phone screening was a programming thing that was kinda hard but not out-of-bounds PhD stuff. I was a bit intimidated by the fact I spent the whole hour on a question that was labeled "Question#1". I asked about it, the SoftEng. told me "Oh, don't worry about that". I asked if there were more questions, he said again not to worry... hmm. I did talk a lot though so he knew what I was thinking while trying to code.
Anyways, a week later I get an email from a Google recruiter saying the SoftEng thought I knew what I was doing so we set up the MTV visit with 5 or 6 people. I was super-excited I made it to the on-site visit. Did you know Google Maps on mobile behaves differently if you're on campus? :) Everything happened on time.
The interview questions and conversations we had for those 6 hours were great, eye-opening for me. I will say that I went into this whole Google thing with an open mind and with the assumption that all these people had more intelligence in their toe-nail than I'd ever obtain in my life.
In the end, 2 weeks later, I was told that they "wouldn't be going forward with me". Of course I was bummed, I didn't even tell my family I was interviewing with Google. I wanted it to be a surprise. But, they showed me my weaknesses and I fixed 'em. Now I have an awesome job(SDET2) and I think the only reason I was able to get through this job's interview process is because Google's interview improved me significantly.
Ha, I didn't tell anyone in my family, including my SO I went to interview with the Big G either. Didn't want them to see how disappointed I would be if they rejected me.
Google sucks. I had a pretty similar experience interviewing there. Strange, late interviewers. One guy who barely spoke English and another who literally asked one question, then said nothing for the rest of the "interview." Then, a pointless "feedback" call in which they told me they "can't provide feedback on specific candidates." Overall, just a really poor experience. F- 'em, move on.
Are we doing this to ourselves? If we are willing to continually subject ourselves to hours (and days) of interviewing, followed-up by abusive responses (or non-response), it seems like this recruiting behavior will continue.
The irony of all this conversation is that the people I know at Google are some of the sharpest, most well adjusted people that I know. It's almost like they got in and thrived despite the recruiting process. None of them are the type to stand people up, gloss over interviewing, or be anything other than decent hard working individuals.
Curious about the 'official' answer to the counter question. I'd have thought just having something triggered daily to clear out increments older than a day would be enough.
I don't know about an official answer but using a simple variation on a round-robin database (RRD) ought to do the trick. Basically:
day count = [last 23 hour buckets] + hour count
hour count = [last 59 minute buckets] + minute count
minute count = [last 59 second buckets] + second count
second count = <running count cleared every 1 second>
You end up losing a small amount of accuracy, the worst being for keeping track of the second counts. You can avoid that by using an actual list of counter values for the seconds bucket and dumping those out when they get older than a second, or maybe by introducing another subdivision -- 1/10th of a second probably is good -- so that you actually have .9 seconds worth of data and can interpolate the last bit.
The last hour now goes back from 22:45:03.435123897 (remember, nanosecond timer, but now it is from 22:46:07.223981453. Unless you can round the time when the last second, the last minute, etc start, you have to keep the full history of increment events up to the nanosecond for the last 24 hours. That's O(246060*1e9).
But if you do round the time to an acceptable degree of accuracy (say, to within 1ms of the second count and 1m of the day count) then it does work within a fixed amount of memory. It's probably the best solution.
It's a lovely exercise in algorithm tradeoffs. In this case it's mainly accuracy vs. memory, with lots of opportunity to explore implementation optimizations.
Just playing, but "If you have n servers that take requests, and server Sᵢ can take a request every tᵢ seconds, and you need to distribute requests to them as efficiently as possible, how do you do it?" can be done very easily in Go.
You have a shared channel which contains the pending requests, and a goroutine per server that simply loops doing: read from the shared channel, perform the request, wait for the sleep period, and continue the loop.
And that's all. Each server will get requests as fast as it can consume them.
And that solution is isomorphic to the one the interviewer was looking for, where you put the requests in a priority queue keyed by their finish time and pull out the next one that'll be done. The only difference is that the priority queue in question is hidden in Go's scheduler.
The reason interviewers ask these questions is so they get a sense of whether you'd be able to implement Go, starting from first principles. (Or actually, it's because before Go many servers and load-balancers were written in C++ using async callbacks, and so this is a very pragmatic question that comes up a lot in real-world usage.)
It's isomorphic and better, because each goroutine performs a synchronous and easily understood acquire-perform-sleep looping operation with no hairy coordination. And even underneath, it's somewhat simpler, because neither Go nor the design I gave cares which of the runnable goroutines (the servers that have finished their work) takes the next request off the channel. Plus the blocking behaviour of channels gives you implicit backpressure if the requests are coming in too fast - the process putting them on the channel will stall.
You probably should care which server gets the request. It's not explicitly said, but if one server can handle twice as many requests per second, then it might be completing each request faster. If that's the case, it's a better service to give more requests to the faster servers.
Worth at least discussing to see if there are other aspects to the problem.
Not to throw water on your thought process, but the abstraction you describe is hardly unique to Go. It's called a "semaphore", and has been pretty well described and implemented for several decades now.
That's an easy solution in any language, frankly; have a shared queue of the requests, and the servers simply pull from the queue whenever they aren't processing a request. I'm sure that this is easier to implement in Go than a lot of other languages, but I think this actually defeats the purpose of the question. The hard part of the question is how to assign work to the servers rather than letting the servers pick the work themselves.
Yeah, I just picked Go because it's one I know well and it's a 5 second solution that handles the question as asked. It would be just as easy to do in ruby for example, with EM::Queue.
I actually intended this as a way to "assign work" rather than having the servers pull. Each goroutine "owns" a server and forwards all requests to it, but it's just part of the one load balancer process, and the load balancer does nothing but balance.
IMO, defeating the purpose of a question is how you solve problems in real life.
Now if you wanted a harder question, you could follow that with: OK, that solution will give the servers time to do their thing, but there's no guarantee it won't just end up dumping all the load on a few servers, straining infrastructure and under-using the other machines, because there's no guarantee Go's scheduler is fair. So please develop two competing solutions. First, a fair scheduler that spreads the load evenly. Second, as an alternative, an unfair scheduler that always fills 100% of the time on the first machine before moving on to the second, and so on, and reports how many machines it's using so we can take the others out of the pool and repurpose them.
Google is probably more interested in hiring people who can answer that rather than your answer.
"There's a library for that" is a great answer for 99.9% of businesses out there, but google's problems aren't that of the 99.9%. (Nor in fact are they in the 99.9% of the remaining 0.1%)
Although I don't work at Google, I feel like this just patently is not the case. I firmly believe the vast majority of devs at Google aren't writing the next massive distributed and concurrent datastore with strong guarantees on transaction sequencing, aka F1 on top of Spanner.
The vast majority of people aren't writing the things that get, or would get if they were publicly available, research papers at Google.
They're using those things, written by the 1% of the 1%, to do things really, really generic, like display advertisements or store emails. There are some people in language development (Dart, Go, probably some others and some DSLs), there are some people doing hardcore database design, they probably have some people working on hard problems in their datacenters, from reducing latency on commodity hardware to networking infrastructure.
Are the majority of Google employees writing things that only the 0.1% of the 0.1% can solve? No, they don't even employ enough software engineers for that to be the case.
I'm pretty sure that storing emails or displaying ads is not nearly as generic or as easy as you think.
My justification for asking algorithmic interview questions is because I believe that engineers using libraries should understand exactly how they work, so they know what design compromises the implementation chose and how that affects their higher-level application. Just because you aren't going to be writing a database doesn't mean you shouldn't know the various levels of transaction isolation that exist.
What he's described is pretty trivially done in most modern languages/frameworks. I can write the same in C#, Scala or C++11--swapping greenlets for standard threads, which honestly is unlikely to be a perf concern--pretty trivially.
The hardest of the above would be C++, because boost::threadpool isn't officially part of Boost--though it works fine--and otherwise you'd have to get a little creative with boost::thread_group (but in doing so it'd probably be only slightly more complex than the Go version).
I mean, it's a nice feature, albeit bolted to a language with a lot of issues. But unless you have pressing reasons to look at Go, something like that sounding easy probably won't really trip your trigger. =)
You don’t need a thread pool or threads at all. Just schedule a timer for each server. You could do it in JavaScript.
I’d even guess that a JavaScript implementation would be more efficient than Go. A goroutine has an overhead measured in kilobytes; a JavaScript timer is presumably smaller.
Yeah, I realize you can accomplish the same result in almost any language, but not nearly as easily. It's the syntactic sugar that impressed me, and the fact that's it's such an integral part of the language.
Interviewing at Google can be terrible. I was an intern who had high scores in my reviews (my host rated me just below 'superstar', whatever that means - I'm not really a superstar and just assume that was some rating jargon they used at Google).
Anyway when it came to my conversion interviews the person who was supposed to interview me wasn't at the office. I ended up waiting around for someone to interview me, and when they came in 15 minutes late we had to trek across campus to get a room. I was asked a fairly difficult problem and botched it pretty hard, and of course didn't have the complete time to attempt to solve it.
I thought I nailed the next interview though! After I answered a couple pretty complex problems the interviewer literally said there is no way you're not getting an offer, and we just ended up chatting a bit.
I got rejected a few days later, not totally unexpected as I knew I botched that first interview. When I asked my host about it later he said the second interview wasn't even on record.
C'est la vie, I guess. I'd still love to try again, I had a lot of fun working there, the people are top notch - even of the hiring process is extremely hit or miss.
Seriously, if a company I interview at is genuinely threatened by me talking about my interview and questions, maybe they should reconsider their viability as a business--things being so precarious and all.
NDAs for employees generally seem to be bad signs for places worth doing business at.
Practically speaking, Google isn't going to do anything besides blacklisting. Can you imagine the stories in the tech press if they sued someone for breaking an interview NDA?
In that case apologies for the mis-assumption. But maybe better to label quotes to better indicate whether you are quoting in agreement or disagreement for people who don't remember the quote.
My reading of the API is that getCountInLastSecond returns the count from the last billion nanoseconds, not the count from the previous second bucket (as the clock ticks).
So when he mentions he can't bound memory, it's because he can't easily discretize the counters.
I feel that this is an important ambiguity. When I read the article, my first question was whether this interpretation is correct, or the other one. I am surprised that he didn't clarify this in the article, and wonder if this is a problem.
Seeing ambiguities in specifications is an important part of software engineering.
Imagine an infinite time line, with a marker moving across the line at the speed of time. Every time increment is called, that marker is saved on the timeline. When getCountInLastX is called, one must return the number of marks on the timeline from the current time to the current time minus X.
I had similar situation many years ago for a different large company. Two before lunch interviews, and I bombed one. Then the rest of the day's interviews seemed easier and I did splendidly. I felt great. A few days later, two job offers from that company, but not from the group I had originally hoped for. I passed and took another job I was more excited about the group I would be with. Later I knew a friend that worked there, he told me that they used the first two interviews to decide which track of second interviews you get after lunch. So then you are with other candidates for other jobs if you have not done in the top of the first round. Something like this may have happened to this fellow, just that the other candidates in the secondary track won out over him making an even better impression.
A friend of mine got a call from Google and set up a phone interview. They never called. The recruiter called again a few days later and apologized, and set up another phone interview. Once again, no call. The recruiter called again and my friend told them he was no longer interested.
I interviewed with Amazon once, I reached only the phone part and failed (most part for my own reason... I fumbled a lot)
But I was really bothered, that they setup "X" to interview me, and when I got the call, it was "Y" because "X" travelled, and that "Y" was not related to the position I applied at all, AND was a newbie at Amazon and thus failed to answer the questions I had about it, AND did not knew any languages I knew, making the coding part of the interview very weird.
I also saw similar stories here in HN many times... I wonder, wazzup with those companies that setup interviews and then send the interviewers somewhere else?
I was the surprise interviewer in the exact same scenario (well, not at Amazon, but same general idea) and was later cross examined, mostly by HR, about how well I thought he'd be able to help me if I came to him. The HR cross examination about his ability was all touchy-feely questions not technical (did what he say sound nice, not, did what he say make logical sense when passed thru the well known engineer BS filter). Position had one of those estimates of 25% helping other people with problems and group work, and he would have been hanging out near me although somewhat different kind of work, so it seemed fair for me to ask him noob questions about his expertise, just to see how he would talk to someone on the team from a different background. He was an expert in C++ if I recall correctly.
All went pretty well with me, although they didn't hire him (donno why)
The part of the story that was weird is I was an old-timer at that employer not a noob. Why they'd assign a noob to evaluate indicates either extreme trust or extreme desperation WRT the noob. Or he was playing you. If you really needed a question answered HR would take care of it.
There's something odd with this page that causes Safari to jam up and use 100% CPU. It shows up as "Processing Math 0%" in the lower left corner while doing this.
Is there some kind of renegade JavaScript going on here?
Interesting, especially since I've just started working for Microsoft, in Bing Ads, and a big factor in deciding to come was the interview process. The phone interview involved writing code in a shared environment, the in-person interviews were all nice (hard questions, non-threatening ways to ask), and I (and the other 4 guys who interviewed in my time slot) were told yes/no right after the interview ended.
I assume experiences at large companies vary widely depending on the group, but I was definitely impressed with Bing's interviewing process.
Before anybody goes to try and get hired at a "hot" company, please please please check out glassdoor's interview experiences and ratings. You'd be surprised at how shitty some companies treat people during the hiring process. I've experienced it myself a couple of times.
The worst (actually, the one bad) job interview experience in my life was with Google. The interviewer was extremely unfriendly, had a thick unintelligible indian accent, and didn't try to hide the fact he had something more interesting to do than interviewing me.
index billions of web sites, stock around 850+/share... but their recruiters/interviewers can't return a call/email or show up to give an interview on time. This something that small and large companies have been doing successfully for ages.
They seriously need to work on their culture in this aspect. It seems like such a trivial problem to fix inside of google. What is the hold up? I'm certain there are more good interviewing experiences than bad interviewing processes, but it does seem to be a common theme over there.
Ok, the RealTimeCounter problem got me thinking. It's a great question. It seems very simple, but as the author notes even PhD's are stumped by it. Here my solution.
One very important purpose it serves is to see how well you can identify problems in algorithms. Probably I'm guessing it's not even important that you get it perfect, just that you can recognize and talk through the challenges.
One challenge relates to understanding the requirements. It needs to return the count for the preceding period of duration N, whether N is a second or a day. It could and usually does start in the middle of the preceding second, day, etc. It's a constantly moving window. That means if you just reset the counter each time you pass the absolute boundary of the next N (1:00, 1:01, etc.), you lose accuracy.
So that suggests that you might have to track each individual increment() somehow. But there's the next challenge, memory usage. If you just store all the timestamps, that's linear memory growth every time increment() is called.
So it seems to me like the solution is a tradeoff between memory usage and accuracy. If you don't call increment() very much or have a lot of memory, you can get perfect accuracy.
So that's the "theory". Now here's where it gets more interesting from an engineering perspective. Optimal implementations. Here's what I came up with in about 15 minutes.
First you minimize memory usage by storing offsets instead of the complete timestamp. Do this in 2 arrays, one for the preceding interval and one for the current one. This makes it easy to exploit our knowledge of when we've crossed the interval boundary, e.g. via now().getSecond(), to clear out old data.
(I am only considering one type of interval like seconds here.. you could extend this to minutes, hours, days by duplicating this method, or perhaps theres some way to consolidate more optimally.)
Anyway, increment() takes the offset from the fixed start of the current interval, i.e. the nanoseconds since the start of the current second, and appends it to the Current array. It also checks if we've passed into the next interval, in which case it reassigns the Current array to the Preceding array and starts a new Current array. The getter functions also do this.
To get the count, the getter simply
1) Finds the nearest offset in the Preceding array to the current offset (could just loop over it, start in the middle, etc.)
2) Subtracts that index from the array length to count the number of in-scope increments from that preceding interval (this works because the array is naturally sorted)
3) Adds that to the length of the Current array (because everything in the current array is in-scope)
SO, that should be a pretty fast way to do it with minimal memory requirements. If memory's going to be a problem,
A) you could spend a little more computation to do a kind of garbage collection. In step 2, resize the array to clear out the out-of-scope indexes. (Maybe you'd want a more optimized kind of data structure than a vanilla array for this.)
B) reduce accuracy by quantizing the offsets.
Ok am I hired yet? I'll go wait by the phone.
Just kidding, I'm sure this is wrong in many ways. But the point I'm trying to make is that it's a great problem for exploring tradeoffs, yet easy to understand what's being asked and requires no special technical knowledge.
With a little extra hardware, you can get perfect accuracy and low memory usage even if increment is called as frequently as once per nanosecond. Google is big enough and rich enough to afford a little custom hardware.
Here's the hardware I want added to the computer running the counter server: 4 lasers capable of pulsed operation at a rate of up to one billion pulses per second with a pulse width under 0.1 nanoseconds, 4 light detectors capable of detecting such pulses, and 4 corner reflectors.
The corner reflectors shall be placed 1/2 light second, 30 light seconds, 30 light minutes, and 12 light hours away from the computer, and each laser aimed at a different one of the corner reflectors. The detectors should be placed next to the lasers so as to detect the return pulses from the corner reflectors.
The computer then maintains 4 counters. When increment is called, each of the counters is incremented, and a pulse is sent toward each corner reflector. The return pulses decrement the counters, with the detector associated with the first reflector detecting the one second counter, and so on.
I realize there are some practical problems here, such as one of the corner reflectors needing to be placed approximately 90 AU from the computer. Of course the path could be folded using reflectors, and maybe could be sent through a medium with a high index of refraction to further reduce the distance needed, but my guess is that it would still be a bit out of range of current technology.
A few hours ago when reading the article I was also intrigued by the question and journeyed down a similar path regarding the moving window and the trade-offs. After toying with a couple of improper solutions I came to a very similar conclusion. The basic idea being that each time increment() is called, you store the difference since the last increment, and to count you simply add up the offsets until you reach your desired time limit. Anyway I emailed myself the basic idea to post here later. There are probably some obvious optimizations but it satisfied me as a solution. Pseudocodish javascript example below:
var second = 100000000
, minute = second * 60
, hour = minute * 60
, day = hour * 24
, current = 0
, lastIncrement = 0
, increments = [];
function increment(){
current = timer.time();
increments.push( current - lastIncrement );
lastIncrement = current;
}
function getCountInLastSecond(){
var copy = increments.slice()
, total = 0
, count = 0;
while( ( total <= second ) && ( amount = copy.pop() ) ){
total += amount;
count++;
}
return count;
}
Your array will grow indefinitely. Not a viable solution, it seems to me.
Incidentally someone else posted a round robin database solution. It's probably the way to go. That's more or less where I was headed with quantizing offsets.
Well to be pedantic it will grow, at worst, to (24 * 60 * 60 * 1000000000), if you are calling increment() every individual nanosecond. Though you are right that it is ignoring realistic memory issues. I was approaching it more as a thought exercise to address the moving window.
Your bigger problem is with this "trim the array" idea, which is definitely not an obvious solution. The way you've coded it you'd have to tally almost the entire days worth of deltas just to determine the trim point. And you may still exceed that single-day max memory, because you'd accumulate overruns in between trims. I'll leave you to think about that one.
(Hint: google round robin database. You know, the solution that I mentioned.)
Interestingly, based on the explanation at [1] round robin databases actually don't precisely solve the question as described in the article. It sacrifices precision for larger increments, and the author was looking for an exact algorithm.
It seemed obvious to me that you would trim it if it became larger because the most it asks for is the count of a single day.
However, now that I think about it increment() could called multiple times during a single nanosecond, in which case I guess it would be multiplied by whatever the maximum number of executions per nanosecond would be. My once per nanosecond comment earlier was an erroneous assumption.
Large companies often fall into the trap of lack of communication between departments and individual employees. They get so big they trip over their own feet. I used to work for Melbourne IT, a behemoth with hundreds of employees spanning multiple countries. Customer relations was a disaster, with each customer being told conflicting things by different sales people and customer service reps. Sorry you had such a bad experience.
I don't agree with the fact that they were rude, which is what is it to not respond in these cases, but they didn't do anything particularly offensive except for leaving him in the dark. All he needed to do was take a job offer, if Google really wanted him, they could fix their mistake(s) of waiting so long. The comments though for this article are pretty egregious, it's too bad interviewers are that awful.
When this person got there, two of the people they were supposed to meet with were traveling on business and hadn't notified the recruiter. A third was out sick. The supposed-to-be fourth, now first interview walked into the room and said, "Look, I don't have any idea how to interview product managers, so I'm going to ask you calculus questions", and proceeded to start to write equations on the board. The fifth interview was the first and only that happened AND dealt with product management.
When they got back to NY, this person was notified that they'd been rejected, then notified this was a mistake and they'd have to come back to MTV to redo all of the interviews, including the two that had happened.
Obviously, at this point they told Google to go scratch and went on to do really good work elsewhere.
I've interviewed at and worked for a number very very large companies before, and none of them have been as disrespectful at interviewing and hiring as Google sounds from these stories.