591–600 of 683 posts
Interviewing is stressful and all, but if the guy's reaction to not getting hired is to flame on twitter, not hiring might've been the right call.
Earlier quoted context omitted.
> At 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. Only to bad interviewees. You'd be shocked to hear the number of impressive résumés I have seen who turned out to be absolute no-hires after 20mn on a white board. By "absolute no hire", I mean the kind where…
> You'd be shocked to hear the number of impressive résumés I have seen who turned out to be absolute no-hires after 20mn on a white board. Hmm, at least in my experience it's really quick and easy to tell if someone is bullshitting about their resume or not by simply talking about the different projects they worked on. I know a few developers who didn't go to a 4 year school so they don't know all of the correct ter…
Earlier quoted context omitted.
> [Ex-Googler here] Truth be told this is a trivial question to be asked during an algo interview and as an interviewer I'd consider this a warm-up. Otherwise it's a rather poor question since either you know how to do it (ie, you have an idea about recursion) or you don't - there aren't too many shades of grey or possible follow-up questions that I can ask to probe the depth of your knowledge. It is a terrible quest…
If they said "swap left & right at each node" it would have been easy. But they used a term that doesn't even yield an example in google searches - what kind of "inversion" do they have in mind? It's as if everyone is on the same page but me.
At 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…
At what point during one's career should one simply be hired at face value and be exempt from interviewing? After 10 years? 20? 30? "I see your resume says you've been writing software for 30 years, and wrote this really well known tool. Wellllll....That's good enough for me. You're hired!"
Earlier quoted context omitted.
> You think like a Google interviewer. The OP is the type of person that, six months from now would be demanding special treatment because "he wrote Homebrew". Writing a package manager (been done before, a lot of times) is far different from writing machine learning algorithms (new field, blazing the trail for the industry). One requires an engineer, one requires a scientist. The OP flamed out because Google was loo…
>Writing a package manager (been done before, a lot of times) is far different from writing machine learning algorithms (new field, blazing the trail for the industry). One requires an engineer, one requires a scientist. I mean, a package manager is probably far more rooted in computer science than machine learning (which is basically just applied statistics: software engineering edition).
Earlier quoted context omitted.
Which is fine and dandy until you get that one person that cheats by getting help from someone else.
As if people who interview for Google don't just look up the most common interview questions and memorize answers before the interview...
I usually ask questions until the person is out of his comfort zone, and if he is completely clueless on how to proceed at that point it's a red flag.
Alumni's response that it is exceptionally tough. He shared an anecdote about one of his best hires.
The alumni wanted to test the interviewee's knowledge in different areas. He asked a question on diodes - it might not have been diodes, but for the sake of the story let's stick to diodes. The interviewee replied: "Hold on, I am not one to know about it."
I have not worked at Google and I do not think I'd pass its interview process. It is unlikely that I be diligent enough to make Homebrew. Nevertheless, I am inclined to the idea, that being knowledgeable in all tested areas would not reveal the personal fit necessary to make a great team.
At 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…
Another way of looking at it is that they do these kinds of interviews particularly because they do want to hire fresh grads (and ideally, the best 5% of those) over experienced programmers. And if that's the case, then it's not really flawed, it's doing what it's supposed to do.
For the top elite of experienced engineers that may not be the case, as they will come with some overall good analytical skills that Google wants. But for most in our industry, what we have learned over the years is how to be good in various sets of tech around our platforms of choice... and that is mostly irrelevant to Google, as they have their own platforms.
WTF 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…
Note that in the original tree each node needs storage for two pointers. After inversion only one is needed. You can use that now unused storage to link together the multiple roots to solve the leak problem.
But note that only consumes the second pointer storage in the roots. Interior nodes end up with some free storage after inversion.
Since inversion is reversible, the binary tree and its inverse contain the same information. Does this mean we should only need one pointer's worth of storage in the binary tree nodes?
Is there something for binary trees similar to Knuth's xor trick for doubly linked lists?
To 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…
We don't have all the details. You might not hire the best computer programmer in the world if he was also a psychopath. Heck, you might skip on him even if he wasn't a good culture fit. I'm not saying this person is / was any of those things, but there's more to hiring than just talent.