Google Interviewer: "so, how would you do X, Y, or Z?"
Ruby Developer: "errm.. gem install X, gem install Y or gem install Z?"
Google Interviewer: "next!"
Google: 90% of our engineers use the software you wrote (Homebrew), but...
101–110 of 683 posts
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#102Earlier quoted context omitted.
I found actually using a whiteboard, or pen & paper, is the best. No computers. Pen only. For me, rehearsing an answer works out. Then, I try to see how to deconstruct it and apply it to a similar problem I don't know. I can deliver an answer sounding confident and competent because I practiced an answer. It's a bit of a crap shoot. What irks me the most is that people are doing the interviews. They can be fooled and…
How is it the best way if you are not going to be writing code on a whiteboard on a daily basis on the job you are going to be interviewing for?
> How is it the best way if you are not going to be writing code on a whiteboard on a daily basis on the job you are going to be interviewing for?
It's not. I hate whiteboarding as much as you but I try not to think of it that way. This method is just a way to increase your chances of succeeding. I've not succeeded in every interview, for sure.
I do what I must to press on. :(
The best thing to do is not to take the rejection personally. I always ask, as nicely as possible, what areas I should focus on to improve for the future.
Sometimes I get no response but I often get replies, good replies.
We do what we must.
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#103Sorta ironic, but remember that the point of an interview is to determine how well you'd do in the environment that's hiring you , not how good a developer you are . Because Google tends to reinvent the wheel for basically everything, algorithmic knowledge really does matter. Package management only matters within a few very specific subteams. If you're interviewing for a general SWE position, you could be Mark Zucke…
That may well be, but if you're considering hiring a guy who's an expert at writing package management tools, don't you put him on one of the specific subteams that needs that skillset? Surely it's something Google deals with?
The problem is that Homebrew is very different from the sort of package management tasks that Google deals with. The design goals for Homebrew include: make it easy for users, make it not require root, make it work on Macs, handle dependencies robustly. If he were at Google it would be Linux-only, he'd be using Linux containerization extensively, he'd be deploying packages to thousands of machines instead of one, it'd be a virtual guarantee that some of the machines would fail during the installation process, there would be little or no user intervention and if there was a user it'd be a trained SRE, and the installation procedure would probably need to be an order of magnitude more efficient than Homebrew is.
I don't want to take away from his accomplishments as a programmer - I use Homebrew too. But my point is that it's very easy to see "Good programmer, of course he should get hired" from the outside, while the reality is that it may not be all that similar to the tasks he'd be doing.
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#104At a certain point, your resume should speak for itself. The fact that experienced engineers with impressive resumes are put through these types of interviews is insulting and frustrating to the interviewees. Succeeding at these whiteboard questions requires weeks of preparation. You need to practice, practice, practice. After enough practice, you are pretty likely to pass. So ultimately, it is more of a test of "how…
I don't necessarily agree though, I think if you can reason about a problem, you are infinitely more valuable than someone who memorizes problems and just applies them blindly.
Correct me if I'm wrong, but a binary search tree is a very simple data structure. It has rules, and just by it's definition, and the definition of "inverted", you should be able to come up with an iterative solution, even if it's just walking the tree and re-creating it.
It may not be the best, but it's a solution, it's a starting point.
But if you're interviewing for a job solving problems, shouldn't you be able to solve problems? Even if they aren't the best solution? Genuinely asking here, as this approach seems to have a 85-90% success rate for me.
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#105At a certain point, your resume should speak for itself. The fact that experienced engineers with impressive resumes are put through these types of interviews is insulting and frustrating to the interviewees. Succeeding at these whiteboard questions requires weeks of preparation. You need to practice, practice, practice. After enough practice, you are pretty likely to pass. So ultimately, it is more of a test of "how…
It's also stressful. To be fair the tree problem he got was easy, but brain freeze can kill you. I flubbed a trivial problem at a FB interview that still haunts me today.
Bingo, unfortunately, this does happen. Happened to me at Google interview with one of the rather trivial question.
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#106Humorous answer: Maybe I can't invert a tree, but watch me flip this table. Serious answer: Companies that pull this crap deserve to starve and die.
What specifically are you objecting to? That specific question? Writing code on a whiteboard? How would you interview software engineering candidates?
Demonstrating one small part of a real working software engineer's job, by solving an artificial problem in an artificial environment under artificial time constraints, while one or more people with no pedagogical training look on and (sometimes) interfere. The amount of information gained is less than the amount lost from having poisoned the entire rest of the interview environment.
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#107What does it mean to invert a binary tree? I'm not familiar with this operation on binary trees. Does it mean to swap parents with child nodes? Or to swap siblings?
I wondered this as well! As far as I can tell - I asked google and looked at what it came up with :) - it means swapping children.
I don't even understand why you would ever want to do this. You could just invert the input or output at the beginning or end (depending on what the binary tree is used for) for super cheap. It's not uprising that no one has done this in practice, though it also seems trivial (visit each node once).
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#108WTF is "inverting a binary tree?". The smattering of search engine results points to some seemingly operation that basically generates garbage by destructively manipulating the tree into a DAG in which the leaves of the original tree are roots, which point downward the parents. The original root node is returned, and still points to its children. Unless you return some aggregate (e.g. list) of all the roots which are not direct children of the original root, or it is understood that something elsewhere holds reference to them, they are leaked.
Be that as it may, if the interviewers hand you a reasonably detailed specification of what "invert a binary tree" means and you can't whiteboard it, I don't see how you can expect the job.
If you're expected to know what it means, and get no hint, then that is just stupid. "Whiteboard up an implementation for something we refuse to specify, beyond citing its name."
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#109To all of those saying ranting on twitter is the wrong move I couldn't disagree more. Twitter is often the ONLY tool that the average person can use to communicate and/or call out large companies on their actions. This is BS and should be made known. Homebrew is an amazing tool and I'd be falling over myself getting the offer papers in this guy's hands if he came to me looking for a job. The fact that google turned h…
maybe Homebrew is amazing, but Google can hire the best people in the world. that day they might've interviewed 10 people better than him who just didn't make a popular tool
"that day they might've interviewed 10 people better than him who just didn't make a popular tool"
Are you judging this on their ability to invert a binary tree? People here are ranting about having a problem with interview practices not representing whether or not you are good at your job. That's presumably (IMO) why the tweet was posted.
Re: Google: 90% of our engineers use the software you wrote (Homebrew), but...
#110At a certain point, your resume should speak for itself. The fact that experienced engineers with impressive resumes are put through these types of interviews is insulting and frustrating to the interviewees. Succeeding at these whiteboard questions requires weeks of preparation. You need to practice, practice, practice. After enough practice, you are pretty likely to pass. So ultimately, it is more of a test of "how…
It's also stressful. To be fair the tree problem he got was easy, but brain freeze can kill you. I flubbed a trivial problem at a FB interview that still haunts me today.
Often it's completely free-form too. So you have to pick the language, the data model, the data structures, the traversal mechanism (recursive vs. iterative), state to track (allow duplicates? prevent infinite loops?) and how to test the example all at once before even getting _started_ with their problem description.
Many of the interviews could actually work if they broke the process down into 8 questions instead of one (how would you represent a tree? a binary tree? how would you find node X? how would you move node X to the other side of the tree?). But, the ability to accommodate understanding takes empathy and human connection, not being a jerk programmer on interview duty who is browsing HN while listing to the interviewee mumble on your speakerphone.
Never underestimate the lack of ability in the interviewer and not the interviewee. Except, the company always believes itself to be more competent than outsiders, so you're ultimately left with being condescended to unnecessarily.