4 ms·

> However, I'm also pretty sure I'd have more chance on the Google interview right after graduation then now, when all the theoretical stuff was fresh in my bra

> However, I'm also pretty sure I'd have more chance on the Google interview right after graduation then now, when all the theoretical stuff was fresh in my brain. So I'd have more chance while being a (in my opinion) less useful engineer. The thing to understand is that Google is more interested in not hiring potential bad hires than in hiring every good hire. Part of the reason the interview process works the way it does is to filter for people willing to put in some effort. If you want a job at Google, it's not a big deal to spend 3-5 hours a week for a few months getting sharp on the basics. If you're not willing to do that, then that's a good sign that you're not really invested, and may not be the best hire. Google will totally lose some good hires this way of course. But their philosophy is explicitly that it's better to lose a good hire than make a bad hire. I think they're probably right.

hueving 10y ago
>Part of the reason the interview process works the way it does is to filter for people willing to put in some effort That's the sales pitch, but it's actually just because there is no other interview approach that works at scale for the volume of candidates they get. If they didn't have a stack of 100,000 resumes, they would throw this ridiculous process out the window in a heartbeat and actually interview people for the position.
- nolemurs 10y ago
  > If they didn't have a stack of 100,000 resumes, they would throw this ridiculous process out the window in a heartbeat and actually interview people for the position. Absolutely. If they had far fewer resumes then they'd be much less willing to pass on potentially good hires, and more willing to risk bad hires. You make it sound like we're disagreeing, but this is 100% consistent with what I said.
  - awfgylbcxhrey 10y ago
    You're not saying the same thing at all. Your statement assumes the process eliminates bad hires, while GP's point is clearly that it doesn't. I'm not agreeing or disagreeing with either side, but you clearly aren't in agreement.
VLM 10y ago
"it's not a big deal to spend 3-5 hours a week for a few months" I think I can get further ahead than a job at Google for that kind of time investment. I don't mind big expenses, I just expect corresponding rewards.
- nolemurs 10y ago
  I mean, all the big tech companies use a similar white board/algorithm centric hiring process. If you're interested in working for one of them, 40-60 hours is really not a big investment to be in a good position to apply to all of them. I totally understand if that sort of job just doesn't interest you, but I'd be really curious as to where you think that 40-60 hours will get you a better ROI.
  - Rapzid 10y ago
    If you already have a good job? Exercise maybe.
fixermark 10y ago
handwave It's a tradeoff. What you may have atrophy a bit being out of academia for a little while is the jargon and some nuance stuff (i.e. can you still reason formally about big-O notation, do you still know the names and relative behavioral constraints on all the fundamental data structures, even the ones you personally haven't had to touch for a decade because your specific industrial domain hasn't really necessitated them---can't tell you the last time I coded my own hash function over just using whatever the default "map" / "dictionary" / "object" is in the language I'm using). What you will have an advantage on is the real-world stuff that an undergraduate new-grad may not have ever seen yet, like "How do you actually build a system that can move data from a web-based UI with authentication through to a database or backend-processing infrastructure and then back out to the user (and how do you scale out a system like that when it starts to bottleneck)", "How do you monitor and maintain a system after you've built it," and (probably the biggest gap between graduate-knowledge and real-world knowledge) "Cool algorithm; how do you verify it's right?" A surprising number of undergrad programs still don't teach unit, functional, or integration testing as a significant aspect of software engineering.

hueving 10y ago

>Part of the reason the interview process works the way it does is to filter for people willing to put in some effort That's the sales pitch, but it's actually just because there is no other interview approach that works at scale for the volume of candidates they get. If they didn't have a stack of 100,000 resumes, they would throw this ridiculous process out the window in a heartbeat and actually interview people for the position.

nolemurs 10y ago
> If they didn't have a stack of 100,000 resumes, they would throw this ridiculous process out the window in a heartbeat and actually interview people for the position. Absolutely. If they had far fewer resumes then they'd be much less willing to pass on potentially good hires, and more willing to risk bad hires. You make it sound like we're disagreeing, but this is 100% consistent with what I said.
- awfgylbcxhrey 10y ago
  You're not saying the same thing at all. Your statement assumes the process eliminates bad hires, while GP's point is clearly that it doesn't. I'm not agreeing or disagreeing with either side, but you clearly aren't in agreement.

VLM 10y ago

"it's not a big deal to spend 3-5 hours a week for a few months" I think I can get further ahead than a job at Google for that kind of time investment. I don't mind big expenses, I just expect corresponding rewards.

nolemurs 10y ago
I mean, all the big tech companies use a similar white board/algorithm centric hiring process. If you're interested in working for one of them, 40-60 hours is really not a big investment to be in a good position to apply to all of them. I totally understand if that sort of job just doesn't interest you, but I'd be really curious as to where you think that 40-60 hours will get you a better ROI.
- Rapzid 10y ago
  If you already have a good job? Exercise maybe.

fixermark 10y ago

handwave It's a tradeoff. What you may have atrophy a bit being out of academia for a little while is the jargon and some nuance stuff (i.e. can you still reason formally about big-O notation, do you still know the names and relative behavioral constraints on all the fundamental data structures, even the ones you personally haven't had to touch for a decade because your specific industrial domain hasn't really necessitated them---can't tell you the last time I coded my own hash function over just using whatever the default "map" / "dictionary" / "object" is in the language I'm using). What you will have an advantage on is the real-world stuff that an undergraduate new-grad may not have ever seen yet, like "How do you actually build a system that can move data from a web-based UI with authentication through to a database or backend-processing infrastructure and then back out to the user (and how do you scale out a system like that when it starts to bottleneck)", "How do you monitor and maintain a system after you've built it," and (probably the biggest gap between graduate-knowledge and real-world knowledge) "Cool algorithm; how do you verify it's right?" A surprising number of undergrad programs still don't teach unit, functional, or integration testing as a significant aspect of software engineering.