9 ms·

Algorithms Interviews: Theory vs. Practice

265 points by jakevoytko 7y ago

Infinitesimus 7y ago
> Some companies will give very large out of band bonuses to people, but that work wasn't for a company that does a lot of that kind of thing, so there's nothing the company could do to indicate that it valued additional work once someone did "enough" work to get the best possible rating on a performance review. From a mechanism design point of view, the company was basically asking employees to stop working once they did "enough" work for the year. and > This also happened in another way. As is common at a lot of companies, managers were given a team-wide budget for raises that was mainly a function of headcount, that was then doled out to team members in a zero-sum way. Unfortunately for each team member (at least in terms of compensation), the team pretty much only had productive engineers, meaning that no one was going to do particularly well in the zero-sum raise game. The team had very low turnover because people like working with good co-workers, but the company was applying one the biggest levers it has, compensation, to try to get people to leave the team and join less effective teams are pretty important points to note. Accepting that organizations are incentivized to extract the maximum amount of value from you means you should be: 1. Aware of the value you produce 2. Know how to sell it This also comes up during promotion season in places that require that you perform at 50%+ of the next "level" to be eligible for a promotion. The unsaid part is that you will be under compensated for that 50% "next level" and when the promo comes, you'll be at the bottom of the comp band at the new level (no wonder people tend to quite shortly after a large promotion)
- mwcampbell 7y ago
  > Accepting that organizations are incentivized to extract the maximum amount of value from you means you should be: 1. Aware of the value you produce 2. Know how to sell it Do you think this is important even if one is already satisfied with one's compensation and mainly cares about the positive impact that they're making for end-users of the company's software?
  - Infinitesimus 7y ago
    If you are satisfied then it is not important. What matters in the end is that you're content/happy with where your life is and the trajectory you're on - whether that's making 200k a year or having enough time off at work so you can do other interesting stuff
  - barry-cotter 7y ago
    You are donating a lot of money to your employer’s shareholders if you knowingly work for below market rates. I hope you have an excellent work environment but even if you do you should interview at least yearly to see if there’s anything really attractive around. Other companies have end users too.
- amznthrowaway5 7y ago
  > This also comes up during promotion season in places that require that you perform at 50%+ of the next "level" to be eligible for a promotion. There is no objective criteria for the next “level”, despite the fact that corporations pretend otherwise. Level is more related to years of experience than actual skill from what I’ve observed. Working extremely hard for a promo and then being compensated far less than external hires who can barely code but managed to pass the leetcode interviews is a real morale killer. And that’s if you get lucky and get promoted instead of passed up for promo, since promos tend to be given for exaggerating impact “metrics” instead of actual total impact which is unmeasurable.
- closeparen 7y ago
  > to try to get people to leave the team and join less effective teams From a director-level perspective it probably makes sense to have one or two of your best people on each team, rather than some wholly excellent teams and some wholly mediocre teams.
  - crtlaltdel 7y ago
    From the standpoint of providing skill-mentorship opportunities it makes sense. A few strong engineers on a team can really help everyone grow. Naturally personalities and preferences should be accounted for, however one of the best moves I ever made was to break up a "ninja squad" (what they called themselves) of high functioning devs when their big project wrapped up. The squad was small (3) and each person was very well liked by the entire engineering team (13). We had several green-field projects starting up, so none of them felt banished to the salt mines of legacy maintenance tasks for instance. The general quality and velocity improved across the teams and we gained more consistency in our codebase when it came to patterns.
  - djcapelis 7y ago
    The IBM Black Team is a notable counterexample that argues clustering your top performers together pays extremely effective dividends.
- austincheney 7y ago
  > Accepting that organizations are incentivized to extract the maximum amount of value from you Perhaps that is true at start ups, but in my career as a developer at very large corporations this has been almost never true. Most of my career has been waiting around wasting time or working on side projects to do my job for me. That time waste is due to any of the following: * Unnecessary build jobs, such as a build job that takes 90 minutes. In that extreme example Java was the center-piece technology at a web travel company even though Java is not a web technology. As a front-end developer if I wanted to make a code change and test it in the browser I would need to rebuild and wait 90 minutes, because the front-end code that the Java developers don't care about is at the end of the funnel. No incentive to hurry and certainly no maximum value extraction. * When I was working as a strategy consultant to a different giant web travel company I was there because they sucked. Let's be honest, if they were awesome they wouldn't be spending huge bags of money on an outside consultant for advise. Because the most sucky developers there were supremely insecure and their management was at war with another department they didn't really want me to do work. I really tried to justify the money they were paying to my employer for my time there, but it was really just an exhaustive exercise in keeping busy so I wouldn't be bored all day. Eventually that faded away and I just started taking long walks out of the office. No value extraction there either. * A more common scenario I have experienced is death by process. Its like bleeding out from a thousand tiny paper cuts such that you are in agony forever, but there is no light at the end of the tunnel. I have reasoned this madness occurs because the organization lacks a qualified architect and the wrong personalities were put in charge of the technology decisions. In nearly all cases management looked around and said to themselves "who here mindlessly works themselves to death" and then that person gets put in charge and now everybody is working themselves to death but nothing is being produced. Nothing says working hard like running as fast as you can on a mouse wheel. In these cases there is need to be constantly in a hurry, but nothing gets done and everybody knows it and morale is destroyed. * The most common failure I encounter is fear of writing original code. As a front-end developer there are only 2 APIs on the front-end: DOM and the Web APIs. Instead of writing a fast performing solution in the fewest possible instructions you typically need to write the code to conform to a very specific, though not documented, code style on top of a giant monster framework with a 1000 dependencies. Then you need to compile the code more than once just for good measure. Even though the problem could be solved slowly in 30 minutes with an additional hour for testing in multiple applications/environments it will likely take a week or more in the framework. Sometimes people claim there is a great hurry to ship product changes, but as a developer working on a framework made out of toothpicks and duct tape the hurry is clearly somebody's self-serving imagination. * I think everybody's favorite value destroyer is death by JIRA. So, JIRA is an Agile planning and assignment tool that the corporate world has fallen in love with. When everything is a story point and nothing else matters your personal goal becomes completing story point assignments and then doing nothing else. Perhaps the only times I have ever experienced a big corporate employer making any attempt to extract the maximum amount of value from me is when work used the old waterfall methodology, because the work was constantly coming in without regard for schedule cycles or administrative nonsense. The time I was most most valued is when I was told to go as fast as possible as the A/B test engineer for Travelocity and all restrictions were on productivity, aside from Q/A and defect resolution, were eliminated. --- > 1. Aware of the value you produce 2. Know how to sell it I, and most people I have worked with, have spent so much time undervalued that we clearly had time to really and continuously sell ourselves like a product on a shelf, but nobody almost wants to. The people that spend the most energy selling themselves instead of writing code or solving problems tend to use charisma as for bad self-promotion. If developers wanted to spend the majority of their energy in marketing they wouldn't waste time solving hard technology problems. It reminds me of end of year evaluations that most developers dread.
kris-s 7y ago
> At one point, after getting a promotion and a raise, I computed the ratio of the amount of money my changes made the company vs. my raise and found that my raise was 0.03% of the money that I made the company, only counting easily quantifiable and totally indisuptable impact to the bottom line. Would profit/revenue sharing help with this?
- dehrmann 7y ago
  Except supply and demand drive your pay, not how much you make the company. Now, if you can't make the company at least as much as you cost, then you're out of a job. Those "I made the company X" arguments are only interesting if it was an action/idea that you were uniquely responsible for. If it's something most equally qualified people would have done in that role, it's not that interesting.
  - wolco 7y ago
    Not true. Making the company X amount or your out is thinking to linear. There are profit centres and profit eater departments. Keeping your job is more political than values based.
    - p1necone 7y ago
      The idea of a "profit eater" department makes no sense to me. Sure, your IT department or janitorial staff or whatever aren't being directly handed money by clients, but your business would not be able to run without them. Surely they're only a negative profit center by a very myopic, naive definition of the term?
      - chii 7y ago
        > your business would not be able to run without them. but can your business earn more if had more of them? If yes, then it's a profit center. If no, it's a "profit eater".
        7y ago
aphextron 7y ago
>"I’ve done maybe 40-ish "real" software interviews and passed maybe one or two of them" I'd say that about mirrors my experience as well. Is this really that common? Here I was thinking that I'm just an idiot.
- hyperpape 7y ago
  According to Dan, you're both outliers: https://twitter.com/danluu/status/1058029337923014656 https://twitter.com/danluu/status/1058029337923014656.
  - ScottFree 7y ago
    I wouldn't call 25% an outlier. Also, that's only people he knows. The numbers from interviewing.io (Aline Lerner) suggest that interview performance is arbitrary[0] and that engineers are bad at gauging their own interview performance[1]. The numbers suggest it's far more common than just 25%. [0]: http://blog.interviewing.io/after-a-lot-more-data-technical-interview-performance-really-is-kind-of-arbitrary/ http://blog.interviewing.io/after-a-lot-more-data-technical-... [1]: http://blog.alinelerner.com/people-cant-gauge-their-own-interview-performance-and-that-makes-them-harder-to-hire/ http://blog.alinelerner.com/people-cant-gauge-their-own-inte...
    - andreareina 7y ago
      > I'm one of four people I know of who fails interviews at a high enough rate that I could fail 20 in a row (and I believe I have). My reading of that is that out of all the people he knows, there are four that could plausibly "fail" 20 interviews in a row, not that 25% of (engineers?) he knows would do so.
  - aphextron 7y ago
    >"I'd never thought about it this way before (look at who gets rejected and see what they have in common), but I guess there's one thing interviews are pretty good at filtering for: people who are a certain type of nervous in interviews." Sounds about right. I can pass "take home quiz" style interviews at nearly 100%, but put me in front of a whiteboard and everything goes blank. Not sure why people insist on doing that.
jorblumesea 7y ago
I actually suspect that one of the main purposes of the algo based interview process is a motivation check. It takes time to prep for these interviews. Lots of time. So if you get a candidate that is crushing problems, it can either mean two things: 1) They are exceedingly brilliant and they can program decently 2) They have studied hard, they can reason and code decently Combine that with a system design portion and some behavioral questions, and the company is probably getting a solid hire. Does it mean that you're weeding out some false negatives? Absolutely. But large companies don't care. The system works well enough, and until it doesn't, I doubt much will change.
- amznthrowaway5 7y ago
  If that’s what companies wanted they could remove the extremely biased human component and give an SAT like IQ test loaded with algorithms and objective design questions. The interviews right now are extremely biased and you get rejected just because some interviewer has a biased opinion of you based on how you act.
- brendanw 7y ago
  I've wonder if this + optimizing for sticky labor while meeting legal requirements. A person who has contributed to impressive open source ticks both checkboxes but will not pass FANG interview.
- eikenberry 7y ago
  But it isn't working well as they are all starving for talent. When your problem is that you can't find enough people and your pipeline is designed to be a strong filter, you are just exasperating the problem and need to rework your pipeline. That is you see a lot of talk about this because "the system" isn't working. Some companies are trying new things, but you have to find them among all the ones who don't spend the time to try to find a better way.
- empath75 7y ago
  3) they just graduated from college and still remember all that stuff. It’s an age screen. People in their 40s don’t have time to prep for those kinds of questions. Nor do people with children who might need a work life balance.
dehrmann 7y ago
> The most widely read programming blogger around (Joel Spolsky) was telling people they need to adopt software practice X because Microsoft was doing it and they couldn't compete adopting the same practices. These days, it's amazing how much "We do X because Google does X" you see. But Google is the new circa 2003 M$, so it makes sense.
- gmiller123456 7y ago
  >"We do X because Google does X" My standard response was "The most distinguishing property of Microsoft (Google) is they have a monopoly, copy that part first".
gowld 7y ago
Opening statement: > When I ask people at trendy big tech companies why algorithms quizzes are mandatory, the most common answer I get is something like "we have so much scale, we can't afford to have someone accidentally write an O(n^2) algorithm and bring the site down" In 20yeara I've never heard someone say anything like that.
- wolco 7y ago
  If we are one query from bring down the site I don't want to be anywhere near that site.
  - vajrabum 7y ago
    After running postmortems at a couple of medium to large software enterprises for a while I'd say you'd likely find that it's a quite common although not everyday thing for a bad query to impact a significant number of users if not the whole site. I've seen this happen with people hand crafting queries, using ORMs, and with a NoSQL database (mongod). Most of the ones I remember were at least partly scale related. So maybe it doesn't happen so frequently if you don't have thousands of instances or more than hundreds of thousands to millions of users.
  - izacus 7y ago
    If you haven't had a single query bring down a service at least once, you just don't have enough industry experience with services. It's surprisingly easy to bring down complete complex services system with a unlucky degenerate case.
    - itronitron 7y ago
      Ctrl+A, then Ctrl+C, followed by Ctrl+V, then Enter...
    - sgerenser 7y ago
      Like A site wide outage at StackOverflow being caused by an inefficient backtracking regex engine: https://stackstatus.net/post/147710624694/outage-postmortem-july-20-2016 https://stackstatus.net/post/147710624694/outage-postmortem-...
fyp 7y ago
> a friend of mine once got a Google Code Jam World Finals question in a phone interview with Google (...) I doubt there were more than a few hundred people in the world who would've gotten the right answer to the question in a phone screen and almost all of them probably would've realized that it was an absurd phone screen question Link to the question: https://code.google.com/codejam/contest/2437491/dashboard#s=p2 https://code.google.com/codejam/contest/2437491/dashboard#s=... The gist of it is: You are given 4*N points on a 2D plane. Can you draw two perpendicular lines to separate them into N points per quadrant? I think Dan's missing context is that google code jam questions always have a small and large dataset. In this case, small is N=10 which makes a lot of bruteforce solutions possible and not much different from any other bruteforce puzzles common in interviews. Being a geometry question is the more unfair part if this is a generalist role (but not unfair if your role involves graphics, computer vision, self driving car mapping, etc). Expecting a solution for the large (N=2500) is ridiculous of course. See analysis: https://code.google.com/codejam/contest/2437491/dashboard#s=a&a=2 https://code.google.com/codejam/contest/2437491/dashboard#s=...
- chillee 7y ago
  Another piece of contextual information that's important is that interviewers can provide hints during an interview. For example, I was asked this question once: Given N points and 3 squares of side length L, what's the minimum L that allows you to cover all N points with the 3 squares? I think this question is fairly unreasonable as an interview question, if you weren't given hints. In the context of an interview, however, I think it could be reasonable.
  - majke 7y ago
    A similar situation happened to me, and the problem was not hints. I just wasn't happy with that particular problem because I knew how much time it took me the last day, when preparing, to solve it! I was really not into doing it again, it was so traumatic. The correct curse of action is for the interviewer to anticipate this and prepare a backup question.
christiansakai 7y ago
Its hard to believe that Dan Luu can’t pass algorithm interviews.
- TrackerFF 7y ago
  It has a lot to do with psyche. If you have anxiety, it is entirely possible to even fail the most basic questions. And unfortunately, you can't just say "Sorry, I'm having a panic attack. Could we do this tomorrow?". I think the best course is anxiety management. But unfortunately, some people get dependent on drugs just to calm their nerves before something important. I know people that can't hold meetings or presentations without taking beta-blockers and the likes.
  - erik_seaberg 7y ago
    Do those people find jobs that never require going on call?
  - wesleyac 7y ago
    Just FYI - in many interviews, you can just say "Sorry, I'm having a panic attack. Could we do this tomorrow?". One of my friends had a panic attack during her Google interview, left came back the next day, and got the job. So, YMMV, but people are often able to be accommodating for things like this :)
  - ddsea 7y ago
    And then tomorrow you'd feel double the pressure - because you cannot do it again.
Ozzie_osman 7y ago
> When I ask people at trendy big tech companies why algorithms quizzes are mandatory, the most common answer I get is something like "we have so much scale, we can't afford to have someone accidentally write an O(n^2) algorithm and bring the site down". I think people who say this just don't get what's really going on here. If you look at these types of interviews, a big part of what they select for is: 1) Some sort of problem-solving skill that's a mix of raw intelligence and/or ability to solve problems by pattern-matching to things you've seen before. 2) Ability/commitment to work on something that may not be that intrinsically motivating, in the context of getting/maintaining a certain type of job. These interviews select exactly for that. To pass, you usually have some mix of: - raw intelligence. - ability to pattern match to similar problems you've seen before. - ability and motivation to spend time preparing for these types of interviews, even if they're not really what you care about doing. That's really what they're trying to capture. It's not a perfect filter (you will still have some false positives and plenty, plenty of false negatives), but it works "well enough". You really only need one Dan Luu per like 10 or 100 engineers at a FAANG. Most people aren't going to be optimizing at the level he is, they're going to be doing work that's mostly a mix of problem-solving by pattern matching, and ideally, they're motivated enough to have that job for as long as possible.
- codingslave 7y ago
  This exactly. But I also think that what happens is once people get inside Google or FB, there's a second level of filtering to actually get put on good projects. Most of the engineers they have just need to do what theyre told. A few get picked to help write the next generation computing platform, distributed deep learning, etc.
- decebalus1 7y ago
  > Ability/commitment to work on something that may not be that intrinsically motivating, in the context of getting/maintaining a certain type of job. I remember a blog post which was ranting about the current culture at trendy big tech companies (has since been deleted [0], probably the author still wanted a career at such a company) in which a quote resonated with me a lot: 'we're not problem solvers, we're problem endurers'. Someone solving hundreds of leetcode problems to prepare for an interview just signaled that they are willing do do basically any tedious piece of work you throw at them. EDIT: [0] Found it: https://web.archive.org/web/20160308032127/https://medium.com/@bryanedds/living-in-the-age-of-software-fuckery-8859f81ca877 https://web.archive.org/web/20160308032127/https://medium.co...
yibg 7y ago
This topic comes up pretty often, and I think most people agree algorithm interview questions aren’t effective and screen for the wrong things. The question though is, what is a better way to interview? I don’t think I’ve seen any consensus, let alone anything backed by data yet.
- sdnlafkjh34rw 7y ago
  You could ask coding questions that are not algorithms? Realistic problems that are commonly found in web work.
boulos 7y ago
So, amusingly, my referral hit rate at Google is like 1/10. Worse, I only refer people if they've told me that they're certain they wish to go through the terrible process. When I say 1/10, I don't mean 10%, I mean I have entered about 10, and only one got an offer. In my opinion, all were qualified and should have been given offers. For comparison, I've done roughly 100 interviews or something (though not nearly enough SWE interviews, because I'm in San Francisco). As an additional upwards bias, I actively discourage people from applying, so this is only the folks that said "I understand, refer me anyway". All that said, Google is really more like dozens of independent companies now. There's Search/Ads, YouTube, Cloud, Photos, Android, Maps/"Geo", and so on. Your mileage will vary pretty drastically depending on how you're routed. Just like Dan was misdirected towards a software interview, I've had friends tossed into the SRE hiring pipeline, asked how to operate large-scale distributed systems and so on, when their background is "Umm, I just did my PhD in CS in Graphics... I've never written a networked program in my life". To all the other Google employees: find the job posting internally that your friends would actually want, talk to the hiring manager to figure out what that maps to externally on the job postings page (it often doesn't), and then tell the assigned recruiter that you're serious about your recommendation. The recruiter may still override you in deference to their hiring targets / goals though (the one offer I've seen from my referral went this way despite my effort), so don't promise your friends that you can fix it for them. I'm not here to excuse these hiring practices. Instead, be honest with yourself about why you want to apply, and how much hassle you're willing to put up with. In my experience, all other companies will decide more quickly on your hiring result, role, level, compensation and so on. I believe that's because of the scale of the interviewing and hiring (>10k full-time employees per year for the last few years), except it's always been pretty bad at Google.
- Google234 7y ago
  lol, it's actually much worse than that.
fakename11 7y ago
Eh, a lot work at Google is pretty heavy on algorithms. It's important to know how to write high performance code and algorithms and data structures knowledge is a large part in that.
insighter 7y ago
Does anyone have articles or advice/experience to share on improving a company's interviewing process / culture? I work at a medium/large enterprise software company in SFBA that's well compensated (not quite FAANG level) and sometimes a final round interview will have 5 algorithm style whiteboarding questions which feels excessive and lazy. I'm interested in: a) standardization. Right now interviewers pick their individual questions and sometimes the question types. You can't apply a wildly inconsistent measure across anything and expect to have confidence in your findings. b) interview question diversity. If people have varying strengths and our day to day work goes beyond just solving algorithm style questions (because it does for a huge majority of dev jobs) then a more diverse body of questions seems to be a better yardstick to measure others by. Examples of questions types that seem interesting to add include refactoring existing code, pair programming, small coding project and even weird things I haven't heard of before like the ability to give constructive feedback on design proposals, etc..

265 points by jakevoytko 7y ago

> Some companies will give very large out of band bonuses to people, but that work wasn't for a company that does a lot of that kind of thing, so there's nothing the company could do to indicate that it valued additional work once someone did "enough" work to get the best possible rating on a performance review. From a mechanism design point of view, the company was basically asking employees to stop working once they did "enough" work for the year. and > This also happened in another way. As is common at a lot of companies, managers were given a team-wide budget for raises that was mainly a function of headcount, that was then doled out to team members in a zero-sum way. Unfortunately for each team member (at least in terms of compensation), the team pretty much only had productive engineers, meaning that no one was going to do particularly well in the zero-sum raise game. The team had very low turnover because people like working with good co-workers, but the company was applying one the biggest levers it has, compensation, to try to get people to leave the team and join less effective teams are pretty important points to note. Accepting that organizations are incentivized to extract the maximum amount of value from you means you should be: 1. Aware of the value you produce 2. Know how to sell it This also comes up during promotion season in places that require that you perform at 50%+ of the next "level" to be eligible for a promotion. The unsaid part is that you will be under compensated for that 50% "next level" and when the promo comes, you'll be at the bottom of the comp band at the new level (no wonder people tend to quite shortly after a large promotion)

mwcampbell 7y ago
> Accepting that organizations are incentivized to extract the maximum amount of value from you means you should be: 1. Aware of the value you produce 2. Know how to sell it Do you think this is important even if one is already satisfied with one's compensation and mainly cares about the positive impact that they're making for end-users of the company's software?
- Infinitesimus 7y ago
  If you are satisfied then it is not important. What matters in the end is that you're content/happy with where your life is and the trajectory you're on - whether that's making 200k a year or having enough time off at work so you can do other interesting stuff
- barry-cotter 7y ago
  You are donating a lot of money to your employer’s shareholders if you knowingly work for below market rates. I hope you have an excellent work environment but even if you do you should interview at least yearly to see if there’s anything really attractive around. Other companies have end users too.
amznthrowaway5 7y ago
> This also comes up during promotion season in places that require that you perform at 50%+ of the next "level" to be eligible for a promotion. There is no objective criteria for the next “level”, despite the fact that corporations pretend otherwise. Level is more related to years of experience than actual skill from what I’ve observed. Working extremely hard for a promo and then being compensated far less than external hires who can barely code but managed to pass the leetcode interviews is a real morale killer. And that’s if you get lucky and get promoted instead of passed up for promo, since promos tend to be given for exaggerating impact “metrics” instead of actual total impact which is unmeasurable.
closeparen 7y ago
> to try to get people to leave the team and join less effective teams From a director-level perspective it probably makes sense to have one or two of your best people on each team, rather than some wholly excellent teams and some wholly mediocre teams.
- crtlaltdel 7y ago
  From the standpoint of providing skill-mentorship opportunities it makes sense. A few strong engineers on a team can really help everyone grow. Naturally personalities and preferences should be accounted for, however one of the best moves I ever made was to break up a "ninja squad" (what they called themselves) of high functioning devs when their big project wrapped up. The squad was small (3) and each person was very well liked by the entire engineering team (13). We had several green-field projects starting up, so none of them felt banished to the salt mines of legacy maintenance tasks for instance. The general quality and velocity improved across the teams and we gained more consistency in our codebase when it came to patterns.
- djcapelis 7y ago
  The IBM Black Team is a notable counterexample that argues clustering your top performers together pays extremely effective dividends.
austincheney 7y ago
> Accepting that organizations are incentivized to extract the maximum amount of value from you Perhaps that is true at start ups, but in my career as a developer at very large corporations this has been almost never true. Most of my career has been waiting around wasting time or working on side projects to do my job for me. That time waste is due to any of the following: * Unnecessary build jobs, such as a build job that takes 90 minutes. In that extreme example Java was the center-piece technology at a web travel company even though Java is not a web technology. As a front-end developer if I wanted to make a code change and test it in the browser I would need to rebuild and wait 90 minutes, because the front-end code that the Java developers don't care about is at the end of the funnel. No incentive to hurry and certainly no maximum value extraction. * When I was working as a strategy consultant to a different giant web travel company I was there because they sucked. Let's be honest, if they were awesome they wouldn't be spending huge bags of money on an outside consultant for advise. Because the most sucky developers there were supremely insecure and their management was at war with another department they didn't really want me to do work. I really tried to justify the money they were paying to my employer for my time there, but it was really just an exhaustive exercise in keeping busy so I wouldn't be bored all day. Eventually that faded away and I just started taking long walks out of the office. No value extraction there either. * A more common scenario I have experienced is death by process. Its like bleeding out from a thousand tiny paper cuts such that you are in agony forever, but there is no light at the end of the tunnel. I have reasoned this madness occurs because the organization lacks a qualified architect and the wrong personalities were put in charge of the technology decisions. In nearly all cases management looked around and said to themselves "who here mindlessly works themselves to death" and then that person gets put in charge and now everybody is working themselves to death but nothing is being produced. Nothing says working hard like running as fast as you can on a mouse wheel. In these cases there is need to be constantly in a hurry, but nothing gets done and everybody knows it and morale is destroyed. * The most common failure I encounter is fear of writing original code. As a front-end developer there are only 2 APIs on the front-end: DOM and the Web APIs. Instead of writing a fast performing solution in the fewest possible instructions you typically need to write the code to conform to a very specific, though not documented, code style on top of a giant monster framework with a 1000 dependencies. Then you need to compile the code more than once just for good measure. Even though the problem could be solved slowly in 30 minutes with an additional hour for testing in multiple applications/environments it will likely take a week or more in the framework. Sometimes people claim there is a great hurry to ship product changes, but as a developer working on a framework made out of toothpicks and duct tape the hurry is clearly somebody's self-serving imagination. * I think everybody's favorite value destroyer is death by JIRA. So, JIRA is an Agile planning and assignment tool that the corporate world has fallen in love with. When everything is a story point and nothing else matters your personal goal becomes completing story point assignments and then doing nothing else. Perhaps the only times I have ever experienced a big corporate employer making any attempt to extract the maximum amount of value from me is when work used the old waterfall methodology, because the work was constantly coming in without regard for schedule cycles or administrative nonsense. The time I was most most valued is when I was told to go as fast as possible as the A/B test engineer for Travelocity and all restrictions were on productivity, aside from Q/A and defect resolution, were eliminated. --- > 1. Aware of the value you produce 2. Know how to sell it I, and most people I have worked with, have spent so much time undervalued that we clearly had time to really and continuously sell ourselves like a product on a shelf, but nobody almost wants to. The people that spend the most energy selling themselves instead of writing code or solving problems tend to use charisma as for bad self-promotion. If developers wanted to spend the majority of their energy in marketing they wouldn't waste time solving hard technology problems. It reminds me of end of year evaluations that most developers dread.

kris-s 7y ago

> At one point, after getting a promotion and a raise, I computed the ratio of the amount of money my changes made the company vs. my raise and found that my raise was 0.03% of the money that I made the company, only counting easily quantifiable and totally indisuptable impact to the bottom line. Would profit/revenue sharing help with this?

dehrmann 7y ago
Except supply and demand drive your pay, not how much you make the company. Now, if you can't make the company at least as much as you cost, then you're out of a job. Those "I made the company X" arguments are only interesting if it was an action/idea that you were uniquely responsible for. If it's something most equally qualified people would have done in that role, it's not that interesting.
- wolco 7y ago
  Not true. Making the company X amount or your out is thinking to linear. There are profit centres and profit eater departments. Keeping your job is more political than values based.
  - p1necone 7y ago
    The idea of a "profit eater" department makes no sense to me. Sure, your IT department or janitorial staff or whatever aren't being directly handed money by clients, but your business would not be able to run without them. Surely they're only a negative profit center by a very myopic, naive definition of the term?
    - chii 7y ago
      > your business would not be able to run without them. but can your business earn more if had more of them? If yes, then it's a profit center. If no, it's a "profit eater".
      - 7y ago

aphextron 7y ago

>"I’ve done maybe 40-ish "real" software interviews and passed maybe one or two of them" I'd say that about mirrors my experience as well. Is this really that common? Here I was thinking that I'm just an idiot.

hyperpape 7y ago
According to Dan, you're both outliers: https://twitter.com/danluu/status/1058029337923014656 https://twitter.com/danluu/status/1058029337923014656.
- ScottFree 7y ago
  I wouldn't call 25% an outlier. Also, that's only people he knows. The numbers from interviewing.io (Aline Lerner) suggest that interview performance is arbitrary[0] and that engineers are bad at gauging their own interview performance[1]. The numbers suggest it's far more common than just 25%. [0]: http://blog.interviewing.io/after-a-lot-more-data-technical-interview-performance-really-is-kind-of-arbitrary/ http://blog.interviewing.io/after-a-lot-more-data-technical-... [1]: http://blog.alinelerner.com/people-cant-gauge-their-own-interview-performance-and-that-makes-them-harder-to-hire/ http://blog.alinelerner.com/people-cant-gauge-their-own-inte...
  - andreareina 7y ago
    > I'm one of four people I know of who fails interviews at a high enough rate that I could fail 20 in a row (and I believe I have). My reading of that is that out of all the people he knows, there are four that could plausibly "fail" 20 interviews in a row, not that 25% of (engineers?) he knows would do so.
- aphextron 7y ago
  >"I'd never thought about it this way before (look at who gets rejected and see what they have in common), but I guess there's one thing interviews are pretty good at filtering for: people who are a certain type of nervous in interviews." Sounds about right. I can pass "take home quiz" style interviews at nearly 100%, but put me in front of a whiteboard and everything goes blank. Not sure why people insist on doing that.

jorblumesea 7y ago

I actually suspect that one of the main purposes of the algo based interview process is a motivation check. It takes time to prep for these interviews. Lots of time. So if you get a candidate that is crushing problems, it can either mean two things: 1) They are exceedingly brilliant and they can program decently 2) They have studied hard, they can reason and code decently Combine that with a system design portion and some behavioral questions, and the company is probably getting a solid hire. Does it mean that you're weeding out some false negatives? Absolutely. But large companies don't care. The system works well enough, and until it doesn't, I doubt much will change.

amznthrowaway5 7y ago
If that’s what companies wanted they could remove the extremely biased human component and give an SAT like IQ test loaded with algorithms and objective design questions. The interviews right now are extremely biased and you get rejected just because some interviewer has a biased opinion of you based on how you act.
brendanw 7y ago
I've wonder if this + optimizing for sticky labor while meeting legal requirements. A person who has contributed to impressive open source ticks both checkboxes but will not pass FANG interview.
eikenberry 7y ago
But it isn't working well as they are all starving for talent. When your problem is that you can't find enough people and your pipeline is designed to be a strong filter, you are just exasperating the problem and need to rework your pipeline. That is you see a lot of talk about this because "the system" isn't working. Some companies are trying new things, but you have to find them among all the ones who don't spend the time to try to find a better way.
empath75 7y ago
3) they just graduated from college and still remember all that stuff. It’s an age screen. People in their 40s don’t have time to prep for those kinds of questions. Nor do people with children who might need a work life balance.

dehrmann 7y ago

> The most widely read programming blogger around (Joel Spolsky) was telling people they need to adopt software practice X because Microsoft was doing it and they couldn't compete adopting the same practices. These days, it's amazing how much "We do X because Google does X" you see. But Google is the new circa 2003 M$, so it makes sense.

gmiller123456 7y ago
>"We do X because Google does X" My standard response was "The most distinguishing property of Microsoft (Google) is they have a monopoly, copy that part first".

gowld 7y ago

Opening statement: > When I ask people at trendy big tech companies why algorithms quizzes are mandatory, the most common answer I get is something like "we have so much scale, we can't afford to have someone accidentally write an O(n^2) algorithm and bring the site down" In 20yeara I've never heard someone say anything like that.

wolco 7y ago
If we are one query from bring down the site I don't want to be anywhere near that site.
- vajrabum 7y ago
  After running postmortems at a couple of medium to large software enterprises for a while I'd say you'd likely find that it's a quite common although not everyday thing for a bad query to impact a significant number of users if not the whole site. I've seen this happen with people hand crafting queries, using ORMs, and with a NoSQL database (mongod). Most of the ones I remember were at least partly scale related. So maybe it doesn't happen so frequently if you don't have thousands of instances or more than hundreds of thousands to millions of users.
- izacus 7y ago
  If you haven't had a single query bring down a service at least once, you just don't have enough industry experience with services. It's surprisingly easy to bring down complete complex services system with a unlucky degenerate case.
  - itronitron 7y ago
    Ctrl+A, then Ctrl+C, followed by Ctrl+V, then Enter...
  - sgerenser 7y ago
    Like A site wide outage at StackOverflow being caused by an inefficient backtracking regex engine: https://stackstatus.net/post/147710624694/outage-postmortem-july-20-2016 https://stackstatus.net/post/147710624694/outage-postmortem-...

fyp 7y ago

> a friend of mine once got a Google Code Jam World Finals question in a phone interview with Google (...) I doubt there were more than a few hundred people in the world who would've gotten the right answer to the question in a phone screen and almost all of them probably would've realized that it was an absurd phone screen question Link to the question: https://code.google.com/codejam/contest/2437491/dashboard#s=p2 https://code.google.com/codejam/contest/2437491/dashboard#s=... The gist of it is: You are given 4*N points on a 2D plane. Can you draw two perpendicular lines to separate them into N points per quadrant? I think Dan's missing context is that google code jam questions always have a small and large dataset. In this case, small is N=10 which makes a lot of bruteforce solutions possible and not much different from any other bruteforce puzzles common in interviews. Being a geometry question is the more unfair part if this is a generalist role (but not unfair if your role involves graphics, computer vision, self driving car mapping, etc). Expecting a solution for the large (N=2500) is ridiculous of course. See analysis: https://code.google.com/codejam/contest/2437491/dashboard#s=a&a=2 https://code.google.com/codejam/contest/2437491/dashboard#s=...

chillee 7y ago
Another piece of contextual information that's important is that interviewers can provide hints during an interview. For example, I was asked this question once: Given N points and 3 squares of side length L, what's the minimum L that allows you to cover all N points with the 3 squares? I think this question is fairly unreasonable as an interview question, if you weren't given hints. In the context of an interview, however, I think it could be reasonable.
- majke 7y ago
  A similar situation happened to me, and the problem was not hints. I just wasn't happy with that particular problem because I knew how much time it took me the last day, when preparing, to solve it! I was really not into doing it again, it was so traumatic. The correct curse of action is for the interviewer to anticipate this and prepare a backup question.

christiansakai 7y ago

Its hard to believe that Dan Luu can’t pass algorithm interviews.

TrackerFF 7y ago
It has a lot to do with psyche. If you have anxiety, it is entirely possible to even fail the most basic questions. And unfortunately, you can't just say "Sorry, I'm having a panic attack. Could we do this tomorrow?". I think the best course is anxiety management. But unfortunately, some people get dependent on drugs just to calm their nerves before something important. I know people that can't hold meetings or presentations without taking beta-blockers and the likes.
- erik_seaberg 7y ago
  Do those people find jobs that never require going on call?
- wesleyac 7y ago
  Just FYI - in many interviews, you can just say "Sorry, I'm having a panic attack. Could we do this tomorrow?". One of my friends had a panic attack during her Google interview, left came back the next day, and got the job. So, YMMV, but people are often able to be accommodating for things like this :)
- ddsea 7y ago
  And then tomorrow you'd feel double the pressure - because you cannot do it again.

Ozzie_osman 7y ago

> When I ask people at trendy big tech companies why algorithms quizzes are mandatory, the most common answer I get is something like "we have so much scale, we can't afford to have someone accidentally write an O(n^2) algorithm and bring the site down". I think people who say this just don't get what's really going on here. If you look at these types of interviews, a big part of what they select for is: 1) Some sort of problem-solving skill that's a mix of raw intelligence and/or ability to solve problems by pattern-matching to things you've seen before. 2) Ability/commitment to work on something that may not be that intrinsically motivating, in the context of getting/maintaining a certain type of job. These interviews select exactly for that. To pass, you usually have some mix of: - raw intelligence. - ability to pattern match to similar problems you've seen before. - ability and motivation to spend time preparing for these types of interviews, even if they're not really what you care about doing. That's really what they're trying to capture. It's not a perfect filter (you will still have some false positives and plenty, plenty of false negatives), but it works "well enough". You really only need one Dan Luu per like 10 or 100 engineers at a FAANG. Most people aren't going to be optimizing at the level he is, they're going to be doing work that's mostly a mix of problem-solving by pattern matching, and ideally, they're motivated enough to have that job for as long as possible.

codingslave 7y ago
This exactly. But I also think that what happens is once people get inside Google or FB, there's a second level of filtering to actually get put on good projects. Most of the engineers they have just need to do what theyre told. A few get picked to help write the next generation computing platform, distributed deep learning, etc.
decebalus1 7y ago
> Ability/commitment to work on something that may not be that intrinsically motivating, in the context of getting/maintaining a certain type of job. I remember a blog post which was ranting about the current culture at trendy big tech companies (has since been deleted [0], probably the author still wanted a career at such a company) in which a quote resonated with me a lot: 'we're not problem solvers, we're problem endurers'. Someone solving hundreds of leetcode problems to prepare for an interview just signaled that they are willing do do basically any tedious piece of work you throw at them. EDIT: [0] Found it: https://web.archive.org/web/20160308032127/https://medium.com/@bryanedds/living-in-the-age-of-software-fuckery-8859f81ca877 https://web.archive.org/web/20160308032127/https://medium.co...

yibg 7y ago

This topic comes up pretty often, and I think most people agree algorithm interview questions aren’t effective and screen for the wrong things. The question though is, what is a better way to interview? I don’t think I’ve seen any consensus, let alone anything backed by data yet.

sdnlafkjh34rw 7y ago
You could ask coding questions that are not algorithms? Realistic problems that are commonly found in web work.

boulos 7y ago

So, amusingly, my referral hit rate at Google is like 1/10. Worse, I only refer people if they've told me that they're certain they wish to go through the terrible process. When I say 1/10, I don't mean 10%, I mean I have entered about 10, and only one got an offer. In my opinion, all were qualified and should have been given offers. For comparison, I've done roughly 100 interviews or something (though not nearly enough SWE interviews, because I'm in San Francisco). As an additional upwards bias, I actively discourage people from applying, so this is only the folks that said "I understand, refer me anyway". All that said, Google is really more like dozens of independent companies now. There's Search/Ads, YouTube, Cloud, Photos, Android, Maps/"Geo", and so on. Your mileage will vary pretty drastically depending on how you're routed. Just like Dan was misdirected towards a software interview, I've had friends tossed into the SRE hiring pipeline, asked how to operate large-scale distributed systems and so on, when their background is "Umm, I just did my PhD in CS in Graphics... I've never written a networked program in my life". To all the other Google employees: find the job posting internally that your friends would actually want, talk to the hiring manager to figure out what that maps to externally on the job postings page (it often doesn't), and then tell the assigned recruiter that you're serious about your recommendation. The recruiter may still override you in deference to their hiring targets / goals though (the one offer I've seen from my referral went this way despite my effort), so don't promise your friends that you can fix it for them. I'm not here to excuse these hiring practices. Instead, be honest with yourself about why you want to apply, and how much hassle you're willing to put up with. In my experience, all other companies will decide more quickly on your hiring result, role, level, compensation and so on. I believe that's because of the scale of the interviewing and hiring (>10k full-time employees per year for the last few years), except it's always been pretty bad at Google.

Google234 7y ago
lol, it's actually much worse than that.

fakename11 7y ago

Eh, a lot work at Google is pretty heavy on algorithms. It's important to know how to write high performance code and algorithms and data structures knowledge is a large part in that.

insighter 7y ago

Does anyone have articles or advice/experience to share on improving a company's interviewing process / culture? I work at a medium/large enterprise software company in SFBA that's well compensated (not quite FAANG level) and sometimes a final round interview will have 5 algorithm style whiteboarding questions which feels excessive and lazy. I'm interested in: a) standardization. Right now interviewers pick their individual questions and sometimes the question types. You can't apply a wildly inconsistent measure across anything and expect to have confidence in your findings. b) interview question diversity. If people have varying strengths and our day to day work goes beyond just solving algorithm style questions (because it does for a huge majority of dev jobs) then a more diverse body of questions seems to be a better yardstick to measure others by. Examples of questions types that seem interesting to add include refactoring existing code, pair programming, small coding project and even weird things I haven't heard of before like the ability to give constructive feedback on design proposals, etc..