Hacker News Reader

Google style interviews don't screen for the best engineers, but they screen strongly for subservience. The fact that a candidate has to go out of their way to prepare for these interviews indicates that the candidate is likely willing to jump through whatever hoops they're told to jump through.

It's similar to how investment banking jobs place such a high premium on Ivy league degrees with high GPAs despite the actual job itself being so simple a high school student could do it. Someone who's willing to jump through all those hoops to get into a top school and graduate with a high GPA has a strong track record of following orders and is less likely to complain about 100 hours workweeks.

>> Google style interviews don't screen for the best engineers, but they screen strongly for subservience. The fact that a candidate has to go out of their way to prepare for these interviews indicates that the candidate is likely willing to jump through whatever hoops they're told to jump through.

Try saying this obvious observation to some Google engineers in real life. I've never seen such butthurt adult-kids!

I mean, that's all true, but what matters is whether you have some personal goal which requires you to go through time at Google.

If this materially impacts the bottom lines of companies that are practicing this approach eventually companies that are not using this process will prevail.

There are other equilibria, likely because the employment market does not have the characteristics necessary for analogies of the the Efficient Market Hypothesis to apply. (most glaringly: people are not fungible commodities / the agents involved do not have rational expectations)

>> If this materially impacts the bottom lines of companies that are practicing this approach eventually companies that are not using this process will prevail.

It would, if companies realize that they can save millions by improving their interview processes and not have to aqui-hire so much.

But this insight requires smart people (who they eliminated with this interview process) to be already hired in those companies.

While I highly dislike this trend it's hard for me to call say Sundar Pichai not smart for example.

What do you think about Marissa Mayer? For every outlier winner person you point out, the industry is littered with losers. Perhaps stop correlating wrong things together?

There are several problems with your and the parent commenter's approach here:

1) You've not defined intelligence in an agreeable way, such that all parties are discussing the same thing (you seem to have interpreted his point about Sundar Pachai as successful due to being CEO of Google, but that may not be the case).

2) You've not defined intelligence in a rigorous way, such that all parties know it's meaningful even if they agree on it (is being CEO of a publicly traded company a robust proxy for intelligence? Can we positively correlate corporate success with intellectual formidability?)

3) You have not established any empirical way to assess intelligence in these people aside from what you'd consider tautological (CEOs are intelligent, Pachai is a CEO, Pachai is intelligent) and therefore self-evident. But you can't discriminate between the relative intelligences of members in this group, especially remotely on a forum, which makes this an issue even if 1) and 2) are solved.

I know, taking dialectics this seriously on an internet messageboard is a major pain in the ass. But this brings us full circle to software engineering interviews. One person mentioned a potential proxy for intelligence they consider self-evident, someone else argued against it without full and transparent clarification, and the cycle continues. This is how whiteboard interviews were born, this is how they became controversial, and this cycle continues even on discussions of whiteboard interviews.

People who want to filter for "intelligent" in their interviewing process can't define the term. People who come up with methodologies for assessing it, or identify proxies to it, can't prove they work. People who argue against these assessments or proxies can't prove they don't work because no one can even agree on what should be assessed. It's a Wittgensteinian clusterfuck all the way down, but the same human habits that gave rise to whiteboard interviews are perfectly manifested in the counterculture reaction to them and the resulting controversy.

I propose instead that you resist the temptation to use the word "smart", even in situations you'd consider the quality self-evident. "Intelligence" is like AI - once it's rigorously defined, no one agrees it's AI and it's so narrow in scope that no one cares about it because it's not weaselly and magical anymore (example - the IQ test). When you appease everyone's inclinations and talk about it without defining it, madness ensues.

Rigorously define a problem space, correctly map a set of empirically measurable capabilities to it, and hire people who demonstrate those capabilities. But don't use descriptions like "smart" which mean everything to everyone.

>> 1) You've not defined intelligence in an agreeable way, such that all parties are discussing the same thing (you seem to have interpreted his point about Sundar Pachai as successful due to being CEO of Google, but that may not be the case).

My last line was, "Perhaps stop correlating wrong things together?". My intention was to indicate that the person who wrote about Sundar Pichai is trying correlate something about the Google CEO to my original comment about aqui-hires.

It was not an exercise to define intelligence. I simply had to point out naivety of any correlations the parent commenter was trying to make.

>> 2) You've not defined intelligence in a rigorous way, such that all parties know it's meaningful even if they agree on it (is being CEO of a publicly traded company a robust proxy for intelligence? Can we positively correlate corporate success with intellectual formidability?)

Again, there was no exercise to define intelligence. You are misreading the context

>> 3) You have not established any empirical way to assess intelligence in these people aside from what you'd consider tautological (CEOs are intelligent, Pachai is a CEO, Pachai is intelligent) and therefore self-evident. But you can't discriminate between the relative intelligences of members in this group, especially remotely on a forum, which makes this an issue even if 1) and 2) are solved.

Same response as above.

>> People who want to filter for "intelligent" in their interviewing process can't define the term. People who come up with methodologies for assessing it, or identify proxies to it, can't prove they work. People who argue against these assessments or proxies can't prove they don't work because no one can even agree on what should be assessed. It's a Wittgensteinian clusterfuck all the way down, but the same human habits that gave rise to whiteboard interviews are perfectly manifested in the counterculture reaction to them and the resulting controversy.

Interesting you bring this up. Let us play a thought experiment. Who would you rather work with?

1. A person who wrote a VM for handling their cross-platform message queue but couldn't solve N-Queens problem

2. A person who can solve N-Queens problem on the whiteboard but doesn't have the engineering appetite/desire to learn something like VMs in detail

Now that you know who you want to work with (hoping you chose 1), let me ask you this. Why is data king? Have test scores ever been a representative of smartness? Is a person with 3.5 GPA worse than 3.75 GPA?

If your answer to above question is no. Then why is Google hiring committee rating people with their own notion of GPA and hiring people with a certain Google GPA?

Because, in that GPA competition, candidate 2 will win. But you didn't want to work with candidate 2 did you?

Well if you theory holds how did Rob Pike, Ken Thompson, Guido van Rossum, Dan Bornstein and on and on ended up at Google?

>> Well if you theory holds how did Rob Pike, Ken Thompson, Guido van Rossum, Dan Bornstein and on and on ended up at Google?

You realize they got hired because of their fame and expertise? They didn't have to go through intense whiteboarding. And even if they did, they would be hired even if they didn't solve a stupid N-Queens problem?

I realise they have 0 problems with CS fundamentals while being at the same time top experts in respective fields.

>> I realise they have 0 problems with CS fundamentals while being at the same time top experts in respective fields.

I suspect your definition of CS fundamentals is only Algos and Datastruct problems. Said experts are very good at what they do. That does not mean they will whip out an algorithmic puzzle solution on a whiteboard under pressure.

I also suspect that those experts have better things to do than get a job at Google. They'd rather not go through this process. Google wants them to be there not the other way around.

Companies that hire the best engineers already use better processes.

How can we check this to be true?

You probably have to become a real good engineer, or work among them, to see it.

How does this prove or disprove anything about the process they use?

So what approach do you suggest for the interview process? How has it been your experience hiring under this process?

Without spoilers, here's an outline of an interview problem I did last Friday:

1) Here is a very small VM (fewer registers and fewer instructions than you can count on your hands). Write an interpreter for it.

2) Add an I/O instruction.

3) Having your interpreter and your I/O instruction, you are given at least one example of a program with a specific property. Write a program analysis which will detect the property soundly and completely.

Managing to finish (3) relies on knowing about certain fundamental concepts from automaton theory and program analysis. The company does actually use this knowledge regularly, so it makes sense that they'll ask. However, even parts (1) and (2) actually manage to test basic programming in a reasonable way.

What do you work on? Can I interview with you?

I was the one interviewing for a job! If I get it, then maybe I can invite you. For now, precious is mine!

Haha! Good luck. Sounds like an awesome opportunity if they deal with VMs and registers!

Registers? You were lucky! Last time i did an interview problem with a weird machine, i didn't have any registers at all! And only three instructions, none of which were arithmetic!

By the end the interviewer was telling it was all right for me to have mistakenly thought the registers were 32-bit words, and thus concluded the machine wasn't quite Turing-complete, and he was noting that our analysis should still work for the Turing-complete version with bignum registers.

Step 1: Read the fucking resume

Step 2: Find somebody with relevant expertise to interview that candidate. Don't send the generic engineer who doesn't know anything beyond using hashmaps for all Java programs.

> Here's my gripe with this interview process. It encourages engineers to spend months and years into learning and remembering optimal solutions to textbook problems.

Wrong. Questions aren't designed to be memorized. It shouldn't take months, or years, to prepare for this stuff if you already have a CS background unless you're really slow.

Who do you want to work with? A person who can regurgitate CS trivia or a person who has interest and track record in solving interesting problems?

Like I said, it's not regurgitation. There's a reason companies try to keep their questions secret.

It's all a variation of the 500 questions listed. Nobody memorizes code line by line. But there are enough hires at Google and FB who memorized algorithms and solutions and got in.

Do you want to work with people who memorize solutions or do you want people who are innovative, genuine problem solvers who've solved interesting problems?

It's hard to imagine an innovative problem solver being unable to tackle Google's interview questions. You gave the example of optimizing an SQL query. That's a data structures problem itself.

Google apparently has an NDA for the interview questions they ask, so they're trying to avoid quizzing people on stuff that they've memorized. I know any place I worked at always tried to ask "fresh" questions to people. There's just no point if they already know the answer.

I had a phone interview with Google a few years ago. I was asked to implement a Soduko solver. I didn't manage it during the interview, but half an hour later a solution came to me when walking down the road. Should I have been a hire or a no hire?

I'm someone who cycles over my thoughts for long periods of time. Interviews really don't capture this at all, but it's one of my strongest intellectual assets.

What is your point? They've got limited time and don't want to waste candidates' time. There is some variance in the process, which they try to minimize by asking lots of questions.

Point is that it is a very poor way of assessing someone.

>> It's hard to imagine an innovative problem solver being unable to tackle Google's interview questions. You gave the example of optimizing an SQL query. That's a data structures problem itself.

Dude, is your definition of problem solving limited only to Algos and datastructs?

Because I can imagine sql optimization in the following ways: 1. Compiler modification to use different instructions 2. Hinting branch predictors 3. Modifying the database environment to use different operations under the hood 4. Use a different hardware 5. Use a different language 6. Allocate different memory configs 7. Use SSD

Do you even realize that CS is not algos and datastructs only?

The big optimization would be avoiding full table scans or full table joins. That would be at the query level.

>> The big optimization would be avoiding full table scans or full table joins. That would be at the query level.

An insight that can only come from experience and to someone who is actually interested in this.

I want to work with people like you, not with the person who can solve some stupid dynamic programming puzzle but can't do any real interesting stuff in the real world.

Well, I meant that the biggest optimization you can do is algorithmic in nature.

> Wrong. Questions aren't designed to be memorized.

Do you know that 'detect a cycle in a linked list' question? I can't imagine many people being able to answer that without having seen the question previously.

I figured that problem out on my own the first time I heard of it. It wasn't Floyd's algorithm, there are many solutions.

One data point, but I was asked that as a Microsoft interview question when I was a freshman. I figured it out on on the fly pretty quickly. I'm no genius.

Recent surprise: exponentiation by squaring. Not by name, but by being the correct answer to the question. (This is in the list of 500, by the way.)

It's trivial to explain:

    x^n = x(x^2)^((n-1)/2), if n is odd
        = (x^2)^(n/2)     , if n is even

Knowing that (or having figured that out yourself if an interview was your first exposure to this problem), it's even more trivial to implement, making it a math quiz far more than a programming exercise. (Though I later turned it into a programming exercise entirely to exploit an arbitrary eye bleedecution bug in the human brain: https://gist.github.com/LnxPrgr3/7154873d3eb8b1e5960851628c7...)

Maybe that's what they intended. It's certainly legit if the job will have you actually doing, rather than applying, math. Except that it concludes you can math if you're smart enough to pretend to derive the answer you memorized after encountering it before. You might accidentally hire a bunch of crypto nerds.

For what it's worth I learned that explicitly in a data structures & algorithms class. I've seen it come up in a bunch of other introductory material, so it seems like a relatively standard part of "the curriculum." I think somebody might have a chance of coming up with this shortcut on their own, if, for example, they wanted to compute the Nth Fibonacci number efficiently (using matrix exponentiation -- the bignum arithmetic makes it O(n^2) if you just do n multiplications) or if they wanted to compute a polynomial more efficiently by memoizing the values x^(2^n), or if you kidnapped them and threatened to kill their family if they couldn't figure out how to compute x^n using O(log_2(n)) multiplications...

The difficult thing about that shortcut isn't that you couldn't come up with it, it's that you wouldn't think to try coming up with it unless you are in a particularly painful situation.

I don't view this exponentiation speedup stuff as math-specific, it's something you can come across when efficiently updating string checksums under random access modifications and concatenations, or when solving some graph problem where you exponentiate an adjacency matrix.

I'm glad your algorithm class covered this. Mine did not. It surely covered some other obscure material that you don't know. You are missing the point. If we had a standard CS curriculum, you can fault people for missing out on stuff they should know. I think part of the problem is people is that CS is too big of a discipline at this point. A systems person couldn't pass a graphics person's interview, etc.

But I wouldn't require somebody to know of faster exponentiation in an interview. It's still too obscure.