Hacker News Reader

Comment by habosa | Hacker News Reader

I work at Google and no it's not easy for us either. I've heard many of my coworkers joke that if they went through the interview process again they'd probably fail.

That said I see two kinds of interviewers. One kind (the good kind) takes a medium difficulty question and uses it to explore the candidate's coding, algorithms, communication, and problem solving skills.

The other kind has a super hard question with a single algorithmic solution that tells you nothing about what kind of engineer the person would be. This kind of interviewer takes too much pleasure in being a gatekeeper to Google.

View on HN

> I've heard many of my coworkers joke that if they went through the interview process again they'd probably fail.

I’ve heard this joke at a lot of tech companies. Also, “the hardest thing I’ve ever done at my job was pass the interview.” Just shows how divorced from day-to-day work skills interviewing has become.

I think most tech companies severely overestimate the cost of false positives, particularly in the USA where it’s trivially easy to fire someone who turns out to be a dud.

Also think it represents an opportunity: if you could reliably figure out who made it to the interview stage at these top companies but did not get an offer, you could forego your recruiting expense, simply hire all those people and likely end up with a well above average team, minus the few false positives.

Tech interviews, coming from someone transitioning into the field, are blowing me away. One national retailer I spoke to does two phone screens, then an onsite round with nine coworkers. I've never seen anything like this in my previous field (mechanical engineering).

Its quite common in the tech area. Some teams in FANG companies(and wannabe FANG companies) are known to reject a candidate even if a single interviewer gives a bad feedback. Like say they did 9 rounds of interviews, and then they do a bar raiser round. They still reject you even if one single interviewer gave a bad feedback.

There is also a concept of 'machine coding round' in a few companies here in Bangalore. Where you are given like an hour to implement sort of like fairly medium application.

You could write a perfectly working application, but if the evaluator thinks its not simple or complicated for their taste, its still a straight reject.

Its almost like they want cookie cut candidates who practiced interviewing day in and out for years.

The real practical world experience is largely considered useless.

> I think most tech companies severely overestimate the cost of false positives, particularly in the USA where it’s trivially easy to fire someone who turns out to be a dud.

I don't think that's actually true. People who are net-negative on a team may be very personable and hence emotionally difficult to fire. And of course the U.S. does have a number of protected classes, who can be very difficult & expensive to fire for cause (because the assumption is that they were not fired for cause). I'm a member of a protected class, and I often worry that it actually makes it more difficult for me to get hired: will folks be willing to take a chance on me, knowing that were I a jerk I could make life difficult for them? I'm not a jerk (I think!), but they can hardly know that!

> People who are net-negative on a team may be very personable and hence emotionally difficult to fire.

Those people are rare and generally caught by much lighter screening.

> And of course the U.S. does have a number of protected classes, who can be very difficult & expensive to fire for cause (because the assumption is that they were not fired for cause).

I don't think you are using "for cause" in the proper legal sense. Firing "for cause" is indeed an time-consuming and potentially expensive process because of the effects on things like unemployment benefits. Firing "without cause" is not, and is permissible in almost every state.

What you are describing are potential accusations of illegal discrimination. This is largely orthogonal to cause.

>I'm a member of a protected class [...]

Technically speaking, we all are, no? We all have genders, sexual orientations, races, ethnicities? Of course you probably meant that you fall into a minority group in one of those classes, but pretty much anyone could allege they were discriminated against based on their protected characteristics, even if sometimes it's not a particularly believable claim.

I'd be curious what the pipeline of candidates looks like at these top places. You're probably correct that they are being overly critical and rejecting plausible candidates. They may be overestimating their needs, but they are also probably inundated with overconfident chumps.

I bet if you could select only the people who made it to the in-person interviews at these companies, which usually happens after multiple weed-out filters, you’d have a way-above-average cohort.

> I've heard many of my coworkers joke that if they went through the interview process again they'd probably fail.

I don't see how companies that claim it's hard to find talent can be OK with a system that would reject more than a small portion (<5%) of their current productive engineers.

Edit: fixed word sense ambiguity

I see it like getting into a top college. Would your average college student be able to get a 2300+ (1500+ ?) SAT score if they had to take it again? Probably not unless they re-studied and prepared for it - which I think is the same answer for FAANG engineers and whiteboarding questions.

Also, good SAT scores don't always translate into good college students and the same could be said for good whiteboarding skills don't translate into good software engineers or vice versa.

That's why standardized testing is becoming more irrelevant in college admissions.

Because they think false positives are really bad and you can always reapply.

> I don't see how companies that claim it's hard to find talent can be OK ...

I don't either, but it's an easy game to play: start a company with an impossibly difficult goal (e.g. build a more popular social network than Facebook in two years, colonize Neptune, cure cancer) and then complain that there isn't enough talent in the labor pool. Finally, blame the government.

I got the same response from an old friend who has worked for Google for the better part of a decade.

FWIW my understanding is that the Hiring Committee tends to discard feedback from interviewers like your latter type here.

I had such an a-hole interviewer the last (and hence final) interview I did at Google. His attitude was ... oh .. you have a PhD, let me show you how smart I am.

Just like getting into YC isn't necessary to be a successful founder, getting into Google isn't necessary to be a successful engineer. There are tons of companies out there, and many pay better than Google.

> many pay better than Google

Those would be? The only one I have actually seen (claimed) numbers out of that can beat Google is Facebook.

Give feedback to your recruiter. Interviewers can be forced into more training or taken off rotations.

The one that got to me admitted first thing that he already was told to knock it off, shrugged it off, and was still in the rotation anyway.

I didn't feel like giving that feedback to the recruiter would help if it was already known well in advance. That and a lot of other signals in two interview cycles seemed to indicate that the recruiter and/or Google were perfectly happy wasting my time, and I've not really felt like bothering to interview with Google since.

Is there any mechanism like those olympics diving competition? i.e. the highest and lowest score are discarded.

They don't do this as a matter of course, but they do look at the question that was asked various factors surrounding the interview. They certainly can and do throw out interviews that don't generate any signal.

I also work at Google and what mystifies me when I do interviews is just how consistently people manage to screw up even the medium difficulty questions. I used to love asking this question until it was banned:

https://programmingpraxis.com/2012/01/20/knights-on-a-keypad...

This is a great question because it has several levels of solutions:

1. A recursive solution that iterates over all sequences, exponential time and logarithmic in space. Interviewing for T3 (entry level, think college grad), getting only this far in 45 minutes earns a "leaning no hire" in my book.

2. The above solution except with memoization, which reduces the runtime to linear but requires linear space. This one earns a "leaning hire" from me.

3. A dynamic programming solution that takes linear time and constant space. This one gets a "hire" to a "strong hire," depending on the elegance of the implementation and the strength of the discussion we have around it.

4. A logarithmic time solution involving adjacency matrices, matrix multiplication, and binary decomposition of numbers. I've never seen anyone get this and I only learned about it after months of asking this question.

It's shocking how few candidates actually got as far as solution 1. I kinda want to open this up to the HN comments section, because this does not strike me as a brutally difficult problem, but the rate at which people fell on their faces when presented with this question suggests either something about our interview process or about the candidates we interview.

EDIT: A clarification about “getting as far as” a particular solution: I’m not sitting there stone faced taking notes, I provide hints and prods and suggestions to push candidates toward more optimal solutions. I want the candidate to get as far as possible because it feels good to watch someone succeed, but oftentimes they run out of steam or take forever to implement their solution. In particular with respect to solution 1, if that’s as far as a candidate can get despite my recommendations, that’s not a good sign for their algorithmic ability.

I mean I'm surprised you don't see why this question is plain stupid.

I've had to deal with an algorithm problem of this difficulty once in my entire work life and I was given a week time to go figure out the best way to go about this.

Your problem creates an unrealistic standard of a software developer. You don't get to see something like their coding quality which is a lot more important in a candidate than their ability to solve an arbitrary algorithms question. Especially since these algorithm quesstions are now being studied for the sake of interviews. Rather than to learn something.

It's shocking to me how many engineers I come across that think having an algorithms based interview actually gives them good results.

>>I mean I'm surprised you don't see why this question is plain stupid.

Its more psychological than technical.

Once a person knows how to do a thing, they start to think any one who doesn't, is stupid.

Their intelligence becomes the baseline to measure others intelligence.

I agree with this.

My question always is why do you think this is important for the position you're hiring. Does knowing this question mean they're actually good for your position?

This is turning into the situation I've seen in places with serious entrance exams for universities. For example in Iran, a lot of not so talented but have great memorization and afforded to do mindless practice exams are making it into higher education while creative and talented and less fortunate people are staying out.

There are entire businesses built around practicing algorithm questions now, this is not a good sign.

I wouldn't be able to answer this question in the time allotted and would heavily discount its signal if I were on the hiring committee with this question in the candidate's packet. It tests for algorithm memorization which is not a hiring signal.

What memorized algorithm does this test for? As far as I know there is no algorithm to do this, and this interview tests for algorithm design rather than memorization.

You said above that you have set LNH for a T3 writing out the obvious solution to your question. The problem is that optimizing that solution comes one of two ways:

1. having seen the specific class of problem before and knowing, as you're writing that solution, to stop and switch to the class of solution you've seen before that would solve the problem more efficiently, or

2. finishing the obvious, poorly performing solution and then optimizing it like an real engineer would do. The problem is that there's not going to be enough time for this to occur in the interview session. The act of writing out the poorly performing solution will consume the entire session.

Therefore, the only way someone would have passed your interview question would have been if they had seen this class of problem before.

This is a fair point, even tough it doesn’t answer my question. When I interview I split up the coding and the algorithms assessments: if someone quickly and correctly implements the naive solution, I consider myself justified in grading them as solid in coding and moving on and having an algorithmic design discussion for the rest of the interview so I can speak more to their algorithms abilities.

If someone fails to design anything more sophisticated than number 1 despite my guidance, or takes an unreasonable amount of time to implement it, that’s a signal.

Also, let’s keep in mind a hiring recommendation isn’t a judgment of a person’a abilities as an engineer, it’s a judgement of how badly we should be trying to hire them relative to other candidates. My LNH is a statement that the candidate is solid but not stellar enough to extend an offer to. If our hiring pool were restricted or we needed to hire more people my assessment would be accordingly softened.

I'm really glad someone is seeing this for what it is. Too often people claim that you should go for the naive solution first, and then iterate, when that really doesn't work in the dynamics of a normal interview.

> I kinda want to open this up to the HN comments section, because this does not strike me as a brutally difficult problem, but the rate at which people fell on their faces when presented with this question suggests either something about our interview process or about the candidates we interview.

Because whiteboard coding is stressful and hard. I still kick myself for almost failing to get a basic sorting question right back in 2009, because the interviewer disguised it as a question about horse racing and it was interview 8 at the end of the day. (I still ended up getting an offer, but I turned it down.)

> t's shocking how few candidates actually got as far as solution

How many people in the real world sit around and practice dynamic programming questions all day?? The answer is ZERO!

>>How many people in the real world sit around and practice dynamic programming questions all day??

You will surprised how many people as a matter of fact actually do this.

In fact for a lot of people the whole purpose of a day job is to pay them salaries so that practice interview questions to hop on the next jobs.

The bad news is many companies think these sort of puzzle solving skills are penultimate level of software engineering skills and pay top salaries, so these people don't even worry about being bad at their current jobs.

Do these for a few years, and pad big brands to your resume and then you are automatically considered something special and qualified for big title promotions.

Oh trust me I know. I was being a smart ass and pointing out that only people that don't live in reality do this stupid shit. Dynamic programming interview questions, in particular, are the epitome of the absurdity of technical interviews.

It is >0, and those people make more than me :(

>A logarithmic time solution involving adjacency matrices, matrix multiplication, and binary decomposition of numbers.

can you post a link to this solution? sounds cool.

edit: lol i just realized this is simply multiplying the adjacency matrix and what you mean by binary decomposition of numbers is just exponentiation by squaring. it's funny now that i realized i'll probably never figure out the dp solution.

edit2: got it. number of length n paths for some key u is sum of n-1 paths across "knight neighbors" of u. base case is length 1 path which is just # of neighbors.

it's funny this problem is designed in a particular way. using the keypad instead of a chessboard lets you write down the graph by hand rather than actually procedurally generating it (which is awkward with lots of literal edge conditions to check).

Yeah this is one of the "standard" uses for matrix multiplication. Another one is calculating the N-th fibonacci number in logarithmic time (or any linear recurrence).

How would you rate this solution? Assuming we have static keypad grid.

  long moves(int start = 1, int len) {
    assert(len > 0);
    long[] cur = new long[10];
    for (int i = 0; i < 10; i++) {
      cur[i] = 1;
    }
  
    long[] nxt = new long[10];
    while (len-- > 0) {
      nxt[0] = cur[4] + cur[6];
      nxt[1] = cur[8] + cur[6];
      nxt[2] = cur[7] + cur[9];
      nxt[3] = cur[4] + cur[8];
      nxt[4] = cur[3] + cur[9] + cur[0];
      nxt[5] = 0;
      nxt[6] = cur[1] + cur[7] + cur[0];
      nxt[7] = cur[2] + cur[6];
      nxt[8] = cur[1] + cur[3];
      nxt[9] = cur[4] + cur[2];

      for (int i = 0; i < 10; i++) {
        cur[i] = nxt[i];
      }
    }
  
    return cur[start];
  }

Very good! However there is an off-by-one error as the exercise asks for paths of lengths not number of nodes. If you came up with that in 45 minutes without googling, you are very strong indeed.

Fun exercise. This is how far I got after about 45 minutes: https://gist.github.com/bjourne/7e45d41e8e4f5518bb92f6df7978... I wasted half the time not getting that you don't need to store the paths only the counts! But this was in my quiet home and I would probably fluke out in an interview setting where you have to talk while you code.

I'm still going to consider myself a pretty good coder. Perhaps not Google material, but pretty damn good still. :)

English is a rich and fuzzy language. I have more trouble translating problems like this into human than I do solving them.

Sometimes interviewers will respond to questions about the question. Others will only repeat the question as-stated. With the latter, I'd be sunk.

Pólya's first principle.

It becomes brutally difficult in the context of a time-limited interview. You have the pressures of: 1) anxiety about limited time, 2) anxiety about hidden "tricks" or "cleverness", 3) inter-personal anxiety.

It's that last one that I think algorithms/white-board coding entirely fails to see the trees for the forest. You would think as an industry that seems to lean heavily towards introverts and people in various places on the autism and social disorder spectrums, that the industry would not rely so much on high-pressure inter-personal communication scenarios for interviewing.

Which is not to say that soft skills don't matter: they absolutely do, and most industries their job interviews are much more highly focused on soft skills. The point is that you are testing soft and hard skills together in a highly charged mix.

If I want to sit down and play with an algorithms problem, I'd probably like to do it in a quiet room with no one watching/looking over my shoulder, and if I'm writing anything for most of the thought time it's scribbles and doodles, not algorithm-appropriate diagrams. "Programmer's Tourette's" of a sort imply that I'd probably be swearing at it for a while as I work to make sense of it. Asking a complicated algorithms question in a whiteboard scenario requires me to "play-act" a more linear string of thoughts, which diagram nicely, than I would use in an actual puzzle situation, while trying to be personal/presentable/well-spoken. I can certainly do that, but that mix of social skills and problem solving skills is very rarely needed in real life where we mostly compartmentalize such things to meetings versus coding time.

Then add in the ticking clock anxiety, that I don't feel like I have time to breathe, much less patiently tease out a solution to the problem.

Then add in the exhaustions of jet lag and trying to do all of that for 8 hours.

I feel like a lot of these sorts of questions, I could solve the problem rather well on my own time, or I could be a great, sociable, and presentable candidate with smart thoughts but maybe not immediate solutions. You want to the test for the former, but present only situations where the latter works well.

I feel like I'm not far from a baseline human on inter-personal skills, and even am somewhat more extrovert than the average programmer, and knowing that I have problems doing "both" the soft and hard skills for an eight hour interview day, I sometimes can't imagine how anyone in this industry gets hired because it's almost like we've optimized interviews to be intentional hells for programmers by trying to test hard skills in high pressure soft skills environments.

I very much believe that the technical interview culture as it exists today meets the definition of hazing [1], and that one day the industry will look back on it and wonder what was it thinking.

[1] https://en.wikipedia.org/wiki/Hazing

>>Then add in the ticking clock anxiety, that I don't feel like I have time to breathe, much less patiently tease out a solution to the problem.

The worst part about this is if you get the first attempt wrong. Then you have very little time to start again and go to a working solution.

By then your anxiety begins to multiply.

I was asked this question at a company (unicorn, but lower bar than Google, got the offer) and I only described #1. Thanks for calling me stupid though!

That wasn’t my intention, and I updated my comment to clarify. Did your interviewer offer suggestions or just sit there?

It may not have been the intention but I'm honestly aghast at the utter elitism coming out of Google and Facebook. I get that you are "superior humans" that are plucked from top institutions making 25% more than me at Amazon, but you don't have to keep emphasizing it.

My interviewer offered suggestions. Finally I described memoizing it (can be done with 2 lines in Python with a dictionary) though he was more interested in how to do it without extra space by utilizing a BFS that uses the input list as a queue. Then he ran off for another meeting.

> I'm honestly aghast at the utter elitism coming out of Google and Facebook

I presume it's Google and Facebook's extremely high hiring bar that you're attributing to elitism? Let me attempt to reframe that for you in a way that I hope will let you let go of some of the anger I'm picking up on:

There's no denying that Google and Facebook target top-tier institutions and put their candidates through hell. However, I don't attribute this to elitism. I personally got my start at a less-than-stellar CS program, and I go out of my way to recruit there as an alum. I've detected no elitism from any recruiters, interviewers, or hiring managers, and I've seen a number of people hired as interns and full time engineers as a direct result of my outreach. If Google were as elitist an organization as you seem to think, I and the people I've helped get hired would never have had a chance.

So then what explains the high bar? Simple necessity. I can't share details, but the number of applications we receive for every opening is staggering. What's more, when we approach people in industry and academia, we see a high rate of interest. The blunt truth is that we are more selective about hiring because we can be. When a hundred people (not real figures) apply for each available posting and your hiring pipeline is staffed well enough to interview all of them, you'd better believe you're going to hire the best one in that pool. This isn't a Google thing, this isn't a Facebook thing, this is a rational actor thing.

So no, I don't think you're stupid for coming up with a suboptimal solution, I have no reason to think you're a bad engineer, and I wouldn't reject you because your background. However, given a pool of candidates of whom some got as far as solution 3 and some got as far as solution 1, I'm going to more enthusiastically recommend hiring the ones who got solution 3.

>I presume it's Google and Facebook's extremely high hiring bar that you're attributing to elitism?

Yes and no. It's that I'm inferior and stupid for being at a lower tier company than at Facebook or Google. I can see it in every condescending hiring post about how easy it is to pass interviews without seeing similar problems before, switch companies and save for retirement and how nice it is to work at a company that treats you like an ubermensch.

>I've detected no elitism from any recruiters, interviewers, or hiring managers, and I've seen a number of people hired as interns and full time engineers as a direct result of my outreach.

I have absolutely heard of individuals from top tier schools getting easy questions while I got tougher ones, cases where people from top programs and other top companies (like Facebook) getting the benefit of a doubt in borderline situations, etc.

In some ways its even worse than at Facebook, at least at Facebook there isn't a hiring committee after a team match like there is at Google now.

Working at FB, +1 to all of this.

Personally I find that I can get a lot more useful signal from simple practical problems (eg "take a .txt file as input, modify all the words which contain the letter 'q' to be uppercase, write the results to a new file") which have a lot of room for expansion (What if we instead want to capitalise each word where the word after it contains a 'q'? What if we only want to modify the third instance of each word? What if the .txt file is too large for RAM? What if a single 'word' is too large for ram and the letter q is right at the end of the word?) -- starting out with something that any programmer should be able to solve in one or two minutes, and then cranking up the difficulty; adding in bits where a strong algorithmic coder has an opportunity to come up with a more efficient solution, but it isn't just a binary "has the candidate memorised the appropriate algorithm yes/no?".

(Example question made up off the top of my head because NDA, I haven't actually given much throught as to if it's a good question or not, just giving an example of "question which starts simple and then you can add complexity on top")

What would the correct solution be for the questions involving an input too large for RAM? This is new to me.

"the correct solution" implies that there is one particular correct solution - there are a lot of options, and I'd accept any answer if the candidate can come up with a reasonable justification for it. One example would be to process the data in fixed-size chunks of eg 1KB instead of trying to process the entire file at once. Pros: no matter how weirdly malformed your data is, your memory use is constant. Cons: what if that 1KB boundary line cuts a word in half? - then the candidate can either handle that new edge case, or switch to a different approach that doesn't suffer from that problem. Again, either option is valid if they have a solid explanation for what they are doing and why they are doing it.

Reply on news.ycombinator.com