171–180 of 239 posts
Genuine Question: Apart from maybe the money or a nice resume entry, why would you/do you want to?
I hate these style of interviews. I give them to prospective engineers every week for one of these FAANGM companies. 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…
Earlier quoted context omitted.
Perhaps using the crying manager example was a bad idea on my part. What I can stand behind is having an org structure that encourages managers and execs to treat their employees well. It sounds like Google has done a better job than most. I'm sure there are managers and engineers crying in private in every big company out there. What I'm trying to say is even though a lot of people like to assume that people work fo…
There are at least two problems with this: - "I'm sure there are managers and engineers crying in private in every big company out there": You're not excusing google here, just expanding the range of companies whose apparent behavior is mortifying a couple of people in this thread. - "Google probably does some things very well to keep all the talent despite the negative press it gets.": probably. They probably do a l…
Is this referring to how they creepily track people, or are they doing worse things which I’m not aware of?
Earlier quoted context omitted.
> (They'll write crap like "()f" or "f()a" when they want to call a function, stuff like that.) Who cares? If they write code that's well engineered and works in your product and they rely on auto-complete or whatever, isn't that what your business needs and why they really pay you? Furthermore, said code will be written from a comfy chair while they listen to their favorite music, with access to Google, SO, etc. And…
I think the function syntax thing is one of those things that's so basic that someone who gets that wrong probably doesn't code very much.
Unless you're giving public demos/performances (which is what an interview is), this skill set isn't nearly the most relevant one for the job.
EDIT: This is a fascinating analysis of this phenomenon from a pilot's perspective: https://youtu.be/BBpqvPujZgM?t=1135
The video is the post-mortem of a plane crash at an air show with the pilot involved. In the part I linked to, he talks about the psychology of a skilled person when put under this kind of pressure and how the quality of their decision making can quickly break down. The whole video is also great if you're interested in aviation.
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…
I completely agree. 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…
One of the best interviews that I've ever had was a screen-sharing session that was based around much the same mentality: "I have this problem. Script a solution in whichever language you choose in notepad. Now, here's sample data. Run it. O.k. It doesn't work as you intended, so start debugging it."
We (as an industry) focus on developing, when debugging is an equally desirable skill. If you can't understand why your code is breaking and need someone else to assist you, then it isn't - necessarily - a bad thing but you are consuming another resource that could be best devoted to other things during the time it takes to sort the problem that you created out.
A friend said recently, "people want to be employed without becoming employable". These guides really exemplify this obsession. Sure, Google has a nice salary and good perks and whatever. But after you get the job, you have to do the job. I wonder if the people who read these guides and try to study just the right topics to get a job, whether they actually like programming. These guides act as optimizations, shorteni…
I'm scared shitless of whiteboard exercises (and - probably biased by that - see no point in them). There's no way I'd be able to get through them UNLESS I optimize for .. whiteboard programming interviews w/ resources like this site.
In spite of writing code every day, for 15 years plus, and although I LOVE programming, this just excludes me from the list.
(This hits a bit close to home for me because my employer of 13 years just got bought and I'm in the process of looking for interviews again - for the first time since 2006..)
Received the green light and moved to the next phase, where I spoke with potential teams over the phone, then settled with Google Maps. Met with one of their Tech Leads, cool. I was really happy and though that all my effort to prepare for the “Google interview” had payed off.
Then no word back from the recruiter with a final offer. It turns out the VP of eng saw some red flags in my interview and decided to bail.
I felt really frustrated and while I spoke I spoke with the recruiter he apologized and even said the hiring manager was on my side and people overall liked me but there were two engs that were on the fence. Gosh, I think I met with 7-8 engs, all the seniors seemed to like me. I remember not having the best conversation with 2 engs who were new to the company and could not relax nor communicate well.
Bottom line, prepare but also be prepared for some degree of luck and arbitrary judgements.
Yes, there are great interviewers in google. Engs that are engs in their minds and hearts, who can see the process is not perfect but work to get it better. But unfortunately, there are insecure folks who should be better trained for before interviewing candidates.
That was 5 years ago, not sure I would subject myself to this sort of loop even again. And strange enough they contact me few months after to reinterview but this time I could skip the big loop and meet with just 3 engs... I said no since I was already in a new job.
Earlier quoted context omitted.
Better designs require fewer lines of code [#]. Maybe the person spends more time thinking than writing. Also think about a typical enterprise Java program - writing lots of boilerplate code is bound to create fantastic muscle/syntax memory and no useful skill beyond that. [#] If this doesn't seem obvious consider the inverse - worse designs will inevitably require more lines of code to get the same result.
Better designs require fewer lines of code I think that's extremely dependent on context. I write mostly SQL and bash and would argue that both languages are not conductive to try to reduce size at the cost of future maintenance.
Earlier quoted context omitted.
I think the function syntax thing is one of those things that's so basic that someone who gets that wrong probably doesn't code very much.
If you put someone in a fight vs. flight situation, and add in the task saturation of the coding interview, a competent person can react adversely and make basic mistakes. A week ago in a conference, I watched an SRE who I knew was very competent have a panic attack when a demo didn't work as expected. I never learned what exactly happened, but apparently it was simple enough that a colleague was able to quickly fix…