If working for Google is such a Valhalla, why do people leave after 1.1y
https://www.quora.com/Why-do-Google-employees-have-such-a-lo...
Why I Don’t Talk to Google Recruiters
311–320 of 674 posts
Re: Why I Don’t Talk to Google Recruiters
#312Earlier quoted context omitted.
the problem with the way Google interviews is that, despite it being heavily standardized, it is not sensitive to non-algorithmic skills and talents that interviewees have. It will _only_ pass candidates who are unusually good at algorithm puzzles, on whiteboards, under time pressure.
> it is not sensitive to non-algorithmic skills and talents that interviewees have. I work at Google and do interviews (though I don't enjoy them). We do ask questions around domain expertise, software design, etc. It's not all just coding and algorithms. A good question: 1. Has a low enough floor that a poor candidate can still make some progress and not feel like they are doing poorly and get stressed out. 2. Has a…
My experience hiring at (YouTube.. at the google campus), was similar to the original post. 3 phone screens (which I must have done ok on), and then they flew me out to CA. I went through the interview process.. got tripped up on the 'puzzle' questions (which I thought was bullshit for a Python programming job.. but whatever), and then didn't get the job. I actually agree with what was said in the original post: this process probably works well for the type of employee Google/Youtube wants to hire.. shame on me for not doing my homework.. I guess. However, I can tell you what definitely was a complete turn-off, was the odd obsession of seemingly everyone there with where I/(you) went to school. At least 5 times: me: 'I live near Princeton'. they: 'oh, did you go to Princeton??!!! (elation)'. me: 'No.. I went to a state school'. they: 'oh.. ' me: (silently) 'yeah.. I'm sorry. It gets better.' Again, whatever.. in truth, I appreciated the opportunity to interview.. no big deal.
What was even weirder after that was, for no less than 6 years, to be 'actively' recruited (again) by Google. My position each time was: thanks, but not interested in going through another bullshit interview where I'm continuously reminded that I didn't go to Princeton. I'm just not Google material.
In all seriousness, in my opinion, Google is one of the best companies in the world and is run and staffed by the best minds in the Industry. My hat's off to them for all of their accomplishments. I just don't want to work there (even if I could :)
Re: Why I Don’t Talk to Google Recruiters
#313There is no point in giving me binary-tree-traversing questions; I don't know those answers and will never be interested in learning them. Let's presume this is out of preference and not ability. It's a pretty basic concept. If your preference stops you from learning something as basic as this as a programmer, then it doesn't seem likely that you will be motivated to keep up with even more abstruse concepts. Nearly e…
Conjecture: the majority (by far, probably on the order of 75%-80% or more) of programming and engineering problems to be solved in a typical company or typical application will not see significant differences in performance by selecting a naive implementation. For example, in your string concatenation example, the naive solution is good enough except in situations where large numbers of strings are to be concatenate…
Details do not matter until they show up. Still take string concatenation as an example. Suppose you want to highlight some particular words while a user is actively typing characters in a dialog. If you naively concatenate every character, the user may have responsiveness issues or at least wastes CPU cycles/battery unnecessarily. Small cases like this add up in a big project.
My conjecture is that a big fraction of programs could get significant performance boost noticeable by end users if they were developed by good developers who have some knowledges in algorithms. You don't need to be an expert, but knowing very basics on time complexity and fundamental data structures is necessary to every programmer IMHO.
Re: Why I Don’t Talk to Google Recruiters
#314Earlier quoted context omitted.
But Google's code quality is quite high...
I don't know about their code quality, but we consume some of their data via APIs and they periodically randomly change their non-nullable data types to nullable. Fun times hotfixing those in prod.
Funny you point this out. Google's JSON Style guidelines[1] say this:
>If a property is optional or has an empty or null value, consider dropping the property from the JSON, unless there's a strong semantic reason for its existence.
[1]: https://google.github.io/styleguide/jsoncstyleguide.xml?show...
Re: Why I Don’t Talk to Google Recruiters
#315Unlike most of HN (it seems), I like hearing from recruiters, because despite the very low signal-to-noise ratio, there's always that remote chance that one of them could be able to set me up with a "dream job". It's zero cost to me to politely reply to a recruiter and ask for more info, and I try to at least respond to everyone. What I've found is that they must have a lot of candidates they're juggling because fall…
My conversations have usually gone like this: "Hey, you look like a great candidate for $AWESOME_JOB" "Great, let's talk" "Oh, you're not really what they're looking for, can I interest you in $GARBAGE_JOB or $BASEMENT_AT_YELLING_CORP" But by then I've showed interest, so I start getting calls. Not worth it.
Seen that, but more often than not it's:
I see you're working as $ROLE in $COMPANY_A. How would you like the exact same $ROLE in $COMPANY_B? Or worse, How would you like $ROLE-1 in $COMPANY_B.
Sorry but it's going to take at least $ROLE+1 to get me to uproot my life and go through that interview gauntlet again.
Of course, as I said in another post, the calculus changes entirely if you're unemployed and need "something, anything".
Re: Why I Don’t Talk to Google Recruiters
#316Earlier quoted context omitted.
Conjecture: the majority (by far, probably on the order of 75%-80% or more) of programming and engineering problems to be solved in a typical company or typical application will not see significant differences in performance by selecting a naive implementation. For example, in your string concatenation example, the naive solution is good enough except in situations where large numbers of strings are to be concatenate…
> Select candidates who are keenly interested in and knowledgeable about algorithms for positions where it's important (i.e. part of the regular course of development), not because of that slight chance there is one edge case where one adjustment to a more efficient algorithm might possibly be useful at some indeterminate point in the future. Well put! At the end of the day, it's way more important to get your produc…
Customers won't necessarily come back after you rewrite your product to deal with all the perf problems your naive implementations caused.
I'm all for striking the right balance with perf concerns, but in my experience that's not "just deal with it later". Giving no thought to performance is as bad as micro optimizing at the beginning.
Re: Why I Don’t Talk to Google Recruiters
#317Earlier quoted context omitted.
The notion that traversing a binary tree requires expertise in algorithms seems questionable to me. I view basic tree traversal as table stakes for a developer with more than a year or two of experience (IIRC, it's discussed in Intro to Algorithms in most CS curricula). OP says that his field is object-oriented design, which links to a page where he announces that "We've started work on a new programming language". T…
Funny you bring up the CS curricula. In response to not knowing the speed of sound as included in the Edison Test, Albert Einstein replied: "[I do not] carry such information in my mind since it is readily available in books. ...The value of a college education is not the learning of many facts but the training of the mind to think." This is even more true today with the vast trove of easily searchable called the Int…
That story about Einstein doesn't illustrate what you think it does. Einstein was a theoretical physicist, not an experimental physicist; there's no reason for him to have known the precise value. However, you can bet that Einstein knew the theory quite thoroughly (review his writings if you believe otherwise) and would have been rather less than impressed by anyone calling themselves a physicist who did not.
And aside from that, let's face it, none of us here are Einsteins.
Re: Why I Don’t Talk to Google Recruiters
#318Earlier quoted context omitted.
I don't know about their code quality, but we consume some of their data via APIs and they periodically randomly change their non-nullable data types to nullable. Fun times hotfixing those in prod.
When data comes in over the wire, you probably shouldn't be making assumptions about what's nullable. You should write a parser that fails gracefully if it receives unexpected input. It's the robustness principle. https://en.wikipedia.org/wiki/Robustness_principle
You're missing the point. Sure, you should make it fil gracefully on unexpected input. But Google shouldn't change APIs in a way hat causes 3rd party apps to fail at all.
Re: Why I Don’t Talk to Google Recruiters
#319Earlier quoted context omitted.
the problem with the way Google interviews is that, despite it being heavily standardized, it is not sensitive to non-algorithmic skills and talents that interviewees have. It will _only_ pass candidates who are unusually good at algorithm puzzles, on whiteboards, under time pressure.
> it is not sensitive to non-algorithmic skills and talents that interviewees have. I work at Google and do interviews (though I don't enjoy them). We do ask questions around domain expertise, software design, etc. It's not all just coding and algorithms. A good question: 1. Has a low enough floor that a poor candidate can still make some progress and not feel like they are doing poorly and get stressed out. 2. Has a…
Speaking as someone who's done these interviews (but was never, for the record, asked about anything other than coding/algorithms): I think the core premise is flawed. The idea that a good developer is somebody who can regurgitate knowledge they learned on Wikipedia in a few hours from memory is just not a good base for determining if the engineer is good. More importantly, a developer who cannot regurgitate the knowledge from memory is not necessarily a bad developer, or, frankly, in any way otherwise distinguishable from the guy who can.
Re: Why I Don’t Talk to Google Recruiters
#320There is no point in giving me binary-tree-traversing questions; I don't know those answers and will never be interested in learning them. Let's presume this is out of preference and not ability. It's a pretty basic concept. If your preference stops you from learning something as basic as this as a programmer, then it doesn't seem likely that you will be motivated to keep up with even more abstruse concepts. Nearly e…
Conjecture: the majority (by far, probably on the order of 75%-80% or more) of programming and engineering problems to be solved in a typical company or typical application will not see significant differences in performance by selecting a naive implementation. For example, in your string concatenation example, the naive solution is good enough except in situations where large numbers of strings are to be concatenate…
Conjecture: the majority (by far, probably on the order of 75%-80% or more) of programming and engineering problems to be solved in a typical company or typical application will not see significant differences in performance by selecting a naive implementation.
True. And people who clutter their code by using some fancy "StringStream" class when they could've just used a concatenation are also part of the problem!
Saying that programmers don't need a basic knowledge of algorithms is like saying drivers don't need to know how to back up a trailer or do a 3 point turn. Over 90% of the time, you don't need it. But when you do, you really do!