14 ms·

Big Tech Coding Interview Framework – Pt 1. Inspect

191 points by ckcheng 5y ago

ckcheng 5y ago
The series relates to recent https://news.ycombinator.com/item?id=28896343 https://news.ycombinator.com/item?id=28896343 which was just a Google spreadsheet
908B64B197 5y ago
What the author describes... is called drafting a spec. It's something that's taught to first year engineering students (map and understand all the constrains of a problem before attempting to solve it, or else pay the price later...).
- theshadowknows 5y ago
  I was brought in to a project on Friday to help figure something out. The gist of the project is that we have a system which generates tons of event data. Basically interaction logging. And until recently the system sent those logs to some other systems via nightly files. But someone in the business decided it made more sense to do it “real time” and so some folks have been diligently coding away and have built their solution only to find there was a gigantic miss: The system is generating thousands, sometimes tens or hundreds of thousands of events per hour. And the api that is to receive this data can only receive 100 “records” (events) per request, and the system that generates the data can’t do any sort of multi threading or multiple requests simultaneously…it can just fire off one request after another.. I did the math and on our busiest day this process would take something like 827 years to send all of the event data… I say all of this to highlight your point that it’s a foundational skill to gather requirements..and yet I’m working with sr engineers that created this mess…
  - 908B64B197 5y ago
    > and yet I’m working with sr engineers that created this mess… Engineers or "Engineers"? I'm asking because there's a trend in this industry to call everyone engineer (6 months bootcamp front-end engineer). But then you see things like that...
eyelidlessness 5y ago
I have generally avoided or balked at typical coding interview questions. They’re very seldom representative of real work, and have more value for helping big companies avoid lawsuits than helping anyone else evaluate candidates or prospective jobs. That said… the article offers good advice for people going through the process. I’d add that it’s not much different from type- and test-driven development. Which, conceptually, might help readers who are reading this advice and feeling overwhelmed by the idea of trying to gather the information discussed while “buying time to think of a solution”. Which is to say, if that feels like a lot of cognitive load on top of trying to navigate “soft skills” and/or other challenges in an interview, you may find it more grounding if you map the advice to ways you already work. Another way to look at it that occurred to me: it doesn’t feel very different from a very short sprint (or new Kanban card or choose your working cycle abstraction). 1. Planning meeting to clarify user intent, acceptance criteria, whatever you need to get started. 2. Definition of smaller tasks and any feedback loop that might entail. 3. Implementation and its own feedback loop.
- 908B64B197 5y ago
  > They’re very seldom representative of real work, and have more value for helping big companies avoid lawsuits than helping anyone else evaluate candidates or prospective jobs. The point of a coding interview is to eliminate, as fast as possible, people who simply can't code. I'm being completely serious here. They can even have a CS degree (or will claim to but if you look closely they were in an easier program to get into and took CS electives) but cannot write a simple program on the board in an hour.
  - jpgvm 5y ago
    Programmers don't write code on whiteboards. If it was just a matter of determining if they can code or not references and prior work should be sufficient. The real reason they exist is to filter for culture fit without having deal with the associated law suits if this was done outright.
  - eyelidlessness 5y ago
    > The point of a coding interview is to eliminate, as fast as possible, people who simply can't code. I sincerely don’t believe this is true or that there’s any supporting evidence for it besides people repeating it. The point is to eliminate employment discrimination claims for large companies and this is what baseline they established to support the claim. The point for everyone else is: we have too much to do, figuring out how to interview effectively and fairly is too much more work. Let’s use what everyone else uses.
ruraljuror 5y ago
> Asking questions like: “Can strings be multi-character?” can provide you with critical information to the problem. I don't understand this example, which immediately leads to imposter syndrome kicking in because this is supposed to be basic, right? But as I gain more experience I begin to expect this is just poorly written. So can anyone help me understand what is meant by this question?
- sharkbot 5y ago
  I think the author is referring to characters in a Unicode string that are combined to form a composite glyph. For instance, a large number of emojis are formed by combining two Unicode characters with a zero width joiner character. Skin tones are a notable instance, along with gendered occupation glyphs (female doctor, say). It would be a simplifying (and usually correct) assumption to ignore such composite characters in a basic processing task.
  - ruraljuror 5y ago
    This is a great explanation and perhaps this is the author's intent. I think this example is so specific it is not a good way to start. It is better to start by eliminating broad categories and narrow in: can we assume ascii or do we allow unicode?
  - joshuamorton 5y ago
    It's unfortunate that the question isn't itself posed, but I think you're overcomplicating it somewhat (because I think the question/explanation is bad). The input is in the form Array<Str>, not Array<char>, yet the example is ['a', 'b', 'c', 'd']. By the API, an input could just as easily be ['apple', 'banana', 'cherry', 'durian'] by the types provided. For this problem, I also think that's a weird clarification, because it doesn't really change how you approach the problem, which should be to construct a hash table keyed by string and whose values are the number of appearances. In python this would end up being something like `return max(collections.Counter(strs).values()) > k`. Whether the strings are single- or multicharacter isn't relevant unless you're doing something weird.
- 5y ago
voz_ 5y ago
I do not find this useful or correct. Furthermore, the author has another post that says to avoid Cracking the Coding Interview, which is actually a stellar book (even for those who are not interviewing).
m0zg 5y ago
I think it's ridiculous and dumb that otherwise smart people take months out of their busy lives to train these bullshit skills they'll never use outside these "interviews". FWIW, I never prepare for more than a couple of days, and my batting average is pretty good, albeit not perfect. And I'm not a genius by any means. I just line up the interviews from least to most desirable (so I get some "interview training" in), and go with the flow.
- Hermitian909 5y ago
  When companies that offer these interviews are often offering 2x or more compensation, taking the time to study seems to really work out. Doing leetcodes once or twice a week for the rest of my career (if these tests persist) seems like a really cheap price to pay to make over 400k a year.
- alexashka 5y ago
  I think it's fine - everyone gets to interview as they please. What's unfortunate is there being a handful of companies that pay 2-3x what everyone else pays. The very existence of such companies should ring 'ding ding ding anti-trust' but seeing how Microsoft is still kicking, better than ever with its disastrous operating system plaguing humanity, I don't have much faith in future legislators.
- zz865 5y ago
  How many interviews do you line up at a time? I can only set up a few at a time because I find it gets unmanageable.
  - m0zg 5y ago
    Usually 3-4. It's tough to line them up, so the ordering is not always complete, but I do get a couple of "doesn't matter" interviews done before I go for a "meaningful" one. Sorry for wasting your time, companies that don't matter. You wrote the rules, I merely play the game.
    - zz865 5y ago
jurassic 5y ago
I give a lot of FAANG interviews these days, and I'm stunned how many people skip this important step of understanding the problem, asking clarifying questions to surface important constraints, and making a plan before launching off into implementation. It's not rocket science.
- reducesuffering 5y ago
  Because common expectations are two complex algorithmic problems finished coding up in 45 minutes? “Show me the incentives and I will show you the outcome.” and “It’s not rocket science.”
  - dilyevsky 5y ago
    Common at fb maybe not at any sane place I’ve ever interviewed with
    - reducesuffering 5y ago
      GP said FAANG, which is the case in general at those companies
      - dilyevsky 5y ago
        Even among faangs this is a distinctly fb thing
        reducesuffering 5y ago
        I have personal experience that it’s common at Amazon and have many corroborating examples it’s done at Google too. Maybe not years back, but definitely in the past couple years.
- fny 5y ago
  A lot of it is nerves driven. They want to look smart, so they just rip through the question even though they probably know better. (I have been a victim of this myself.)
codeyperson 5y ago
I don't like the expectation that all people should approach problem solving in a particular way. Everybody is different. Personally, I like to continuously implement and clarify in small tight loops. It might look something like: implement a rough structure with lots of empty functions and very basic control flow. Ask questions. Restructure. Ask more questions. Restructure again and add implementation detail. Etc etc. This way of working is tied with my thinking. It reveals the problem to me over time instead of all at once. I get a deeper understanding this way. There is an assumption by some people that my process is wrong. They would argue that I should instead break the problem down on paper, or in my head, or using test driven development, or with design documents etc etc. But this is the process that I've found works best for me. I can enforce a particular process to please interviewers (and I have). But solving the problem becomes much harder.
- asdfasgasdgasdg 5y ago
  Even if your typical way of solving problems is via intuition and internal processing, materializing this stage on the whiteboard probably improves your odds in a coding interview. It's not a statement about how things should be, but how things are. Even if this isn't your preferred mode of problem solving, I'm confident that any qualified candidate is capable of doing what was demonstrated in this post, and if they really want the job, they probably should.
  - LurkingPenguin 5y ago
    > Even if this isn't your preferred mode of problem solving, I'm confident that any qualified candidate is capable of doing what was demonstrated in this post, and if they really want the job, they probably should. I get that Big Tech jobs are glamorized the way high-paying jobs in Big Law, High Finance, etc. have historically been glamorized, but unlike professions like law and finance, there are lots of opportunities for people with even decent development skills to make really good money today even if they don't work for Big Tech. As an example, my friend's son is making well over $120,000 annually as a freelance PHP developer with a few years of experience. He's in his late 20s, doesn't have a comp sci degree and lives in a lower cost of living city where he's probably at least in the top 5% of earners. On the flip side, I know people who are hiring for developers and they're more and more flexible, especially in regards to location and remote work, because the demand for decent developers greatly exceeds the supply. Why someone should feel compelled to pretend that they problem solve differently to ace a whiteboard in this market is beyond me.
brhsagain 5y ago
This seems completely pointless: either you understand how to solve the question, in which case you don't need any of this, or you don't, in which case all of this won't help you. Reminds me of Magnus Carlsen saying his biggest advantage is that he is better than his opponent at chess. The real "framework" for passing coding interviews is to get better at understanding and solving the problems.
- Jensson 5y ago
  This framework help people feel better about themselves when they fail the interview, since at least they wrote a lot of things on the board and didn't just get stuck.
  - Apocryphon 5y ago
    Rather droll and overly uncharitable reading, perhaps. Given the highly performative nature of these interviews, where the candidate is expected to explain their "way of thinking", writing out thought processes in a systemized, scientific investigative matter will at least earn partial credit.
    - therealdrag0 5y ago
      As an interviewer, this is true for me. I don’t just care about your solution. I care about how and what you communicate during it.
mgraczyk 5y ago
It's important to understand the question and communicate that understanding before you start coding. For relatively junior positions (L3-L4 at Google), I would expect that a candidate would do roughly what was described in the linked post. However, it's really important not to behave in a way that is overly formulaic or comes across as being heavily "coached". If your interviewer is engaged and competent, coaching like this will entice the interviewer to mix things up and ask questions that force you to break out of the coached pattern. If the interviewer isn't as good, it's more likely they will just give you a lukewarm score and say that you were coached. For example, if a candidate said something like "can strings be multicharacter?", I'd probably ask why that would matter. In the example question, it doesn't matter at all because we're just looking for equality of members (could be arrays of any type and the question would be the same), and would be a weird thing to seek clarification on. Maybe a better example would be if the candidate asked if there's an upper bound on the size of the input array. In real programming, that's not the sort of thing that usually matters, so I'd expect the candidate to explain why that matters in this case (maybe they have a O(n^3) algorithm in mind that would be untenable if the input can be large). I've done a few hundred interviews, over 100 at Google.
sydthrowaway 5y ago
Fear of leetcoding is going to be the next big mental health issue in tech
- therealdrag0 5y ago
  How could it if there’s selective pressures for not fearing leetcode :)
Apocryphon 5y ago
An attempt of a framework for solving whiteboarding/Leetcode problems is helpful, and it should always invite us to ask what computer science pedagogy is missing. Any CS program worth its salt includes data structures and algorithms courses- they are simply fundamental elements of the discipline. And yet, why are these interviews so difficult? I don't think it's simply an issue of many people having gone through these programs and failing to absorb or retain the material. Neither do I think there is a severe mismatch in the material covered and the interviews. Yes, some interview questions are awfully close to logic puzzles - having to know the two pointer trick for detecting cyclic graphs, what CS program covers that industry-specific technique? - but others are fundamental applications of trees, graphs, dynamic programming, etc. Could it just be that academic CS doesn't approach solving problems in the same way as these interviews do? Are there meta-problem solving techniques that these courses simply don't cover? Heuristics that must be applied when one approaches a general problem before the topic is narrowed down? "Ah this involves a tree, ah this requires sorting, ah we should use a hash table?"
- wly_cdgr 5y ago
  Why don't you think it's simply an issue of many people who go through CS programs failing to master the material? It's hard to imagine someone who did well in, say, Sedgewick's sequence at Princeton (which, by the way, is available on Coursera for free for anyone who didn't want to go to Princeton) - it's hard to imagine someone like that struggling with entry level tech interview questions
  - Apocryphon 5y ago
    Is it? If it's so straightforward, then why don't all of the people who are struggling with these questions simply take the Coursera course? At the very least, these interviews require the applicant to be immediately familiar with any of the topics that might span a semester (or two) long course, so recall could be an issue.
    - wly_cdgr 5y ago
      They probably should! Also, recall would only be an issue if they didn't truly master the material. Do you need to recall how to ride a bike after you've learned to do it?
wly_cdgr 5y ago
Never study for a test directly, particularly if it figures to help you get a job. Just learn stuff and build stuff
- jpgvm 5y ago
  Learning and building stuff won't help you pass these interviews. Which is ironic but it also means that applying for a company that uses such interviews is a completely different task to becoming a better engineer. Personally I avoid such places, there is sufficiently good compensation available elsewhere from people that don't expect me to perform parlour tricks on a whiteboard for their amusement.
  - Jensson 5y ago
    It depends on what you learn and build. If you learn and build algorithmic solutions to hard problems then it will help with these interviews.
    - jpgvm 5y ago
      I think even having a working knowledge of common algorithms and data-structures is insufficient preparation for these. They often call for incredibly esoteric algos/datastructures or test for patterns incredibly uncommon in industry, i.e dynamic programming. I would say even if you had a good background in how to implement a proper production ready database, i.e b+trees, bloom filters, journaling, etc. This while certainly enough to do the job of building a database would be insufficient to pass the interview to build a database. Which to me seems like the system is broken.
still_grokking 5y ago
I had a look at the linked spread sheet¹ containing all the framework questions. It's actually great advice for solving any programming problem — not only in case of a whiteboard interview. Not that you need to write down everything explicitly for any problem. But you should in any case think through all of the mentioned things at least. The other thing I've noticed is that a strong type-system will from the get go force you to describe exactly—down to the details—at least 80% of that stuff. Refinement types for example let you constrain further types with a lot of inhabitants. But even the usual things like optional or, for the contrast, non-empty types can help greatly. With some formal verification capabilities on top you could likely even codify more than 90% of the things mentioned in that spread sheet. Add some meaningfull comments with the reminder of the answers and you'll get almost perfect code in my opinion. I would bet bug count in software overall would go down by more than 90% — if only all code would look like that in reality… ¹ https://docs.google.com/spreadsheets/d/1gy9cmPwNhZvola7kqnfY3DElk7PYrz2ARpaCODTp8Go/edit#gid=0 https://docs.google.com/spreadsheets/d/1gy9cmPwNhZvola7kqnfY...
DeathArrow 5y ago
I got to the point that I am telling recruiters that "leet coding" on the whiteboard will double my financial demands. I did a fair share of problem solving on whiteboard, replying to very specific questions about libraries and frameworks. But I've also accumulated some experience. And if my experience isn't enough, if you can't tell by having a discussion with me if I fake it or not, then with all due respect I will tell you that I have better things to do with my time.
- smcl 5y ago
  How do they react to being told that? I don’t imagine many companies are prepared to rework their interviews on the fly like that, so my naive guess would be that they continue with the interview and proceed to offer the original salary they planned to
  - DeathArrow 5y ago
    >How do they react to being told that? They tell me that this is how things work for their company. Which means I do not have to waste my time with them.
  - brailsafe 5y ago
    I've just told numerous companies that I won't do it, and they don't care, because they're just trying to fill seats and the sellers market isn't what some people make it out to be.
    - DeathArrow 5y ago
      I am not searching for work. The recruiters are reaching out to me. And many companies are not trying to whiteboard me.
      - brailsafe 5y ago
        I am searching for work, but these are largely asked by recruiters of me. It usually goes 0.5) Call with recruiter 1) coding test 2) call with 1 - 3 other people 3) Call with CTO or something 4) usually there's some other call I've started saying no to these though
jillesvangurp 5y ago
In my experience, it's never a good sign when coding exercises are brought up when I'm being interviewed. I make a point of not doing that my self when I'm interviewing because I consider it disrespectful and actively harmful. Most people that I'd actually like to hire would hate me doing that. I've actually had interviewers apologize for their lame test during the interview to me; probably because they sensed my annoyance. Usually it's a thing that HR insists on as a screening mechanism because they've heard that that is a thing they should do. Also a work culture where that is a thing breeds employees that believe it is actually a good thing. It's the old A's hire A's, B's hire C's thing. Usually, screening becomes necessary when you have recruiters supplying you a lot of C's with the occasional B. Those recruiters don't have access to either good candidates or good projects, typically. Either way, there's a class of engineers that will happily decline to take coding exercises because they have better options to choose from because they just are that good and are probably not even answering the spam that your recruiter is shoveling out by the thousands. That's actually the kind of people I'd like to hire. I don't waste my time with doing interviews for jobs a lot and any hint of a coding exercise is a sure way for me to loose interest. I mostly ignore recruiter spam. Just like most half decent engineers I know. It's actually a good way to screen projects; there is a lot of mediocrity in this industry. I look for a certain level of quality in projects I join. Coding exercises as part of the process is a red flag. Not necessarily fatal but a red flag still. Especially when interviewing seniors with decades of experience. Never really ends well and I tend to end the process early when that happens. Good engineers don't come begging for a position on your project/company. You actually have to work hard to get them onboard. I know, because I've actually hired a few people that were genuinely very good. Better than me even. I love working with smart people and I love it when I find someone that is clearly razor sharp. When you come across such a person, you become a sales person. It's a time critical process where during the brief moment this engineer is actually not busy working for somebody else, you have an opportunity to convince them to work for you. That's how I interview and that's what I'm looking for when I'm being interviewed. Anything less than that signals to me a level of indifference and mediocrity that I probably need to walk away from. Confronting candidates with some lousy coding exercise is not a great way to sell them on the opportunity. It screens candidates alright: you lose many of the good ones that you probably don't even get to talk to. Beware the candidates that get really enthusiastic about your coding exercise. They might still be good but it's something to explore further during the actual interview.

191 points by ckcheng 5y ago

The series relates to recent https://news.ycombinator.com/item?id=28896343 https://news.ycombinator.com/item?id=28896343 which was just a Google spreadsheet

908B64B197 5y ago

What the author describes... is called drafting a spec. It's something that's taught to first year engineering students (map and understand all the constrains of a problem before attempting to solve it, or else pay the price later...).

theshadowknows 5y ago
I was brought in to a project on Friday to help figure something out. The gist of the project is that we have a system which generates tons of event data. Basically interaction logging. And until recently the system sent those logs to some other systems via nightly files. But someone in the business decided it made more sense to do it “real time” and so some folks have been diligently coding away and have built their solution only to find there was a gigantic miss: The system is generating thousands, sometimes tens or hundreds of thousands of events per hour. And the api that is to receive this data can only receive 100 “records” (events) per request, and the system that generates the data can’t do any sort of multi threading or multiple requests simultaneously…it can just fire off one request after another.. I did the math and on our busiest day this process would take something like 827 years to send all of the event data… I say all of this to highlight your point that it’s a foundational skill to gather requirements..and yet I’m working with sr engineers that created this mess…
- 908B64B197 5y ago
  > and yet I’m working with sr engineers that created this mess… Engineers or "Engineers"? I'm asking because there's a trend in this industry to call everyone engineer (6 months bootcamp front-end engineer). But then you see things like that...

eyelidlessness 5y ago

I have generally avoided or balked at typical coding interview questions. They’re very seldom representative of real work, and have more value for helping big companies avoid lawsuits than helping anyone else evaluate candidates or prospective jobs. That said… the article offers good advice for people going through the process. I’d add that it’s not much different from type- and test-driven development. Which, conceptually, might help readers who are reading this advice and feeling overwhelmed by the idea of trying to gather the information discussed while “buying time to think of a solution”. Which is to say, if that feels like a lot of cognitive load on top of trying to navigate “soft skills” and/or other challenges in an interview, you may find it more grounding if you map the advice to ways you already work. Another way to look at it that occurred to me: it doesn’t feel very different from a very short sprint (or new Kanban card or choose your working cycle abstraction). 1. Planning meeting to clarify user intent, acceptance criteria, whatever you need to get started. 2. Definition of smaller tasks and any feedback loop that might entail. 3. Implementation and its own feedback loop.

908B64B197 5y ago
> They’re very seldom representative of real work, and have more value for helping big companies avoid lawsuits than helping anyone else evaluate candidates or prospective jobs. The point of a coding interview is to eliminate, as fast as possible, people who simply can't code. I'm being completely serious here. They can even have a CS degree (or will claim to but if you look closely they were in an easier program to get into and took CS electives) but cannot write a simple program on the board in an hour.
- jpgvm 5y ago
  Programmers don't write code on whiteboards. If it was just a matter of determining if they can code or not references and prior work should be sufficient. The real reason they exist is to filter for culture fit without having deal with the associated law suits if this was done outright.
- eyelidlessness 5y ago
  > The point of a coding interview is to eliminate, as fast as possible, people who simply can't code. I sincerely don’t believe this is true or that there’s any supporting evidence for it besides people repeating it. The point is to eliminate employment discrimination claims for large companies and this is what baseline they established to support the claim. The point for everyone else is: we have too much to do, figuring out how to interview effectively and fairly is too much more work. Let’s use what everyone else uses.

ruraljuror 5y ago

> Asking questions like: “Can strings be multi-character?” can provide you with critical information to the problem. I don't understand this example, which immediately leads to imposter syndrome kicking in because this is supposed to be basic, right? But as I gain more experience I begin to expect this is just poorly written. So can anyone help me understand what is meant by this question?

sharkbot 5y ago
I think the author is referring to characters in a Unicode string that are combined to form a composite glyph. For instance, a large number of emojis are formed by combining two Unicode characters with a zero width joiner character. Skin tones are a notable instance, along with gendered occupation glyphs (female doctor, say). It would be a simplifying (and usually correct) assumption to ignore such composite characters in a basic processing task.
- ruraljuror 5y ago
  This is a great explanation and perhaps this is the author's intent. I think this example is so specific it is not a good way to start. It is better to start by eliminating broad categories and narrow in: can we assume ascii or do we allow unicode?
- joshuamorton 5y ago
  It's unfortunate that the question isn't itself posed, but I think you're overcomplicating it somewhat (because I think the question/explanation is bad). The input is in the form Array<Str>, not Array<char>, yet the example is ['a', 'b', 'c', 'd']. By the API, an input could just as easily be ['apple', 'banana', 'cherry', 'durian'] by the types provided. For this problem, I also think that's a weird clarification, because it doesn't really change how you approach the problem, which should be to construct a hash table keyed by string and whose values are the number of appearances. In python this would end up being something like `return max(collections.Counter(strs).values()) > k`. Whether the strings are single- or multicharacter isn't relevant unless you're doing something weird.
5y ago

voz_ 5y ago

I do not find this useful or correct. Furthermore, the author has another post that says to avoid Cracking the Coding Interview, which is actually a stellar book (even for those who are not interviewing).

m0zg 5y ago

I think it's ridiculous and dumb that otherwise smart people take months out of their busy lives to train these bullshit skills they'll never use outside these "interviews". FWIW, I never prepare for more than a couple of days, and my batting average is pretty good, albeit not perfect. And I'm not a genius by any means. I just line up the interviews from least to most desirable (so I get some "interview training" in), and go with the flow.

Hermitian909 5y ago
When companies that offer these interviews are often offering 2x or more compensation, taking the time to study seems to really work out. Doing leetcodes once or twice a week for the rest of my career (if these tests persist) seems like a really cheap price to pay to make over 400k a year.
alexashka 5y ago
I think it's fine - everyone gets to interview as they please. What's unfortunate is there being a handful of companies that pay 2-3x what everyone else pays. The very existence of such companies should ring 'ding ding ding anti-trust' but seeing how Microsoft is still kicking, better than ever with its disastrous operating system plaguing humanity, I don't have much faith in future legislators.
zz865 5y ago
How many interviews do you line up at a time? I can only set up a few at a time because I find it gets unmanageable.
- m0zg 5y ago
  Usually 3-4. It's tough to line them up, so the ordering is not always complete, but I do get a couple of "doesn't matter" interviews done before I go for a "meaningful" one. Sorry for wasting your time, companies that don't matter. You wrote the rules, I merely play the game.
  - zz865 5y ago

jurassic 5y ago

I give a lot of FAANG interviews these days, and I'm stunned how many people skip this important step of understanding the problem, asking clarifying questions to surface important constraints, and making a plan before launching off into implementation. It's not rocket science.

reducesuffering 5y ago
Because common expectations are two complex algorithmic problems finished coding up in 45 minutes? “Show me the incentives and I will show you the outcome.” and “It’s not rocket science.”
- dilyevsky 5y ago
  Common at fb maybe not at any sane place I’ve ever interviewed with
  - reducesuffering 5y ago
    GP said FAANG, which is the case in general at those companies
    - dilyevsky 5y ago
      Even among faangs this is a distinctly fb thing
      - reducesuffering 5y ago
        I have personal experience that it’s common at Amazon and have many corroborating examples it’s done at Google too. Maybe not years back, but definitely in the past couple years.
fny 5y ago
A lot of it is nerves driven. They want to look smart, so they just rip through the question even though they probably know better. (I have been a victim of this myself.)

codeyperson 5y ago

I don't like the expectation that all people should approach problem solving in a particular way. Everybody is different. Personally, I like to continuously implement and clarify in small tight loops. It might look something like: implement a rough structure with lots of empty functions and very basic control flow. Ask questions. Restructure. Ask more questions. Restructure again and add implementation detail. Etc etc. This way of working is tied with my thinking. It reveals the problem to me over time instead of all at once. I get a deeper understanding this way. There is an assumption by some people that my process is wrong. They would argue that I should instead break the problem down on paper, or in my head, or using test driven development, or with design documents etc etc. But this is the process that I've found works best for me. I can enforce a particular process to please interviewers (and I have). But solving the problem becomes much harder.

asdfasgasdgasdg 5y ago
Even if your typical way of solving problems is via intuition and internal processing, materializing this stage on the whiteboard probably improves your odds in a coding interview. It's not a statement about how things should be, but how things are. Even if this isn't your preferred mode of problem solving, I'm confident that any qualified candidate is capable of doing what was demonstrated in this post, and if they really want the job, they probably should.
- LurkingPenguin 5y ago
  > Even if this isn't your preferred mode of problem solving, I'm confident that any qualified candidate is capable of doing what was demonstrated in this post, and if they really want the job, they probably should. I get that Big Tech jobs are glamorized the way high-paying jobs in Big Law, High Finance, etc. have historically been glamorized, but unlike professions like law and finance, there are lots of opportunities for people with even decent development skills to make really good money today even if they don't work for Big Tech. As an example, my friend's son is making well over $120,000 annually as a freelance PHP developer with a few years of experience. He's in his late 20s, doesn't have a comp sci degree and lives in a lower cost of living city where he's probably at least in the top 5% of earners. On the flip side, I know people who are hiring for developers and they're more and more flexible, especially in regards to location and remote work, because the demand for decent developers greatly exceeds the supply. Why someone should feel compelled to pretend that they problem solve differently to ace a whiteboard in this market is beyond me.

brhsagain 5y ago

This seems completely pointless: either you understand how to solve the question, in which case you don't need any of this, or you don't, in which case all of this won't help you. Reminds me of Magnus Carlsen saying his biggest advantage is that he is better than his opponent at chess. The real "framework" for passing coding interviews is to get better at understanding and solving the problems.

Jensson 5y ago
This framework help people feel better about themselves when they fail the interview, since at least they wrote a lot of things on the board and didn't just get stuck.
- Apocryphon 5y ago
  Rather droll and overly uncharitable reading, perhaps. Given the highly performative nature of these interviews, where the candidate is expected to explain their "way of thinking", writing out thought processes in a systemized, scientific investigative matter will at least earn partial credit.
  - therealdrag0 5y ago
    As an interviewer, this is true for me. I don’t just care about your solution. I care about how and what you communicate during it.

mgraczyk 5y ago

It's important to understand the question and communicate that understanding before you start coding. For relatively junior positions (L3-L4 at Google), I would expect that a candidate would do roughly what was described in the linked post. However, it's really important not to behave in a way that is overly formulaic or comes across as being heavily "coached". If your interviewer is engaged and competent, coaching like this will entice the interviewer to mix things up and ask questions that force you to break out of the coached pattern. If the interviewer isn't as good, it's more likely they will just give you a lukewarm score and say that you were coached. For example, if a candidate said something like "can strings be multicharacter?", I'd probably ask why that would matter. In the example question, it doesn't matter at all because we're just looking for equality of members (could be arrays of any type and the question would be the same), and would be a weird thing to seek clarification on. Maybe a better example would be if the candidate asked if there's an upper bound on the size of the input array. In real programming, that's not the sort of thing that usually matters, so I'd expect the candidate to explain why that matters in this case (maybe they have a O(n^3) algorithm in mind that would be untenable if the input can be large). I've done a few hundred interviews, over 100 at Google.

sydthrowaway 5y ago

Fear of leetcoding is going to be the next big mental health issue in tech

therealdrag0 5y ago
How could it if there’s selective pressures for not fearing leetcode :)

Apocryphon 5y ago

An attempt of a framework for solving whiteboarding/Leetcode problems is helpful, and it should always invite us to ask what computer science pedagogy is missing. Any CS program worth its salt includes data structures and algorithms courses- they are simply fundamental elements of the discipline. And yet, why are these interviews so difficult? I don't think it's simply an issue of many people having gone through these programs and failing to absorb or retain the material. Neither do I think there is a severe mismatch in the material covered and the interviews. Yes, some interview questions are awfully close to logic puzzles - having to know the two pointer trick for detecting cyclic graphs, what CS program covers that industry-specific technique? - but others are fundamental applications of trees, graphs, dynamic programming, etc. Could it just be that academic CS doesn't approach solving problems in the same way as these interviews do? Are there meta-problem solving techniques that these courses simply don't cover? Heuristics that must be applied when one approaches a general problem before the topic is narrowed down? "Ah this involves a tree, ah this requires sorting, ah we should use a hash table?"

wly_cdgr 5y ago
Why don't you think it's simply an issue of many people who go through CS programs failing to master the material? It's hard to imagine someone who did well in, say, Sedgewick's sequence at Princeton (which, by the way, is available on Coursera for free for anyone who didn't want to go to Princeton) - it's hard to imagine someone like that struggling with entry level tech interview questions
- Apocryphon 5y ago
  Is it? If it's so straightforward, then why don't all of the people who are struggling with these questions simply take the Coursera course? At the very least, these interviews require the applicant to be immediately familiar with any of the topics that might span a semester (or two) long course, so recall could be an issue.
  - wly_cdgr 5y ago
    They probably should! Also, recall would only be an issue if they didn't truly master the material. Do you need to recall how to ride a bike after you've learned to do it?

wly_cdgr 5y ago

Never study for a test directly, particularly if it figures to help you get a job. Just learn stuff and build stuff

jpgvm 5y ago
Learning and building stuff won't help you pass these interviews. Which is ironic but it also means that applying for a company that uses such interviews is a completely different task to becoming a better engineer. Personally I avoid such places, there is sufficiently good compensation available elsewhere from people that don't expect me to perform parlour tricks on a whiteboard for their amusement.
- Jensson 5y ago
  It depends on what you learn and build. If you learn and build algorithmic solutions to hard problems then it will help with these interviews.
  - jpgvm 5y ago
    I think even having a working knowledge of common algorithms and data-structures is insufficient preparation for these. They often call for incredibly esoteric algos/datastructures or test for patterns incredibly uncommon in industry, i.e dynamic programming. I would say even if you had a good background in how to implement a proper production ready database, i.e b+trees, bloom filters, journaling, etc. This while certainly enough to do the job of building a database would be insufficient to pass the interview to build a database. Which to me seems like the system is broken.

still_grokking 5y ago

I had a look at the linked spread sheet¹ containing all the framework questions. It's actually great advice for solving any programming problem — not only in case of a whiteboard interview. Not that you need to write down everything explicitly for any problem. But you should in any case think through all of the mentioned things at least. The other thing I've noticed is that a strong type-system will from the get go force you to describe exactly—down to the details—at least 80% of that stuff. Refinement types for example let you constrain further types with a lot of inhabitants. But even the usual things like optional or, for the contrast, non-empty types can help greatly. With some formal verification capabilities on top you could likely even codify more than 90% of the things mentioned in that spread sheet. Add some meaningfull comments with the reminder of the answers and you'll get almost perfect code in my opinion. I would bet bug count in software overall would go down by more than 90% — if only all code would look like that in reality… ¹ https://docs.google.com/spreadsheets/d/1gy9cmPwNhZvola7kqnfY3DElk7PYrz2ARpaCODTp8Go/edit#gid=0 https://docs.google.com/spreadsheets/d/1gy9cmPwNhZvola7kqnfY...

DeathArrow 5y ago

I got to the point that I am telling recruiters that "leet coding" on the whiteboard will double my financial demands. I did a fair share of problem solving on whiteboard, replying to very specific questions about libraries and frameworks. But I've also accumulated some experience. And if my experience isn't enough, if you can't tell by having a discussion with me if I fake it or not, then with all due respect I will tell you that I have better things to do with my time.

smcl 5y ago
How do they react to being told that? I don’t imagine many companies are prepared to rework their interviews on the fly like that, so my naive guess would be that they continue with the interview and proceed to offer the original salary they planned to
- DeathArrow 5y ago
  >How do they react to being told that? They tell me that this is how things work for their company. Which means I do not have to waste my time with them.
- brailsafe 5y ago
  I've just told numerous companies that I won't do it, and they don't care, because they're just trying to fill seats and the sellers market isn't what some people make it out to be.
  - DeathArrow 5y ago
    I am not searching for work. The recruiters are reaching out to me. And many companies are not trying to whiteboard me.
    - brailsafe 5y ago
      I am searching for work, but these are largely asked by recruiters of me. It usually goes 0.5) Call with recruiter 1) coding test 2) call with 1 - 3 other people 3) Call with CTO or something 4) usually there's some other call I've started saying no to these though

jillesvangurp 5y ago

In my experience, it's never a good sign when coding exercises are brought up when I'm being interviewed. I make a point of not doing that my self when I'm interviewing because I consider it disrespectful and actively harmful. Most people that I'd actually like to hire would hate me doing that. I've actually had interviewers apologize for their lame test during the interview to me; probably because they sensed my annoyance. Usually it's a thing that HR insists on as a screening mechanism because they've heard that that is a thing they should do. Also a work culture where that is a thing breeds employees that believe it is actually a good thing. It's the old A's hire A's, B's hire C's thing. Usually, screening becomes necessary when you have recruiters supplying you a lot of C's with the occasional B. Those recruiters don't have access to either good candidates or good projects, typically. Either way, there's a class of engineers that will happily decline to take coding exercises because they have better options to choose from because they just are that good and are probably not even answering the spam that your recruiter is shoveling out by the thousands. That's actually the kind of people I'd like to hire. I don't waste my time with doing interviews for jobs a lot and any hint of a coding exercise is a sure way for me to loose interest. I mostly ignore recruiter spam. Just like most half decent engineers I know. It's actually a good way to screen projects; there is a lot of mediocrity in this industry. I look for a certain level of quality in projects I join. Coding exercises as part of the process is a red flag. Not necessarily fatal but a red flag still. Especially when interviewing seniors with decades of experience. Never really ends well and I tend to end the process early when that happens. Good engineers don't come begging for a position on your project/company. You actually have to work hard to get them onboard. I know, because I've actually hired a few people that were genuinely very good. Better than me even. I love working with smart people and I love it when I find someone that is clearly razor sharp. When you come across such a person, you become a sales person. It's a time critical process where during the brief moment this engineer is actually not busy working for somebody else, you have an opportunity to convince them to work for you. That's how I interview and that's what I'm looking for when I'm being interviewed. Anything less than that signals to me a level of indifference and mediocrity that I probably need to walk away from. Confronting candidates with some lousy coding exercise is not a great way to sell them on the opportunity. It screens candidates alright: you lose many of the good ones that you probably don't even get to talk to. Beware the candidates that get really enthusiastic about your coding exercise. They might still be good but it's something to explore further during the actual interview.