4 ms·

I applied for a job at Microsoft recently. I had to take an online test which consisted of two medium and one hard leetcode problems. In one hour. It took near

I applied for a job at Microsoft recently. I had to take an online test which consisted of two medium and one hard leetcode problems. In one hour. It took nearly 15 minutes to just read the problems and make a game plan. That left 15 minutes solve and code all of them up. Have you ever done a hard leetcode problem? In 15 minutes? If that’s the bar at Microsoft, I doubt their developers are computer science illiterate. That test was harder than any of the other FAANG tests I’ve done, online or in person. Clearly the icon code was delegated to some intern or perhaps a child of one of the developers, because the bar is stupid high there just to have a conversation with a hiring manager. And they don’t even pay that well.

baobabKoodaa 6y ago
> Have you ever done a hard leetcode problem? Yes. I used to compete on CodeForces regularly. > Clearly the icon code was delegated to some intern or perhaps a child of one of the developers, because the bar is stupid high there just to have a conversation with a hiring manager. You're implying that the developers of Microsoft can't be computer science illiterate, because a computer science illiterate couldn't possibly pass through the recruitment funnel that you experienced. But we know this code exists. Somebody wrote it. Somebody reviewed it. Somebody tested it. Everybody involved in this process thought "yeah, this is good enough", when it's clearly not good enough. Anyone with as little as CS101 experience would not write crap like this in the first place, so it's really hard to argue that the developers at Microsoft are computer science literate.
- fingerlocks 6y ago
  The code was likely written in the early 90s when the barrier to entry was much lower. It was a time when thousands of icons on your desktop wasn’t a use case worth considering, much less testable. That seems more plausible than all the developers being illiterate.
  - baobabKoodaa 6y ago
    > The code was likely written in the early 90s when the barrier to entry was much lower. You're probably right about that. > That seems more plausible than all the developers being illiterate. I'm not saying all developers are CS illiterate, but most are.
  - alisonkisk 6y ago
    That's not true at all. Many many people save everything they touch to Desktop, so it builds up cruft over time. There are ancient jokes about it. And computers were slower then brute-forcing big-O complexity was less feasible. And the "barrier to entry" gets lower as an org gross and needs to higher thousands of people and get less picky. I'm sure that MS doesn't require people to ace the hard leetcode problem to get an offer. It's just there to provide a broad picture of algorithm memory and coding speed (which is a stupid metric, not a "high" metric).
  - rasz 6y ago
    >The code was likely written in the early 90s This is easily falsifiable by running a test case (create 1000 icons on desktop) in windows 7, 2000, XP and 98.
MontyCarloHall 6y ago
That interview process doesn’t just select for people who truly understand algorithms at a fundamental level. It also admits people who are good at memorizing the solutions to hundreds of leetcode-style problems. It is likely better at selecting more of the latter than the former. When I ask algo questions during interviews they’re always based on real problems that have arisen in our code. Making the question actually relevant to the job is both a better interview process overall and has the added benefit of instantly filtering out the memorizers.
haddr 6y ago
It is of course good that MS has a interview process that favors really smart people. But it doesn't mean that automatically all the work at MS will be flawless. There is much more then that. And people are even joking recently about this: https://i.redd.it/jhr5tv5ls2e61.jpg https://i.redd.it/jhr5tv5ls2e61.jpg
jerf 6y ago
Being good at "leetcode" problems and being good at writing good production algorithms certainly have some overlap... but it's not very large, and they're actively at odds with each other quite often.
- baobabKoodaa 6y ago
  > Being good at "leetcode" problems and being good at writing good production algorithms certainly have some overlap... but it's not very large, and they're actively at odds with each other quite often. Except in this particular example, where someone managed to write a quadratic algorithm for arranging icons.
  - jerf 6y ago
    It's the leetcoder who would have written the O(n^2) algorithm and figured it's OK because it passes all the cases thrown at it. A leetcoder doesn't optimize everything, just the thing for the problem they're facing today. It's the person used to writing production code who would have stopped to think about the fact that the cases we tested with today may not be representative of the entire problem space. Leetcode is throwaway code. Writing tons and tons of throwaway code is, like I said, not completely unrelated to writing good production code. To get good at coding, as with anything, it is necessary but not sufficient to code a lot. But this is the sort of thing that I'd expect a leetcoder to do in practice; to miss the real problems, probably because they were off hyperoptimizing something else that was irrelevant.
    - baobabKoodaa 6y ago
      I don't understand why you're trying to make this argument. You said: > being good at writing good production algorithms certainly have some overlap... but it's not very large I agreed with you, and noted that this specific case is an exception: > Except in this particular example, where someone managed to write a quadratic algorithm for arranging icons. It seems to me like you're trying to take the most extreme position that's available in this discussion: you're trying to claim that being good at optimizing algorithmic time complexity ("good at leetcode") does not help someone at optimizing algorithmic time complexity in production, because there's some kind of mythical distinction between "throwaway code" and "production code". That distinction is not relevant here. Someone who is good at optimizing algorithmic time complexity in throwaway code is certainly good at optimizing algorithmic time complexity in production code. Just like someone who is good at riding horses is also good at riding horses on a sunny day. Or someone who is good at painting with acrylic is also good at painting with watercolors, if you compare to another person who doesn't have any experience painting.
scottlamb 6y ago
Check out some of Dan Luu's writing. https://danluu.com/algorithms-interviews/ https://danluu.com/algorithms-interviews/ comes to mind: > At the start of this post, we noted that people at big tech companies commonly claim that they have to do algorithms interviews since it's so costly to have inefficiencies at scale. My experience is that these examples are legion at every company I've worked for that does algorithms interviews. Trying to get people to solve algorithms problems on the job by asking algorithms questions in interviews doesn't work. He goes on to talk about why this happens. In my own experience [edit to clarify: not at Microsoft], if you lay out a piece of code as an algorithm problem that needs to be optimized, most folks will make short work of it. But it's quite common for folks to not realize something will be slow enough that they need to apply that kind of thinking. That's especially true if part of the algorithm is hidden behind some indirection: whether just a function call, a call into a library that feels "far away" in the codebase / is owned by a different team, or dependency injection.
- brucedawson 6y ago
  Good article. I liked this quote: "though big companies try to make sure that the people they hire can solve algorithms puzzles they also incentivize many or most developers to avoid deploying that kind of reasoning to make money."
- fingerlocks 6y ago
  Great blog, thanks for sharing. It’s true that leetcode is a unfortunate fad of the times, and a lazy way to select candidates. I also know a number of people at Microsoft that couldn’t answer any of the leetcode problems I was given, yet extremely talented developers nonetheless. Fortunately because the system is automated, you can just reapply and take another test. Seems the questions are plucked randomly so with some luck you’ll pull a triple easy set.

baobabKoodaa 6y ago

> Have you ever done a hard leetcode problem? Yes. I used to compete on CodeForces regularly. > Clearly the icon code was delegated to some intern or perhaps a child of one of the developers, because the bar is stupid high there just to have a conversation with a hiring manager. You're implying that the developers of Microsoft can't be computer science illiterate, because a computer science illiterate couldn't possibly pass through the recruitment funnel that you experienced. But we know this code exists. Somebody wrote it. Somebody reviewed it. Somebody tested it. Everybody involved in this process thought "yeah, this is good enough", when it's clearly not good enough. Anyone with as little as CS101 experience would not write crap like this in the first place, so it's really hard to argue that the developers at Microsoft are computer science literate.

fingerlocks 6y ago
The code was likely written in the early 90s when the barrier to entry was much lower. It was a time when thousands of icons on your desktop wasn’t a use case worth considering, much less testable. That seems more plausible than all the developers being illiterate.
- baobabKoodaa 6y ago
  > The code was likely written in the early 90s when the barrier to entry was much lower. You're probably right about that. > That seems more plausible than all the developers being illiterate. I'm not saying all developers are CS illiterate, but most are.
- alisonkisk 6y ago
  That's not true at all. Many many people save everything they touch to Desktop, so it builds up cruft over time. There are ancient jokes about it. And computers were slower then brute-forcing big-O complexity was less feasible. And the "barrier to entry" gets lower as an org gross and needs to higher thousands of people and get less picky. I'm sure that MS doesn't require people to ace the hard leetcode problem to get an offer. It's just there to provide a broad picture of algorithm memory and coding speed (which is a stupid metric, not a "high" metric).
- rasz 6y ago
  >The code was likely written in the early 90s This is easily falsifiable by running a test case (create 1000 icons on desktop) in windows 7, 2000, XP and 98.

MontyCarloHall 6y ago

That interview process doesn’t just select for people who truly understand algorithms at a fundamental level. It also admits people who are good at memorizing the solutions to hundreds of leetcode-style problems. It is likely better at selecting more of the latter than the former. When I ask algo questions during interviews they’re always based on real problems that have arisen in our code. Making the question actually relevant to the job is both a better interview process overall and has the added benefit of instantly filtering out the memorizers.

haddr 6y ago

It is of course good that MS has a interview process that favors really smart people. But it doesn't mean that automatically all the work at MS will be flawless. There is much more then that. And people are even joking recently about this: https://i.redd.it/jhr5tv5ls2e61.jpg https://i.redd.it/jhr5tv5ls2e61.jpg

jerf 6y ago

Being good at "leetcode" problems and being good at writing good production algorithms certainly have some overlap... but it's not very large, and they're actively at odds with each other quite often.

baobabKoodaa 6y ago
> Being good at "leetcode" problems and being good at writing good production algorithms certainly have some overlap... but it's not very large, and they're actively at odds with each other quite often. Except in this particular example, where someone managed to write a quadratic algorithm for arranging icons.
- jerf 6y ago
  It's the leetcoder who would have written the O(n^2) algorithm and figured it's OK because it passes all the cases thrown at it. A leetcoder doesn't optimize everything, just the thing for the problem they're facing today. It's the person used to writing production code who would have stopped to think about the fact that the cases we tested with today may not be representative of the entire problem space. Leetcode is throwaway code. Writing tons and tons of throwaway code is, like I said, not completely unrelated to writing good production code. To get good at coding, as with anything, it is necessary but not sufficient to code a lot. But this is the sort of thing that I'd expect a leetcoder to do in practice; to miss the real problems, probably because they were off hyperoptimizing something else that was irrelevant.
  - baobabKoodaa 6y ago
    I don't understand why you're trying to make this argument. You said: > being good at writing good production algorithms certainly have some overlap... but it's not very large I agreed with you, and noted that this specific case is an exception: > Except in this particular example, where someone managed to write a quadratic algorithm for arranging icons. It seems to me like you're trying to take the most extreme position that's available in this discussion: you're trying to claim that being good at optimizing algorithmic time complexity ("good at leetcode") does not help someone at optimizing algorithmic time complexity in production, because there's some kind of mythical distinction between "throwaway code" and "production code". That distinction is not relevant here. Someone who is good at optimizing algorithmic time complexity in throwaway code is certainly good at optimizing algorithmic time complexity in production code. Just like someone who is good at riding horses is also good at riding horses on a sunny day. Or someone who is good at painting with acrylic is also good at painting with watercolors, if you compare to another person who doesn't have any experience painting.

scottlamb 6y ago

Check out some of Dan Luu's writing. https://danluu.com/algorithms-interviews/ https://danluu.com/algorithms-interviews/ comes to mind: > At the start of this post, we noted that people at big tech companies commonly claim that they have to do algorithms interviews since it's so costly to have inefficiencies at scale. My experience is that these examples are legion at every company I've worked for that does algorithms interviews. Trying to get people to solve algorithms problems on the job by asking algorithms questions in interviews doesn't work. He goes on to talk about why this happens. In my own experience [edit to clarify: not at Microsoft], if you lay out a piece of code as an algorithm problem that needs to be optimized, most folks will make short work of it. But it's quite common for folks to not realize something will be slow enough that they need to apply that kind of thinking. That's especially true if part of the algorithm is hidden behind some indirection: whether just a function call, a call into a library that feels "far away" in the codebase / is owned by a different team, or dependency injection.

brucedawson 6y ago
Good article. I liked this quote: "though big companies try to make sure that the people they hire can solve algorithms puzzles they also incentivize many or most developers to avoid deploying that kind of reasoning to make money."
fingerlocks 6y ago
Great blog, thanks for sharing. It’s true that leetcode is a unfortunate fad of the times, and a lazy way to select candidates. I also know a number of people at Microsoft that couldn’t answer any of the leetcode problems I was given, yet extremely talented developers nonetheless. Fortunately because the system is automated, you can just reapply and take another test. Seems the questions are plucked randomly so with some luck you’ll pull a triple easy set.