72 ms·

I had a similarly bad Google experience that I've talked about before[0] but will copy here: I was asked to do a task that eventually boiled down to a topologi

I had a similarly bad Google experience that I've talked about before[0] but will copy here: I was asked to do a task that eventually boiled down to a topological sort, and I thought the question consisted of recognizing that the answer was a topological sort and moving on because it was over the phone. However, that was not the case. The interviewer wanted me to code it all out over Google Docs, but I didn't remember the exact algorithm so I basically had to re-figure it out on the fly, which took most of the interview (I even similarly mention "in any real situation I would just look this up", but that didn't help). At the end, I had a bunch of pseudo-C++-code that should do it correctly. I thought I was done, then the interviewer said she would go go copy my code and compile it after the interview to see if I was right, which blew my mind. It was never mentioned previously that the code would actually be compiled and run, and with no syntax highlighting or ability to compile and test the code myself there is zero chance it was ever going to work. I never heard back, so I'm assuming my code failed and they left it at that. Anyway, I'm much happier now that I think I would have been at Google. [0] https://news.ycombinator.com/item?id=23848556 https://news.ycombinator.com/item?id=23848556

MattGaiser 5y ago
A friend encountered this with Amazon, although their tool at least has some code help (at least when I tried a year ago). The interviewer tried to compile his code.
bb88 5y ago
Back when I wanted to interview at google, I sensed some frustration between HR and the engineering. Some engineers just didn't make good interviewers. HR wished I had gotten a different interviewer.
- vidarh 5y ago
  I had a recruiter obtain approval to have my technical review ignored because I pointed out so many flaws in it. At that point I had too much of a distaste for the process to continue. But I kept being approached by Google recruiters, kept recounting what had happened last time and asked if I could expect better this time. None could promise things had improved, and a few did express that kind of frustration. This was years ago now. Could have changed of course. But I started telling them to go away.
  - bb88 5y ago
    I was getting HR hits like every six months and eventually I told them I would get back in touch when I was ready. Now I'm getting an email every month from FB, and about ready to do the same with them. The last time I passed the first and second rounds and Google let me languish on the third round for a month. I still probably would not have made it through, but it was surprising that my candidacy was dropped like that.
    - vidarh 5y ago
      It says something about their HR systems that it's clear they don't review past interactions before doing this. To me that's a warning sign too - I'm less likely to consider interviewing if a company contacts me again and the interaction doesn't start with a pitch of how this time or this position is a better fit...
- papito 5y ago
  The problem is that many out there try to copy the dysfunctional FAANG interview style. Google was asking those dumb brain-teaser questions for years, which were obviously useless to the naked eye, and then they realized themselves that those were counter-productive. Yet, you could expect one of those in almost any interview process. Seemingly smart people are ready to jump on bandwagons, too.
  - dagw 5y ago
    Google was asking those dumb brain-teaser questions for years Microsoft started doing this, realized it was a bad idea, and stopped before Google even really started this practice. So Google is as guilty of bandwagon jumping as everybody else here.
XorNot 5y ago
At this point I'm pretty sure FAANG hiring is just a random walk. Every now again someone happens to have looked at all the questions they ask recently for that particular interview cycle (or avoid the trap ones like that) and that person gets hired (and then put on the ad targeting team or whatever).
- bb88 5y ago
  What's funny is that I specifically remember a conference where some library that a google employee wrote was terrible. The one google developer talking about it, disavowed any responsibility of it. Whatever metrics that google is using in their interviews have probably become worthless in the past decade as people game the system.
  - pjmlp 5y ago
    Just check the Android code, specially the early versions looked like "C dev (not even C++) tries to create a Java based framework". And the NDK clearly is anything but modern C or C++.
    - ChrisMarshallNY 5y ago
      Google is famous for having a C++ implementation that eschews a lot of what makes C++ powerful. I’ve heard it referred to as “C+-“.
      - pjmlp 5y ago
        Yes and apparently clang is now suffering from Google not caring about latest C++ compliance. Apple mostly cares about LLVM based tooling in the context of Objective-C and Swift, Metal is C++14 dialect, and IO/Driver Kit require only a subset similar in goals to Embedded C++, so that leaves the remaing of the clang community to actually provide the efforts for ISO C++20 compliancy. https://en.cppreference.com/w/cpp/compiler_support/20 https://en.cppreference.com/w/cpp/compiler_support/20
trinovantes 5y ago
I once had an in-person interview where they gave me a sheet of printed code and asked me to point out the syntax errors. Some interviewers are absolutely insane.
- hdjjhhvvhga 5y ago
  Actually this one might make sense, depending on the code and the position you applied for.
  - trinovantes 5y ago
    It was for a junior c# position so I doubt it's applicable considering Visual Studio will point out the problems. But I'm curious what position would this question make sense?
    - burntoutfire 5y ago
      It doesn't sound that stupid, it checks whether you know the syntax of the language you'll be programming in.
      - exdsq 5y ago
        Depends... imagine getting four pages of C# code and having to play Where's Wally but you're not even sure what Wally looks like. Surely it'd be better to just write FizzBuzz.
      - mns 5y ago
        It's literally asking someone to write perfect code in a time limited situation, under pressure, how can someone with any kind of coding experience ask someone else to do in an interview?
        killtimeatwork 5y ago
        It not literally asking to write any code, just to read it.
biztos 5y ago
I find it… troubling? That a technical interviewer can’t tell for herself whether your code will work. Wouldn’t you ideally want people who actually understand code to be giving the coding questions?
- ellenhp 5y ago
  Are you saying that because this interviewer needs to run code to find logic errors, she's somehow not a competent engineer? Because I usually need to run code to find logic errors. Sometimes I use formal verification instead but that's pretty rare. Am I also not a competent engineer?
  - gspr 5y ago
    Does this reasoning not also apply to the applicant, though?
    - mlyle 5y ago
      So, we can have an interviewer perform a possibly incorrect manual validation of an interviewee's possibly faulty code. Reading code is harder than writing it, and presumably the applicant has been asked to do something tricky. Or they can run it, asking the real arbiter of truth whether it works or not. Of course, "whether it works" is merely one (very important) metric of quality.
      - ellenhp 5y ago
        Yeah. If I were asking a trickier question and I got an interesting new variant of the solutions I'm aware of, I'd absolutely run it if I had time to type it up and everything. Most solutions are either something I've seen before verbatim or obviously wrong, though.
      - tsukikage 5y ago
        The interview is a proxy for working with the person. In this case, it's a proxy for pair programming / code review. A good chunk of what the interviewer, ideally, looks for when asking a coding question is communication from the interviewee - can the interviewee communicate what they are doing and why? Can they explain the intent of the thing they've just written? Do they have a clear picture of it in their head, and can they communicate it? When the interviewer spots problems with it, what does the ensuing discussion look like? - how well does the interviewee collaborate in solving them? If the interviewer is wrong, does the interviewee push back? How? Can they understand you, and can they make themselves understood? Can you work with this person? Can you collaborate to write code, or will it be a daily struggle? Whether the code actually builds and runs after the hour is up does not help answer these questions; it is arguably the least interesting part of the whole process. The time limit is artificial; if all the other things align but you didn't happen to get it working in one hour, you'll likely have got it in two. If they don't align, you'd likely never have got it.
gspr 5y ago
It's also incredibly telling that the interviewer couldn't figure out whether your code was correct or not without compiling and running it.
TGImemegen 5y ago
Googler here. At some stage of the interview process, we have to check whether you're able to code, there's no way around it if you're applying for a coding position. So yes, we'll have you code the solution to a problem. Of course in the real world we'd use a library or look up the algorithm on stack overflow like everyone else. Good for you if you came up with a workable algorithm for the problem quickly. But that's not the only point of the interview. An important goal there is to check if you can really code. We don't usually care if you don't know find the perfect algorithm (unless it's for a senior position), and in fact it's a desirable property if you don't, because that allows us to see your thinking process. Some of the best interviewees I've had, they didn't have the right solution, but impressed me with how they thought about the problem and dealt with the situation of having a problem in front of them that they didn't know how to solve. How they considered possible boundary conditions and restrictions and extensions. Someone saying "yeah, this is just depth-first-search" and then spits up a memorized solution gives me zero insights on whether the candidate is good (and will likely not allow me to write great feedback on the candidate, unless they're able to sell me that they understand what they are doing and why and how). It's usually expected that most of the interview will be taken up by you implementing some algorithm, and it's expected that you won't get every detail right. We do NOT require you to produce token-by-token perfect code, and nowhere in the process will I ever have to give feedback on whether the code produced was actually valid. So maybe you misunderstood your interviewer's intention, or something else went wrong, or maybe they were just joking. But it's not the interviewers task to copy code into GCC and try it out, that'd be a huge waste of time. So let me be very clear and explicit: no-one gets classified as "no hire" because they've forgotten a semicolon somewhere. You messed up somewhere else. With that said, if a candidate says they can write in a language, we expect them to know the language, its idioms and at least parts of the standard library. Not every nook and cranny (e.g. I'd often instruct candidates "just pretend you have some library that implements a heap, and invent an API for it, I don't care about that part"), but if you call "strlen" in the termination-condition of your for-loop instead of before, or do other stuff that shows you don't know the language well, that's a red flag. After all, we expect you to be able to write production-level code that servers billions of users.
- hownottowrite 5y ago
bborud 5y ago
I worked at Google and did a fair share of interviews. Two observations: When you have 3 interviews per week for a prolonged period, you, as an interviewer, are not going to do a stellar job every time. What's worse: you will develop a routine and it becomes very easy to give candidates that do not fit your routine a lower grade. It takes effort on the interviewers part to recognize talent that perhaps doesn't fit your routine or your expectations. If you are not going to end up being a bad interviewer you also have to try to relate what you see in interviews to what you know about work. For instance I _never_ asked people to code live (mostly on whiteboards back then) because it just isn't a relevant exercise. And I was kind of horrified at experienced interviewers who asked people to code and then got obsessive about small details that the tooling would have taken care of. Absolutely pointless. The only piece of advice I found useful from the interview training was this: this is the candidate's big day. For you it is a chore, for them it is their big chance. Keep that in mind and respect it. I kept telling myself this for every interview - and some days I felt really terrible because I wasn't properly prepared. The other thing that horrified me was when we let inexperienced people who had been out of school for less than a year interview people. These interviewers barely knew how to write software themselves, and they'd get even more hung up on irrelevant stuff because they simply had no idea how to be software engineers. I doubt that I would have done very well in those kinds of interviews because this isn't how I work and it certainly isn't how I teach people to do problem solving. Problem solving requires more time because any even mildly tricky problem worth solving tends to have a lot of facets far beyond picking an algorithm or knowing how to code it up. That's the easy part because for that part, you have books, papers, tools and other people to seek advice from. Junior programmers right out of school with no engineering experience have no business interviewing developers. They make poor and overly judgemental interviewers and only rarely are able to spot talent if it doesn't fit their template. They also aren't going to fight for candidates that may not fit the imaginary template, but have some special gift because they are junior programmers. It takes a certain amount of balls to say "I know you think this candidate is rubbish, but I see something here and I don't care what you say, I am going to insist". (btw, statistically, this used to be a good predictor for later success: candidates that were somehow "controversial" in that they didn't make the grade with some interviewers, but displayed something that made other interviewers fight for them)
ballenf 5y ago
My lesson learned was "don't listen to what they say, watch what they do". As in, don't trust them to tell you what they're looking for, understand that figuring out what they're actually testing is also part of the screening process. I don't see a lot of focus on the hide-the-ball aspect of interviews, but is something I've experienced a few times and bothers me way more than anything else. The clearest time this happened I was told the company was big on pair programming, so I'd be doing a pair programming session. It turns out they meant I'd be tested on whether I could finish a coding exercise in the allotted time with someone watching. There was zero "pair programming" of any kind involved and time spent on collaboration counted against me.
markus_zhang 5y ago
Sometimes I sarcastically think they already have a friend who applies and needs to fail the others.
- nowherebeen 5y ago
  That does happen more often than you think. The hiring manager wants to hire a friend, tells HR he needs to hire a good programmer in mind (but doesn’t disclose it’s his friend). HR tend posts job postings for legal reasons knowing full well none of the candidates will be hire. They then reject a few candidates and then brings the friend saying they couldn’t find someone more qualified.
sltkr 5y ago
Let me first concede a few points: 1. You should have been better informed about the expectations of the interview, so you would have had a chance to prepare yourself. 2. Coding in a Google Doc is a terrible experience. It's a step up from coding on a whiteboard, but that's not saying much. Google has since moved away from both, prefering an online text editor that's not quite an IDE but at least more programmer-friendly. 3. The goal shouldn't be to write 100% correct code without any compiler feedback. That's insane. Still, there is a big difference between "candidate forgot a semicolon once" and "candidate did not know how to write a for-loop without IDE feedback". But beyond those valid complaints, it sounds like you were also unhappy that you were asked to write any code at all. I don't think that's reasonable. The point of a phone interview for an entry-level SWE is to determine two things: 1. Can they figure out how to solve a nontrivial problem? 2. Are they able to translate ideas into reasonable, working code? For an algorithm question that boils down to a topological sort, the interviewer will see three kinds of candidates: 1. Those that don't have a clue how to solve it. 2. Those that recognize it boils down to a topological sort. 3. Those that recognize it boils down to a topological sort and are able to implement a solution. Each of these candidates is strictly better than the last, and Google only wants to hire the third one. > I didn't remember the exact algorithm so I basically had to re-figure it out on the fly Yes! That was the whole point of the question! You had already demonstrated that you were at least a "type 2" candidate, so now the interviewer was trying to move beyond that and figure out if you were actually a "type 3" candidate. Nobody expected you to have the exact solution memorized, but they expected you to be able to figure it out from first principles. > I even similarly mention "in any real situation I would just look this up", but that didn't help That was missing the point, which was to test your ability to actually implement a solution. In the real world, if you encounter a standard problem (which happens often, like "I need this list sorted" or "I want to put this stuff in a hash table for O(1) access") you wouldn't even look up how to solve it. You would just call the existing standard library function and move on. Logically, the problems that you end up spending most of your time on are not of the standard variety, and involve actually thinking about how to break down the problem and actually implementing your intended solution. Those are the problems Google needs you to solve on the job. If you can't even implement a topological sort from scratch, why should anyone expect you to do anything more complicated than that?
throwawayboise 5y ago
I've never written a sort from scratch since my college days, over 30 years ago. Also never had a job interview that asked me do to so, or any other coding questions. I'm planning more for retirement than a next job at this point, but I shake my head at what my younger colleagues need to go through these days for the opportunity to write JavaScript with IDEs that do most of the work for you.
- simias 5y ago
  I sometimes have to implement a sorting algorithm when I write bare metal code that doesn't have any sort of standard library available. Of course, being a 1337 hacker, I then resort to the state of the art bubble sort. Or maybe an insertion sort if I'm feeling fancy. But enough bragging.
  - jt2190 5y ago
    OT: I wish I could relocate a blog post (on Microsoft’s site, I think) about a very a naive and “obviously wrong” sorting algorithm that a dev identified in their (Excel?) codebase. Turns out the code was naive because the vast majority of their users were sorting very small sets of data and the implementation actually performed much better in those circumstances.
    - jhck 5y ago
      Maybe it's this one? https://ericlippert.com/2020/03/27/new-grad-vs-senior-dev/ https://ericlippert.com/2020/03/27/new-grad-vs-senior-dev/
  - bear8642 5y ago
    > I then resort to the state of the art bubble sort Remember reading Bentley's Programming Pearls and fairly sure that's what he starts Sorting section with a short implementation of
  - JTbane 5y ago
    Funnily enough, if you're sorting small amounts of stuff it does not matter what algorithm you use. If fact your O(n log n) sorts are probably a lot slower on less than some millions of elements.
lawn 5y ago
I had a similar experience interviewing years ago for Google, although I can't remember the algorithm they wanted me to implement.
dekhn 5y ago
i failed quicksort the first time I interviewed at google. then got hired and worked there for 12 years and never wrote a sort. I also complained that google's coding solution (docs, basically) was a terrible way to code, other companies use coderpad or whatever, but I expect that Google will never change this. They love to hire people who are excellent at coding CS approximate solutions, but have little to no judgement on how to do good software engineering.
- telotortium 5y ago
  The pandemic has finally. forced them to move to something more Coderpad-like
endtime 5y ago
Standard disclaimer: everything below is my own opinion based on my personal experience, and I'm not speaking on behalf of my employer. > I thought I was done, then the interviewer said she would go go copy my code and compile it after the interview to see if I was right, which blew my mind. I've been interviewing at Google for nine years and have never done this. I generally don't think it's fair to ding a candidate for something I don't notice in an interview, where I'm at a huge advantage. If it looks right to me then that's good enough. But that said, I have often asked questions similar to what you describe. You have to write code in the shared doc because hiring committees want to see it - fair to blame the process for that, but not the interviewer. I actually appreciate this for a couple reasons: * It levels the playing field a bit, in the sense that code is more objective than an interviewer's notes on how a conversation went (especially for people who aren't native English speakers) * I sometimes find that candidates who communicate well struggle to turn their ideas info code. Other times, someone's communication and solution are kind of average, but then they use all the little things I like seeing (defaultdict(set), zip, etc. in Python). Lots of people claim to be very experienced programmers; seeing how comfortable and fluent someone is when actually writing code is a strong signal. If you don't like the focus on data structures and algorithms that you haven't thought about since college, you should probably appreciate the coding part.
- mox1 5y ago
  How would you feel if you were going to a job as a writer, and the interviewee asked you to put a story, poem, etc. down on a napkin, with a crayon? Like thats how I would feel writing code into freakin google docs during a job interview...with Google. Tie 1 arm behind by back as the synax goes wonky, I'm fighting the spacing, etc. etc. Or put mario Andretti into a ford focus, then test his lap times, with 0 warning. Yuck.
  - verticalflight 5y ago
    Just fyi - Mario Andretti and other similar drivers could be placed into any car and would perform at a very high level after a lap or so...
  - 5y ago
yawnxyz 5y ago
we must have had the same interviewer! It boggles my mind how this helps their business case / bottom line. And I was applying as a UX designer lol.
deleted 5y ago
[deleted]
FalconSensei 5y ago
I hate this. People have IDEs and internet when working. Having to write something that can be compiled in a doc is just stupid. As someone mentioned in another comment, I also never had to actually implement a sort since I left university more than a decade ago. I'm happy to discuss the different types and approaches to how they could be done - as to evaluate problem solving, logic, and general understanding - but to actually code in an interview... In a similar way, this week I even jokes on Twitter how I'm doing many improvements and refactors on a codebase, but there's the occasional 'how I do join 2 lists on Java again?' moment when I completely forget something basic.

MattGaiser 5y ago

A friend encountered this with Amazon, although their tool at least has some code help (at least when I tried a year ago). The interviewer tried to compile his code.

bb88 5y ago

Back when I wanted to interview at google, I sensed some frustration between HR and the engineering. Some engineers just didn't make good interviewers. HR wished I had gotten a different interviewer.

vidarh 5y ago
I had a recruiter obtain approval to have my technical review ignored because I pointed out so many flaws in it. At that point I had too much of a distaste for the process to continue. But I kept being approached by Google recruiters, kept recounting what had happened last time and asked if I could expect better this time. None could promise things had improved, and a few did express that kind of frustration. This was years ago now. Could have changed of course. But I started telling them to go away.
- bb88 5y ago
  I was getting HR hits like every six months and eventually I told them I would get back in touch when I was ready. Now I'm getting an email every month from FB, and about ready to do the same with them. The last time I passed the first and second rounds and Google let me languish on the third round for a month. I still probably would not have made it through, but it was surprising that my candidacy was dropped like that.
  - vidarh 5y ago
    It says something about their HR systems that it's clear they don't review past interactions before doing this. To me that's a warning sign too - I'm less likely to consider interviewing if a company contacts me again and the interaction doesn't start with a pitch of how this time or this position is a better fit...
papito 5y ago
The problem is that many out there try to copy the dysfunctional FAANG interview style. Google was asking those dumb brain-teaser questions for years, which were obviously useless to the naked eye, and then they realized themselves that those were counter-productive. Yet, you could expect one of those in almost any interview process. Seemingly smart people are ready to jump on bandwagons, too.
- dagw 5y ago
  Google was asking those dumb brain-teaser questions for years Microsoft started doing this, realized it was a bad idea, and stopped before Google even really started this practice. So Google is as guilty of bandwagon jumping as everybody else here.

XorNot 5y ago

At this point I'm pretty sure FAANG hiring is just a random walk. Every now again someone happens to have looked at all the questions they ask recently for that particular interview cycle (or avoid the trap ones like that) and that person gets hired (and then put on the ad targeting team or whatever).

bb88 5y ago
What's funny is that I specifically remember a conference where some library that a google employee wrote was terrible. The one google developer talking about it, disavowed any responsibility of it. Whatever metrics that google is using in their interviews have probably become worthless in the past decade as people game the system.
- pjmlp 5y ago
  Just check the Android code, specially the early versions looked like "C dev (not even C++) tries to create a Java based framework". And the NDK clearly is anything but modern C or C++.
  - ChrisMarshallNY 5y ago
    Google is famous for having a C++ implementation that eschews a lot of what makes C++ powerful. I’ve heard it referred to as “C+-“.
    - pjmlp 5y ago
      Yes and apparently clang is now suffering from Google not caring about latest C++ compliance. Apple mostly cares about LLVM based tooling in the context of Objective-C and Swift, Metal is C++14 dialect, and IO/Driver Kit require only a subset similar in goals to Embedded C++, so that leaves the remaing of the clang community to actually provide the efforts for ISO C++20 compliancy. https://en.cppreference.com/w/cpp/compiler_support/20 https://en.cppreference.com/w/cpp/compiler_support/20

trinovantes 5y ago

I once had an in-person interview where they gave me a sheet of printed code and asked me to point out the syntax errors. Some interviewers are absolutely insane.

hdjjhhvvhga 5y ago
Actually this one might make sense, depending on the code and the position you applied for.
- trinovantes 5y ago
  It was for a junior c# position so I doubt it's applicable considering Visual Studio will point out the problems. But I'm curious what position would this question make sense?
  - burntoutfire 5y ago
    It doesn't sound that stupid, it checks whether you know the syntax of the language you'll be programming in.
    - exdsq 5y ago
      Depends... imagine getting four pages of C# code and having to play Where's Wally but you're not even sure what Wally looks like. Surely it'd be better to just write FizzBuzz.
    - mns 5y ago
      It's literally asking someone to write perfect code in a time limited situation, under pressure, how can someone with any kind of coding experience ask someone else to do in an interview?
      - killtimeatwork 5y ago
        It not literally asking to write any code, just to read it.

biztos 5y ago

I find it… troubling? That a technical interviewer can’t tell for herself whether your code will work. Wouldn’t you ideally want people who actually understand code to be giving the coding questions?

ellenhp 5y ago
Are you saying that because this interviewer needs to run code to find logic errors, she's somehow not a competent engineer? Because I usually need to run code to find logic errors. Sometimes I use formal verification instead but that's pretty rare. Am I also not a competent engineer?
- gspr 5y ago
  Does this reasoning not also apply to the applicant, though?
  - mlyle 5y ago
    So, we can have an interviewer perform a possibly incorrect manual validation of an interviewee's possibly faulty code. Reading code is harder than writing it, and presumably the applicant has been asked to do something tricky. Or they can run it, asking the real arbiter of truth whether it works or not. Of course, "whether it works" is merely one (very important) metric of quality.
    - ellenhp 5y ago
      Yeah. If I were asking a trickier question and I got an interesting new variant of the solutions I'm aware of, I'd absolutely run it if I had time to type it up and everything. Most solutions are either something I've seen before verbatim or obviously wrong, though.
    - tsukikage 5y ago
      The interview is a proxy for working with the person. In this case, it's a proxy for pair programming / code review. A good chunk of what the interviewer, ideally, looks for when asking a coding question is communication from the interviewee - can the interviewee communicate what they are doing and why? Can they explain the intent of the thing they've just written? Do they have a clear picture of it in their head, and can they communicate it? When the interviewer spots problems with it, what does the ensuing discussion look like? - how well does the interviewee collaborate in solving them? If the interviewer is wrong, does the interviewee push back? How? Can they understand you, and can they make themselves understood? Can you work with this person? Can you collaborate to write code, or will it be a daily struggle? Whether the code actually builds and runs after the hour is up does not help answer these questions; it is arguably the least interesting part of the whole process. The time limit is artificial; if all the other things align but you didn't happen to get it working in one hour, you'll likely have got it in two. If they don't align, you'd likely never have got it.

gspr 5y ago

It's also incredibly telling that the interviewer couldn't figure out whether your code was correct or not without compiling and running it.

TGImemegen 5y ago

Googler here. At some stage of the interview process, we have to check whether you're able to code, there's no way around it if you're applying for a coding position. So yes, we'll have you code the solution to a problem. Of course in the real world we'd use a library or look up the algorithm on stack overflow like everyone else. Good for you if you came up with a workable algorithm for the problem quickly. But that's not the only point of the interview. An important goal there is to check if you can really code. We don't usually care if you don't know find the perfect algorithm (unless it's for a senior position), and in fact it's a desirable property if you don't, because that allows us to see your thinking process. Some of the best interviewees I've had, they didn't have the right solution, but impressed me with how they thought about the problem and dealt with the situation of having a problem in front of them that they didn't know how to solve. How they considered possible boundary conditions and restrictions and extensions. Someone saying "yeah, this is just depth-first-search" and then spits up a memorized solution gives me zero insights on whether the candidate is good (and will likely not allow me to write great feedback on the candidate, unless they're able to sell me that they understand what they are doing and why and how). It's usually expected that most of the interview will be taken up by you implementing some algorithm, and it's expected that you won't get every detail right. We do NOT require you to produce token-by-token perfect code, and nowhere in the process will I ever have to give feedback on whether the code produced was actually valid. So maybe you misunderstood your interviewer's intention, or something else went wrong, or maybe they were just joking. But it's not the interviewers task to copy code into GCC and try it out, that'd be a huge waste of time. So let me be very clear and explicit: no-one gets classified as "no hire" because they've forgotten a semicolon somewhere. You messed up somewhere else. With that said, if a candidate says they can write in a language, we expect them to know the language, its idioms and at least parts of the standard library. Not every nook and cranny (e.g. I'd often instruct candidates "just pretend you have some library that implements a heap, and invent an API for it, I don't care about that part"), but if you call "strlen" in the termination-condition of your for-loop instead of before, or do other stuff that shows you don't know the language well, that's a red flag. After all, we expect you to be able to write production-level code that servers billions of users.

hownottowrite 5y ago

bborud 5y ago

I worked at Google and did a fair share of interviews. Two observations: When you have 3 interviews per week for a prolonged period, you, as an interviewer, are not going to do a stellar job every time. What's worse: you will develop a routine and it becomes very easy to give candidates that do not fit your routine a lower grade. It takes effort on the interviewers part to recognize talent that perhaps doesn't fit your routine or your expectations. If you are not going to end up being a bad interviewer you also have to try to relate what you see in interviews to what you know about work. For instance I _never_ asked people to code live (mostly on whiteboards back then) because it just isn't a relevant exercise. And I was kind of horrified at experienced interviewers who asked people to code and then got obsessive about small details that the tooling would have taken care of. Absolutely pointless. The only piece of advice I found useful from the interview training was this: this is the candidate's big day. For you it is a chore, for them it is their big chance. Keep that in mind and respect it. I kept telling myself this for every interview - and some days I felt really terrible because I wasn't properly prepared. The other thing that horrified me was when we let inexperienced people who had been out of school for less than a year interview people. These interviewers barely knew how to write software themselves, and they'd get even more hung up on irrelevant stuff because they simply had no idea how to be software engineers. I doubt that I would have done very well in those kinds of interviews because this isn't how I work and it certainly isn't how I teach people to do problem solving. Problem solving requires more time because any even mildly tricky problem worth solving tends to have a lot of facets far beyond picking an algorithm or knowing how to code it up. That's the easy part because for that part, you have books, papers, tools and other people to seek advice from. Junior programmers right out of school with no engineering experience have no business interviewing developers. They make poor and overly judgemental interviewers and only rarely are able to spot talent if it doesn't fit their template. They also aren't going to fight for candidates that may not fit the imaginary template, but have some special gift because they are junior programmers. It takes a certain amount of balls to say "I know you think this candidate is rubbish, but I see something here and I don't care what you say, I am going to insist". (btw, statistically, this used to be a good predictor for later success: candidates that were somehow "controversial" in that they didn't make the grade with some interviewers, but displayed something that made other interviewers fight for them)

ballenf 5y ago

My lesson learned was "don't listen to what they say, watch what they do". As in, don't trust them to tell you what they're looking for, understand that figuring out what they're actually testing is also part of the screening process. I don't see a lot of focus on the hide-the-ball aspect of interviews, but is something I've experienced a few times and bothers me way more than anything else. The clearest time this happened I was told the company was big on pair programming, so I'd be doing a pair programming session. It turns out they meant I'd be tested on whether I could finish a coding exercise in the allotted time with someone watching. There was zero "pair programming" of any kind involved and time spent on collaboration counted against me.

markus_zhang 5y ago

Sometimes I sarcastically think they already have a friend who applies and needs to fail the others.

nowherebeen 5y ago
That does happen more often than you think. The hiring manager wants to hire a friend, tells HR he needs to hire a good programmer in mind (but doesn’t disclose it’s his friend). HR tend posts job postings for legal reasons knowing full well none of the candidates will be hire. They then reject a few candidates and then brings the friend saying they couldn’t find someone more qualified.

sltkr 5y ago

Let me first concede a few points: 1. You should have been better informed about the expectations of the interview, so you would have had a chance to prepare yourself. 2. Coding in a Google Doc is a terrible experience. It's a step up from coding on a whiteboard, but that's not saying much. Google has since moved away from both, prefering an online text editor that's not quite an IDE but at least more programmer-friendly. 3. The goal shouldn't be to write 100% correct code without any compiler feedback. That's insane. Still, there is a big difference between "candidate forgot a semicolon once" and "candidate did not know how to write a for-loop without IDE feedback". But beyond those valid complaints, it sounds like you were also unhappy that you were asked to write any code at all. I don't think that's reasonable. The point of a phone interview for an entry-level SWE is to determine two things: 1. Can they figure out how to solve a nontrivial problem? 2. Are they able to translate ideas into reasonable, working code? For an algorithm question that boils down to a topological sort, the interviewer will see three kinds of candidates: 1. Those that don't have a clue how to solve it. 2. Those that recognize it boils down to a topological sort. 3. Those that recognize it boils down to a topological sort and are able to implement a solution. Each of these candidates is strictly better than the last, and Google only wants to hire the third one. > I didn't remember the exact algorithm so I basically had to re-figure it out on the fly Yes! That was the whole point of the question! You had already demonstrated that you were at least a "type 2" candidate, so now the interviewer was trying to move beyond that and figure out if you were actually a "type 3" candidate. Nobody expected you to have the exact solution memorized, but they expected you to be able to figure it out from first principles. > I even similarly mention "in any real situation I would just look this up", but that didn't help That was missing the point, which was to test your ability to actually implement a solution. In the real world, if you encounter a standard problem (which happens often, like "I need this list sorted" or "I want to put this stuff in a hash table for O(1) access") you wouldn't even look up how to solve it. You would just call the existing standard library function and move on. Logically, the problems that you end up spending most of your time on are not of the standard variety, and involve actually thinking about how to break down the problem and actually implementing your intended solution. Those are the problems Google needs you to solve on the job. If you can't even implement a topological sort from scratch, why should anyone expect you to do anything more complicated than that?

throwawayboise 5y ago

I've never written a sort from scratch since my college days, over 30 years ago. Also never had a job interview that asked me do to so, or any other coding questions. I'm planning more for retirement than a next job at this point, but I shake my head at what my younger colleagues need to go through these days for the opportunity to write JavaScript with IDEs that do most of the work for you.

simias 5y ago
I sometimes have to implement a sorting algorithm when I write bare metal code that doesn't have any sort of standard library available. Of course, being a 1337 hacker, I then resort to the state of the art bubble sort. Or maybe an insertion sort if I'm feeling fancy. But enough bragging.
- jt2190 5y ago
  OT: I wish I could relocate a blog post (on Microsoft’s site, I think) about a very a naive and “obviously wrong” sorting algorithm that a dev identified in their (Excel?) codebase. Turns out the code was naive because the vast majority of their users were sorting very small sets of data and the implementation actually performed much better in those circumstances.
  - jhck 5y ago
    Maybe it's this one? https://ericlippert.com/2020/03/27/new-grad-vs-senior-dev/ https://ericlippert.com/2020/03/27/new-grad-vs-senior-dev/
- bear8642 5y ago
  > I then resort to the state of the art bubble sort Remember reading Bentley's Programming Pearls and fairly sure that's what he starts Sorting section with a short implementation of
- JTbane 5y ago
  Funnily enough, if you're sorting small amounts of stuff it does not matter what algorithm you use. If fact your O(n log n) sorts are probably a lot slower on less than some millions of elements.

lawn 5y ago

I had a similar experience interviewing years ago for Google, although I can't remember the algorithm they wanted me to implement.

dekhn 5y ago

i failed quicksort the first time I interviewed at google. then got hired and worked there for 12 years and never wrote a sort. I also complained that google's coding solution (docs, basically) was a terrible way to code, other companies use coderpad or whatever, but I expect that Google will never change this. They love to hire people who are excellent at coding CS approximate solutions, but have little to no judgement on how to do good software engineering.

telotortium 5y ago
The pandemic has finally. forced them to move to something more Coderpad-like

endtime 5y ago

Standard disclaimer: everything below is my own opinion based on my personal experience, and I'm not speaking on behalf of my employer. > I thought I was done, then the interviewer said she would go go copy my code and compile it after the interview to see if I was right, which blew my mind. I've been interviewing at Google for nine years and have never done this. I generally don't think it's fair to ding a candidate for something I don't notice in an interview, where I'm at a huge advantage. If it looks right to me then that's good enough. But that said, I have often asked questions similar to what you describe. You have to write code in the shared doc because hiring committees want to see it - fair to blame the process for that, but not the interviewer. I actually appreciate this for a couple reasons: * It levels the playing field a bit, in the sense that code is more objective than an interviewer's notes on how a conversation went (especially for people who aren't native English speakers) * I sometimes find that candidates who communicate well struggle to turn their ideas info code. Other times, someone's communication and solution are kind of average, but then they use all the little things I like seeing (defaultdict(set), zip, etc. in Python). Lots of people claim to be very experienced programmers; seeing how comfortable and fluent someone is when actually writing code is a strong signal. If you don't like the focus on data structures and algorithms that you haven't thought about since college, you should probably appreciate the coding part.

mox1 5y ago
How would you feel if you were going to a job as a writer, and the interviewee asked you to put a story, poem, etc. down on a napkin, with a crayon? Like thats how I would feel writing code into freakin google docs during a job interview...with Google. Tie 1 arm behind by back as the synax goes wonky, I'm fighting the spacing, etc. etc. Or put mario Andretti into a ford focus, then test his lap times, with 0 warning. Yuck.
- verticalflight 5y ago
  Just fyi - Mario Andretti and other similar drivers could be placed into any car and would perform at a very high level after a lap or so...
- 5y ago

yawnxyz 5y ago

we must have had the same interviewer! It boggles my mind how this helps their business case / bottom line. And I was applying as a UX designer lol.

deleted 5y ago

[deleted]

FalconSensei 5y ago

I hate this. People have IDEs and internet when working. Having to write something that can be compiled in a doc is just stupid. As someone mentioned in another comment, I also never had to actually implement a sort since I left university more than a decade ago. I'm happy to discuss the different types and approaches to how they could be done - as to evaluate problem solving, logic, and general understanding - but to actually code in an interview... In a similar way, this week I even jokes on Twitter how I'm doing many improvements and refactors on a codebase, but there's the occasional 'how I do join 2 lists on Java again?' moment when I completely forget something basic.