31–40 of 239 posts
This is getting ridiculous. These guides to interviewing at specific companies are starting to sound like the video game cheat code books of old. If the process is so nuanced that there's an entire industry around these types of guides (and Google even highly recommends you buy them!), then the process is fundamentally flawed. But we already knew that, and as long as others are still playing the game, we are forced t…
This is getting ridiculous. These guides to interviewing at specific companies are starting to sound like the video game cheat code books of old. If the process is so nuanced that there's an entire industry around these types of guides (and Google even highly recommends you buy them!), then the process is fundamentally flawed. But we already knew that, and as long as others are still playing the game, we are forced t…
That is too say, their interviewing process explores things at sufficient depth and breadth to make knowing "the" solution not a deciding factor.
Earlier quoted context omitted.
I'm in the interviewer pool @ Google. > practice writing syntactically correct code on a whiteboard This probably differs from interviewer to interviewer as to how strictly it's adhered to, but it's not really a hard and fast rule. I'm sure there are some interviewers that will ding you on a forgotten semicolon, but I suspect that most would not. Personally I look for code that isn't so far from syntactically correct…
> But I've had candidates that try to make up language features, and that doesn't fly with me. This piqued my curiosity. Can you give an example?
The question asked was a very short multiple choice; only two of the answers were possible under immutability.
Genuine Question: Apart from maybe the money or a nice resume entry, why would you/do you want to?
I don't work at Google (and I don't agree with some of the things the company's decided to do) but have many friends who enjoy working there. From what I hear, Google has an organizational structure that is very favorable for regular engineers. Once you're hired and you put in around a year of work in a team, it's almost trivial to find another team. Engineers also directly evaluate managers and I've heard stories of…
Honestly this sounds like a thought experiment.
Do you have any ethical hangups about entering an environment where falling out of your favor can leave someone stress-crying in their place of work and/or about their livelihood.
If so, how much money would it take for you to join the system anyway?
How long would you stay in such a system if you found yourself already in one?
Back in the real world, in a business context, it sounds like an abusive workplace and an untenable system. Like, that obviously can't last forever.
This is getting ridiculous. These guides to interviewing at specific companies are starting to sound like the video game cheat code books of old. If the process is so nuanced that there's an entire industry around these types of guides (and Google even highly recommends you buy them!), then the process is fundamentally flawed. But we already knew that, and as long as others are still playing the game, we are forced t…
learn with the intent to become a better engineer, even if you don't hit the google mark (which is arbitrary anyway), you will become a better engineer. That is the philosophy most people should use when trying to aim for these companies. Don't cram, learn.
This is getting ridiculous. These guides to interviewing at specific companies are starting to sound like the video game cheat code books of old. If the process is so nuanced that there's an entire industry around these types of guides (and Google even highly recommends you buy them!), then the process is fundamentally flawed. But we already knew that, and as long as others are still playing the game, we are forced t…
Even Google suggest to "practice writing syntactically correct code on a whiteboard". This is clearly a useless skill as a software engineers except in getting a job at companies that do whiteboard interviews. Did you try to refactor code on a whiteboard?
How are they able to find people that are able to efficiently debug problems?
When I interview people I tell them, "Bring your own laptop set up to be able to code and debug". And I give them "Fix this site" or "build this thing" kind of problems.
It looks like that it works a lot better to find "hidden gems" and people that are good at "doing" instead of those that are jsut good at "telling".
This is getting ridiculous. These guides to interviewing at specific companies are starting to sound like the video game cheat code books of old. If the process is so nuanced that there's an entire industry around these types of guides (and Google even highly recommends you buy them!), then the process is fundamentally flawed. But we already knew that, and as long as others are still playing the game, we are forced t…
On the contrary; the fact that Google recommends them indicates the process is not flawed. That is too say, their interviewing process explores things at sufficient depth and breadth to make knowing "the" solution not a deciding factor.
Earlier quoted context omitted.
On the contrary; the fact that Google recommends them indicates the process is not flawed. That is too say, their interviewing process explores things at sufficient depth and breadth to make knowing "the" solution not a deciding factor.
Maybe the sort of person who has the time/desire/interest to study a guide to figure out how to fit in at google is exactly the sort of person they want to hire.
They don't test for good engineers -- they test for people who practice these style interviews, and for good new graduates.
It makes sense to ask these questions to new grads, but afterwards there is so much more experience that I feel like is much more important than acing data structures questions.
I am amazing at whiteboard questions, but that doesn't make me a good engineer. It's because I found the trick to solving these, and have practiced them. A lot of it it is practice 'ooo this looks like a graph problem, let me use a graph', etc.