9 ms·

Every time I read these posts I find them very depressing. Crunch through an enormous bunch of algorithm problems in order to perform well on some unrealistic

by conorh 6y ago

Every time I read these posts I find them very depressing. Crunch through an enormous bunch of algorithm problems in order to perform well on some unrealistic whiteboard programming (I think the system engineering problems are actually more useful though) - as usual we've focused on the easy to measure metric rather than anything actually useful. Maybe these things are meant to be a proxy for how good you are at other development tasks, but it has never seemed to work out that way to me. Some of the very successful people I know at FAANG companies have told me that they would not pass the algorithm interviews without months of preparation and that they don't really use those skills.

gonzo41 6y ago
It is a proxy or how good you are at other development tasks. I think it's a bad proxy. Mostly because I've read and studied CLRS at school. And I don't use the fun parts much in the wild. I'm also not expected to be able to recall things that you can look up. One 'slightly' shameful things I noted about myself reading that list of system design interview questions is that I actually don't use most of those systems or know their features well enough. Other than YT of course. I feel like the simpler interview process would be to just take a person and do a hand wavy system design interview. Then if they pass, hire em on probation for 2 months and slam them with work. They get paid, you maybe get a feel for them. They sink or swim. You keep em' or toss em' away at the end of the two months.
- wojciii 6y ago
  Hmm.. this is how I got hired last year. I told the employer that I wanted to test them and to get me a short term project we could use to determine if company/me are a good match.
- dntrkv 6y ago
  That approach would work for a startup, but not when you’re hiring 100s of engineers on a weekly basis. Not to mention the amount of bias that approach will introduce. At least with the current approach, you know exactly what the criteria is to land the gig.
davidw 6y ago
I don't know that it's depressing, more that it's indicative of a culture I don't want anything to do with, which is fine with me. At least it's truth in advertising.
blisterpeanuts 6y ago
After 20 years in software, I had a phone interview with an Amazon guy who sounded half my age (at most). Asked me to write some kind of function to do something, sort some stuff or some such. I described verbally how I would do it, almost line by line, in pseudo-code. He said "I need you to write it out in [some language]". I said "But why? I just told you how I'd do it." But he needed me to literally write the code out, as though I couldn't easily copy-and-paste something for him. I thanked him and hung up. All I learned from that encounter is that I'd be very unhappy working with people like him. Bullet dodged. Sure, I use my knowledge of algorithms, and I frequently look such things up on StackOverflow and improve my knowledge; we all do. But these interviews seem designed to filter out experienced, pragmatic programmers and just bring in more cookie-cutter software engineering BS/MS recent grads who speak their language. A far cry from the startup environment that most of these companies began as!
- mrits 6y ago
  "But why?" Because most people can't. And they want to make sure you can.
  - jrd259 6y ago
    We always allow the candidate to use any reasonable language. We're not testing if someone knows Java/Python/Lisp (I wish). We're testing if they know any language. I can confirm seeing people with resumes who nevertheless could not write any code even in the language they professed to be "expert" in.
    - jrib 6y ago
      Same. I learned through experience to ask for a candidate to write a couple of lines of code. Usually it's just some simple question that requires a single loop. We explicitly tell them they can use any language including one they want to make up as long as they are ok explaining how it works. When possible, I try to relate it to the conversation we've had up to that point. I've had someone start off by writing "four" on the board when prompted to write a "for" loop and get stuck. I'm still not sure if he was truly inexperienced or just trolling. The resume looked solid to me and he spoke well about his experience. I had almost decided to just skip the coding question as a result.
rektide 6y ago
I'm quite sympathetic. I think there's a huge domain of experiences that engineers bring with them. However, I also see some wisdom here. I still don't full agree with it, but I see some sense too. These are core skills for an undergraduate Computer Science degree. They represent the bulk of our abstract knowledge of how to compute well, how to think about & break down problems. Without proficiency here, a coder risks creating potentially dangerously inefficient solutions, that, at Facebook's scale, may well literally cost the company millions of dollars in server costs, or which could make the difference between a successful on-time positive-PR roll-out, & a failed highly-negative public-relations roll-out. That you can gain this knowledge in a couple of months is fairly remarkable in & of itself. Most engineering domains have a much broader swarth of core knowledge. Computer science literally has algorithms.
- engineeringwoke 6y ago
  > Without proficiency here, a coder risks creating potentially dangerously inefficient solutions, that, at Facebook's scale, may well literally cost the company millions of dollars in server costs, or which could make the difference between a successful on-time positive-PR roll-out, & a failed highly-negative public-relations roll-out. This is a common refrain, but juniors and mid-levels don't work on stuff like this at FAANG. If there's anything those guys are good at, it's making sure that you don't have too many cooks in the kitchen. Interviews like these don't find cooks, which is somewhat the point.
  - rektide 6y ago
    my experience in the industry of coding has driven home to huge points: 1. that each individual & each team has an enormous amount of leeway & personal responsibility. teams are vested with what power they take & how far they & their environment let them. 2. complexity is everywhere & typically to work, to produce, is to add complexity & create new ways for things to go bad. indeed part of what is most notable about FAANG companies is that they have colossal staffs- & notably many of their senior engineer ranks- working to manage & reduce complexity, by inventing continuous integration/deploy systems, by devising trackers for cyclocmatic code & cyclomatic data-dependency/data-access-pattern complexity, by creating more resilient infrastructure & new ways to administrate systems. i fully agree that there is a huge opportunity cost. i think it's madness how focused & specific these interview courses are, what a set path they are on. but i also think it's been underspoken that learning algorithms & data-structures & less so systems are fairly core material to the industry, that these are basic truths that underpin every single thing we do. and i think the knowledge is acquireable and important. and i think just as much, it's unsaid, culturally, a lot of my first point: that individuals in this industry have enormous liberties, that they are sent off to incredible & weird tasks, to go drag something or other back to the company. notably, it's just so so so so hard for a company to take responsibility for "it's" code, to re-integrate, to handle, the new complexity that gets dragged in to base, by each individual contributor. there are so few repeatable processes, so few really good ways for a company to systematically remember what any given thing is, how it works, why it works, what it does. code-bases are bits of the wild, collected from all over, so often from one or a couple of individual contributors who set forth on some expedition. even, yes, the juniors. hacking new tweaks, changes, sometimes it doesn't feel like big stuff, but to software engineer is to set out upon wild land, most every time. the sociology of this is fascinating to me, the dynamic is incredibly strong, incredibly asymmetric in how much responsibility is given to the developer, how wild the tasks are, & the difficulty & crudeness with which companies step up to re-integrate, take in, take responsibility for, manage the work that gets done.
francisofascii 6y ago
This may be an unpopular opinion, but I like how it is very objective, measurable, and somewhat specific. If I get fired and suddenly have my days free, I can simply study algorithms and leetcode and get a job elsewhere. It seems easier than worrying about everything else that could be asked during an interview.
- LordHumungous 6y ago
  I feel the same. It's also much more meritocratic. People from no-name schools and no-name companies study leetcode and get into FAANG all the time. Do people really think it would be better to base it on resume and YOE?
  - Philip-J-Fry 6y ago
    It's not an "either/or" choice... These companies treat it as though if you can't recite a leetcode answer line for line then you're no good. A software developer skillset is a lot more varied than reciting 5 leetcode answers for algorithms you won't ever use in production code 99% of the time. And that 1% of the time you do? You're just going to Google the algorithm again anyway. It's an almost pointless interview exercise.
    - LordHumungous 6y ago
      The interview is not just about leet code. There's also a behavioral loop and a system design loop, and both of those are extremely important as well. In fact most candidates vastly underestimate their importance. In my experience the leetcode questions were quite easy from an algorithm standpoint: string operations and traversals and things like that. You are judged not just on correctness but also your communication, requirements gathering, ability to catch edge cases and bugs, and general code quality. In other words, things that are absolutely relevant to the actual job.
    - francisofascii 6y ago
      Partially agree. But developers have to often create custom algorithms that are very specific to their business requirements, and these algorithms cannot be simply googled. I agree they would never write a "sort" algorithm, I suppose interviewers use these generic algorithms, rather than take the additional time needed to explain a real world, custom set of requirements.
codingdave 6y ago
> Maybe these things are meant to be a proxy for how good you are at other development task They are also a proxy for how hard you are willing to work to join them. I don't find that a useful metric as it implies a huge power imbalance in their minds... nevertheless, sometimes hiring processes make you jump through hoops just to prove that you are willing to do so.
sockgrant 6y ago
HN loves to hate FAANG interviews. There's always a monthly passion post about how flawed they are. I don't think it's unfair to say that Google and FB are considered to have strong engineering talent. So the interview process has to have _some_ hand in that success, even if it's also turning away some would-be strong performers. I'm not saying the interview process shouldn't be criticized or that it's beyond improvement. And, yeah, it's a little silly to go memorize a bunch of algorithms so you can recite them on the stop. Furthermore, so many interview questions are posted on leetcode... and there's so many more flaws to be pointed out, but in spite of that, they still manage to have a high engineering bar. But if you only read HN you'd think it's a total failure.
pvfffghhr 6y ago
On the other hand, learning algorithms is probably more fun than the actual work at Facebook.
orangepudding 6y ago
It's sad but yeah it's true that you have to prepare for interviews. The reality is that the breadth of topics that you have to have good knowledge on is larger than the scope of work you've probably been working on in your current job. I had work at a FANG before, but after a few years doing a startup, I had to go over and learn topics that I had no understanding on to get good offers again. I summarized what I felt were useful tactics for prepping system design interviews here (https://www.reddit.com/r/cscareerquestions/comments/kd13sx/sharing_the_system_design_framework_ive_used_that/ https://www.reddit.com/r/cscareerquestions/comments/kd13sx/s...) and a summary on a list of core topics I put together here (http://gum.co/sysdesign http://gum.co/sysdesign).
highspeedbus 6y ago
It's a game, some people are willing to play it.

by conorh 6y ago

gonzo41 6y ago

It is a proxy or how good you are at other development tasks. I think it's a bad proxy. Mostly because I've read and studied CLRS at school. And I don't use the fun parts much in the wild. I'm also not expected to be able to recall things that you can look up. One 'slightly' shameful things I noted about myself reading that list of system design interview questions is that I actually don't use most of those systems or know their features well enough. Other than YT of course. I feel like the simpler interview process would be to just take a person and do a hand wavy system design interview. Then if they pass, hire em on probation for 2 months and slam them with work. They get paid, you maybe get a feel for them. They sink or swim. You keep em' or toss em' away at the end of the two months.

wojciii 6y ago
Hmm.. this is how I got hired last year. I told the employer that I wanted to test them and to get me a short term project we could use to determine if company/me are a good match.
dntrkv 6y ago
That approach would work for a startup, but not when you’re hiring 100s of engineers on a weekly basis. Not to mention the amount of bias that approach will introduce. At least with the current approach, you know exactly what the criteria is to land the gig.

davidw 6y ago

I don't know that it's depressing, more that it's indicative of a culture I don't want anything to do with, which is fine with me. At least it's truth in advertising.

blisterpeanuts 6y ago

After 20 years in software, I had a phone interview with an Amazon guy who sounded half my age (at most). Asked me to write some kind of function to do something, sort some stuff or some such. I described verbally how I would do it, almost line by line, in pseudo-code. He said "I need you to write it out in [some language]". I said "But why? I just told you how I'd do it." But he needed me to literally write the code out, as though I couldn't easily copy-and-paste something for him. I thanked him and hung up. All I learned from that encounter is that I'd be very unhappy working with people like him. Bullet dodged. Sure, I use my knowledge of algorithms, and I frequently look such things up on StackOverflow and improve my knowledge; we all do. But these interviews seem designed to filter out experienced, pragmatic programmers and just bring in more cookie-cutter software engineering BS/MS recent grads who speak their language. A far cry from the startup environment that most of these companies began as!

mrits 6y ago
"But why?" Because most people can't. And they want to make sure you can.
- jrd259 6y ago
  We always allow the candidate to use any reasonable language. We're not testing if someone knows Java/Python/Lisp (I wish). We're testing if they know any language. I can confirm seeing people with resumes who nevertheless could not write any code even in the language they professed to be "expert" in.
  - jrib 6y ago
    Same. I learned through experience to ask for a candidate to write a couple of lines of code. Usually it's just some simple question that requires a single loop. We explicitly tell them they can use any language including one they want to make up as long as they are ok explaining how it works. When possible, I try to relate it to the conversation we've had up to that point. I've had someone start off by writing "four" on the board when prompted to write a "for" loop and get stuck. I'm still not sure if he was truly inexperienced or just trolling. The resume looked solid to me and he spoke well about his experience. I had almost decided to just skip the coding question as a result.

rektide 6y ago

I'm quite sympathetic. I think there's a huge domain of experiences that engineers bring with them. However, I also see some wisdom here. I still don't full agree with it, but I see some sense too. These are core skills for an undergraduate Computer Science degree. They represent the bulk of our abstract knowledge of how to compute well, how to think about & break down problems. Without proficiency here, a coder risks creating potentially dangerously inefficient solutions, that, at Facebook's scale, may well literally cost the company millions of dollars in server costs, or which could make the difference between a successful on-time positive-PR roll-out, & a failed highly-negative public-relations roll-out. That you can gain this knowledge in a couple of months is fairly remarkable in & of itself. Most engineering domains have a much broader swarth of core knowledge. Computer science literally has algorithms.

engineeringwoke 6y ago
> Without proficiency here, a coder risks creating potentially dangerously inefficient solutions, that, at Facebook's scale, may well literally cost the company millions of dollars in server costs, or which could make the difference between a successful on-time positive-PR roll-out, & a failed highly-negative public-relations roll-out. This is a common refrain, but juniors and mid-levels don't work on stuff like this at FAANG. If there's anything those guys are good at, it's making sure that you don't have too many cooks in the kitchen. Interviews like these don't find cooks, which is somewhat the point.
- rektide 6y ago
  my experience in the industry of coding has driven home to huge points: 1. that each individual & each team has an enormous amount of leeway & personal responsibility. teams are vested with what power they take & how far they & their environment let them. 2. complexity is everywhere & typically to work, to produce, is to add complexity & create new ways for things to go bad. indeed part of what is most notable about FAANG companies is that they have colossal staffs- & notably many of their senior engineer ranks- working to manage & reduce complexity, by inventing continuous integration/deploy systems, by devising trackers for cyclocmatic code & cyclomatic data-dependency/data-access-pattern complexity, by creating more resilient infrastructure & new ways to administrate systems. i fully agree that there is a huge opportunity cost. i think it's madness how focused & specific these interview courses are, what a set path they are on. but i also think it's been underspoken that learning algorithms & data-structures & less so systems are fairly core material to the industry, that these are basic truths that underpin every single thing we do. and i think the knowledge is acquireable and important. and i think just as much, it's unsaid, culturally, a lot of my first point: that individuals in this industry have enormous liberties, that they are sent off to incredible & weird tasks, to go drag something or other back to the company. notably, it's just so so so so hard for a company to take responsibility for "it's" code, to re-integrate, to handle, the new complexity that gets dragged in to base, by each individual contributor. there are so few repeatable processes, so few really good ways for a company to systematically remember what any given thing is, how it works, why it works, what it does. code-bases are bits of the wild, collected from all over, so often from one or a couple of individual contributors who set forth on some expedition. even, yes, the juniors. hacking new tweaks, changes, sometimes it doesn't feel like big stuff, but to software engineer is to set out upon wild land, most every time. the sociology of this is fascinating to me, the dynamic is incredibly strong, incredibly asymmetric in how much responsibility is given to the developer, how wild the tasks are, & the difficulty & crudeness with which companies step up to re-integrate, take in, take responsibility for, manage the work that gets done.

francisofascii 6y ago

This may be an unpopular opinion, but I like how it is very objective, measurable, and somewhat specific. If I get fired and suddenly have my days free, I can simply study algorithms and leetcode and get a job elsewhere. It seems easier than worrying about everything else that could be asked during an interview.

LordHumungous 6y ago
I feel the same. It's also much more meritocratic. People from no-name schools and no-name companies study leetcode and get into FAANG all the time. Do people really think it would be better to base it on resume and YOE?
- Philip-J-Fry 6y ago
  It's not an "either/or" choice... These companies treat it as though if you can't recite a leetcode answer line for line then you're no good. A software developer skillset is a lot more varied than reciting 5 leetcode answers for algorithms you won't ever use in production code 99% of the time. And that 1% of the time you do? You're just going to Google the algorithm again anyway. It's an almost pointless interview exercise.
  - LordHumungous 6y ago
    The interview is not just about leet code. There's also a behavioral loop and a system design loop, and both of those are extremely important as well. In fact most candidates vastly underestimate their importance. In my experience the leetcode questions were quite easy from an algorithm standpoint: string operations and traversals and things like that. You are judged not just on correctness but also your communication, requirements gathering, ability to catch edge cases and bugs, and general code quality. In other words, things that are absolutely relevant to the actual job.
  - francisofascii 6y ago
    Partially agree. But developers have to often create custom algorithms that are very specific to their business requirements, and these algorithms cannot be simply googled. I agree they would never write a "sort" algorithm, I suppose interviewers use these generic algorithms, rather than take the additional time needed to explain a real world, custom set of requirements.

codingdave 6y ago

> Maybe these things are meant to be a proxy for how good you are at other development task They are also a proxy for how hard you are willing to work to join them. I don't find that a useful metric as it implies a huge power imbalance in their minds... nevertheless, sometimes hiring processes make you jump through hoops just to prove that you are willing to do so.

sockgrant 6y ago

HN loves to hate FAANG interviews. There's always a monthly passion post about how flawed they are. I don't think it's unfair to say that Google and FB are considered to have strong engineering talent. So the interview process has to have _some_ hand in that success, even if it's also turning away some would-be strong performers. I'm not saying the interview process shouldn't be criticized or that it's beyond improvement. And, yeah, it's a little silly to go memorize a bunch of algorithms so you can recite them on the stop. Furthermore, so many interview questions are posted on leetcode... and there's so many more flaws to be pointed out, but in spite of that, they still manage to have a high engineering bar. But if you only read HN you'd think it's a total failure.

pvfffghhr 6y ago

On the other hand, learning algorithms is probably more fun than the actual work at Facebook.

orangepudding 6y ago

It's sad but yeah it's true that you have to prepare for interviews. The reality is that the breadth of topics that you have to have good knowledge on is larger than the scope of work you've probably been working on in your current job. I had work at a FANG before, but after a few years doing a startup, I had to go over and learn topics that I had no understanding on to get good offers again. I summarized what I felt were useful tactics for prepping system design interviews here (https://www.reddit.com/r/cscareerquestions/comments/kd13sx/sharing_the_system_design_framework_ive_used_that/ https://www.reddit.com/r/cscareerquestions/comments/kd13sx/s...) and a summary on a list of core topics I put together here (http://gum.co/sysdesign http://gum.co/sysdesign).

highspeedbus 6y ago

It's a game, some people are willing to play it.