5 ms·

Our interviews at Palantir test for these for two reasons: We evaluate a lot of people coming straight out of school in CS. They don't have much experience in

Our interviews at Palantir test for these for two reasons: We evaluate a lot of people coming straight out of school in CS. They don't have much experience in development. Thus, the best way to test if a candidate is smart is to see if he's learned his course material well. We do a lot of heavy algorithms and distributed systems, so we ask that, but it also happens to be what students learn. Running time and Oh, however, in addition to systems knowledge, is extremely important to creating good software in general. If you can't determine how your software will scale with big data, and you can't understand why efficient code that runs quickly with small operations does so, you simply can't write good software. I realize a lot of people on HN take offense at these claims because they've written programs without this knowledge and claim they are self taught. The reality, however, is that they aren't good programmers. You don't need a good programmer to write a prototype that works and determines market fit. You do need good programmers to scale your product, add features efficiently, and architect solutions without making a crippling mess of your code. Edit: I realize the above comment sounds a little condescending. It wasn't meant to be. I have met self taught programmers that are amazing. Most people just don't have the self discipline to fully learn a subject matter (I many times don't). So a lot of "self taught" programmers have only taught themselves 10% of what they need to know and never bother learning the other 90%.

mcantor 15y ago
I upvoted you for the good explanation (and the refreshingly self-aware edit). However, I think it is rather presumptuous to paint the broad strokes of "good" and "bad" without adding so many caveats that it would no longer be germane to this conversation. By your definition, I am currently a "bad programmer" because I do not have fluency in algorithms. (I will leave the objective truth of this statement as an exercise to the reader; God knows it might be so. However...) I contend that I am capable of learning new material quickly enough that, if I were suddenly called upon at my job to write code which handles all of the slings and arrows of algorithmic complexity, I would be able to do so with very little friction. To phrase it differently: I (probably) don't know enough to write gorgeous, algorithmically sophisticated code on the first pass, but I know enough to know when it's time for me to hit the books, and where to start. Obviously, it would take me longer than someone with prior experience in writing such code! If the overarching question is "does algorithmic fluency constitute a dealbreaker when hiring at certain positions", then I suppose the answer depends on how much longer it would take. I can only speculate on the difference in a flagrantly biased manner, as I would egotistically prefer to believe that I ought to be hired in more cases than not. :-) Or, if we look through the Dunning-Kruger lens, we may conclude that lack of algorithmic fluency always constitutes a dealbreaker at certain positions, because even if the developer in question can learn on the job, he or she will still make errors and oversights with far-reaching implications that are invisible--unknown unknowns--to the algorithmically illiterate. This feels less plausible to me than the simpler consideration that "learning on the job" may simply be an undesirable speed bump. I don't really have any concrete points or refutations to make; I'm just fascinated by the issue in general and enjoy exploring the possible angles. (Also I shall likely just cut the Gordian knot and go play with algorithms until it simply isn't an issue anymore. Go figure) EDIT: Actually, there is a point I forgot to make: In your edit you wrote, "So a lot of "self taught" programmers have only taught themselves 10% of what they need to know and never bother learning the other 90%." I think this is the crux of the "good/bad" problem: "what they need to know" is very subjective and dependent on context. I think it's reasonable to assert that there are programmers out there who have long and satisfying careers, but never learned X, or didn't learn it for many years. Who's to say whether they are "good" or "bad"? It's a judgment, and judgments are meaningless without context: "good programmers need to know X" doesn't really say anything, but "programmers need to know X if they want to Y" does. You certainly went down this road in your comment, but your Y was "You do need good programmers to scale your product, add features efficiently, and architect solutions without making a crippling mess of your code.", and I feel like lack of fluency in algorithms is just not a surefire indicator of bad architecture skills (among the others you listed) as well.
- jimbokun 15y ago
  "I contend that I am capable of learning new material quickly enough that, if I were suddenly called upon at my job to write code which handles all of the slings and arrows of algorithmic complexity, I would be able to do so with very little friction." How do you know whether or not this is true? Until you know it, how do you go about estimating how long it will take to you to learn it? How do you even assess when you've learned "enough" algorithmic complexity for the task at hand? Can you give any reasons someone looking to hire you should believe that you can learn the ins and outs of algorithmic complexity with "very little friction"?
- groby_b 15y ago
  Based on 20 years of experience, lack of fluency in algorithms _is_ a surefire indicator of bad architecture skills. Yes, it gives a few false positives, but the amount of false negatives is pretty much 0. And since actually getting a new person on-board is an expensive process, you aim for criteria that are a bit too stringent, if you can afford it. There's also the issue that making a bad algorithmic decision at the center of the problem turns scaling into an insanely hard problem, sometimes. It's not so much about learning about it when you need it, but about avoiding issues in the first place. True, there are many places where it truly doesn't matter - but if scaling/performance matter for your company, you don't want to head down the garden path because your developers didn't know better. Not knowing algorithms won't exclude you from all jobs (or even many of them), but there are some jobs where it _will_ bite you. It's your choice if you want to go for those jobs. Personally, I think they are where the cool stuff is happening, but YMMV.
  - HardyLeung 15y ago
    I agree with jchonphoenix and groby_b. I'm sure there are a lot of great self-taught genius who don't have the formal training but does a much better job than most, but there are orders of magnitude more in the camp of "half-taught" mediocre programmers, with shiny formal training, that can easily be filtered out using this approach.
  - mcantor 15y ago
    Thank you, this is an illuminating response! Hopefully I'll remember to look back on this thread when I'm enlightened so I can see if I've switched sides on the debate. :-)
ori_b 15y ago
As a self taught programmer, I fully agree with you. Forcing myself to work through CLRS was the most important thing I did on my way towards where I am. What you said isn't condescending at all. If you are a self taught programmer and you haven't read up and gotten a good handle on big O notation, data structures, and algorithms, do yourself a favor and start.
jaylevitt 15y ago
I'm self-taught. I also wrote the world's then-largest mail system, which eventually handled 4,000 TPS at zero downtime on servers about as powerful as my iPhone. I also don't know algorithms. E-mail, at the time, didn't need them - there was no search, no deduplication, no anything but "do a bunch of deterministic, bounded operations very quickly." Sure, some hash tables and plenty of linked lists, but that's about it. Am I just a big fat outlier there, condemned to cram Skiena before every interview for the rest of my life?
- jchonphoenix 15y ago
  You may be an outlier, or you may just not be in the group of self taught programmers that was described. As I said, most self taught programmers don't fully understand what they do. Many, however, do. I was just explaining the most common case. Judging by the fact that you were able to do many deterministic bounded operations quickly, and understand why they were bounded and why they were quick, I get the feeling that you'd do much better at an algorithm interview than you give yourself credit for. And I'd also cram CLRS before an interview :P I know I'm good at what I do compared to the avg coder, but compared to the average coder at Palantir, I have a long way to go. I'm in no way satisfied with my ability where it is today and its always smart to take a refresher before an interview.
jebblue 15y ago
>> Edit: I realize the above comment sounds a little condescending. It wasn't meant to be. I have met self taught programmers that are amazing. Most people just don't have the self discipline to fully learn a subject matter (I many times don't). So a lot of "self taught" programmers have only taught themselves 10% of what they need to know and never bother learning the other 90%. It was condescending to my eyes, nothing more nothing less.

mcantor 15y ago

I upvoted you for the good explanation (and the refreshingly self-aware edit). However, I think it is rather presumptuous to paint the broad strokes of "good" and "bad" without adding so many caveats that it would no longer be germane to this conversation. By your definition, I am currently a "bad programmer" because I do not have fluency in algorithms. (I will leave the objective truth of this statement as an exercise to the reader; God knows it might be so. However...) I contend that I am capable of learning new material quickly enough that, if I were suddenly called upon at my job to write code which handles all of the slings and arrows of algorithmic complexity, I would be able to do so with very little friction. To phrase it differently: I (probably) don't know enough to write gorgeous, algorithmically sophisticated code on the first pass, but I know enough to know when it's time for me to hit the books, and where to start. Obviously, it would take me longer than someone with prior experience in writing such code! If the overarching question is "does algorithmic fluency constitute a dealbreaker when hiring at certain positions", then I suppose the answer depends on how much longer it would take. I can only speculate on the difference in a flagrantly biased manner, as I would egotistically prefer to believe that I ought to be hired in more cases than not. :-) Or, if we look through the Dunning-Kruger lens, we may conclude that lack of algorithmic fluency always constitutes a dealbreaker at certain positions, because even if the developer in question can learn on the job, he or she will still make errors and oversights with far-reaching implications that are invisible--unknown unknowns--to the algorithmically illiterate. This feels less plausible to me than the simpler consideration that "learning on the job" may simply be an undesirable speed bump. I don't really have any concrete points or refutations to make; I'm just fascinated by the issue in general and enjoy exploring the possible angles. (Also I shall likely just cut the Gordian knot and go play with algorithms until it simply isn't an issue anymore. Go figure) EDIT: Actually, there is a point I forgot to make: In your edit you wrote, "So a lot of "self taught" programmers have only taught themselves 10% of what they need to know and never bother learning the other 90%." I think this is the crux of the "good/bad" problem: "what they need to know" is very subjective and dependent on context. I think it's reasonable to assert that there are programmers out there who have long and satisfying careers, but never learned X, or didn't learn it for many years. Who's to say whether they are "good" or "bad"? It's a judgment, and judgments are meaningless without context: "good programmers need to know X" doesn't really say anything, but "programmers need to know X if they want to Y" does. You certainly went down this road in your comment, but your Y was "You do need good programmers to scale your product, add features efficiently, and architect solutions without making a crippling mess of your code.", and I feel like lack of fluency in algorithms is just not a surefire indicator of bad architecture skills (among the others you listed) as well.

jimbokun 15y ago
"I contend that I am capable of learning new material quickly enough that, if I were suddenly called upon at my job to write code which handles all of the slings and arrows of algorithmic complexity, I would be able to do so with very little friction." How do you know whether or not this is true? Until you know it, how do you go about estimating how long it will take to you to learn it? How do you even assess when you've learned "enough" algorithmic complexity for the task at hand? Can you give any reasons someone looking to hire you should believe that you can learn the ins and outs of algorithmic complexity with "very little friction"?
groby_b 15y ago
Based on 20 years of experience, lack of fluency in algorithms _is_ a surefire indicator of bad architecture skills. Yes, it gives a few false positives, but the amount of false negatives is pretty much 0. And since actually getting a new person on-board is an expensive process, you aim for criteria that are a bit too stringent, if you can afford it. There's also the issue that making a bad algorithmic decision at the center of the problem turns scaling into an insanely hard problem, sometimes. It's not so much about learning about it when you need it, but about avoiding issues in the first place. True, there are many places where it truly doesn't matter - but if scaling/performance matter for your company, you don't want to head down the garden path because your developers didn't know better. Not knowing algorithms won't exclude you from all jobs (or even many of them), but there are some jobs where it _will_ bite you. It's your choice if you want to go for those jobs. Personally, I think they are where the cool stuff is happening, but YMMV.
- HardyLeung 15y ago
  I agree with jchonphoenix and groby_b. I'm sure there are a lot of great self-taught genius who don't have the formal training but does a much better job than most, but there are orders of magnitude more in the camp of "half-taught" mediocre programmers, with shiny formal training, that can easily be filtered out using this approach.
- mcantor 15y ago
  Thank you, this is an illuminating response! Hopefully I'll remember to look back on this thread when I'm enlightened so I can see if I've switched sides on the debate. :-)

ori_b 15y ago

As a self taught programmer, I fully agree with you. Forcing myself to work through CLRS was the most important thing I did on my way towards where I am. What you said isn't condescending at all. If you are a self taught programmer and you haven't read up and gotten a good handle on big O notation, data structures, and algorithms, do yourself a favor and start.

jaylevitt 15y ago

I'm self-taught. I also wrote the world's then-largest mail system, which eventually handled 4,000 TPS at zero downtime on servers about as powerful as my iPhone. I also don't know algorithms. E-mail, at the time, didn't need them - there was no search, no deduplication, no anything but "do a bunch of deterministic, bounded operations very quickly." Sure, some hash tables and plenty of linked lists, but that's about it. Am I just a big fat outlier there, condemned to cram Skiena before every interview for the rest of my life?

jchonphoenix 15y ago
You may be an outlier, or you may just not be in the group of self taught programmers that was described. As I said, most self taught programmers don't fully understand what they do. Many, however, do. I was just explaining the most common case. Judging by the fact that you were able to do many deterministic bounded operations quickly, and understand why they were bounded and why they were quick, I get the feeling that you'd do much better at an algorithm interview than you give yourself credit for. And I'd also cram CLRS before an interview :P I know I'm good at what I do compared to the avg coder, but compared to the average coder at Palantir, I have a long way to go. I'm in no way satisfied with my ability where it is today and its always smart to take a refresher before an interview.

jebblue 15y ago

>> Edit: I realize the above comment sounds a little condescending. It wasn't meant to be. I have met self taught programmers that are amazing. Most people just don't have the self discipline to fully learn a subject matter (I many times don't). So a lot of "self taught" programmers have only taught themselves 10% of what they need to know and never bother learning the other 90%. It was condescending to my eyes, nothing more nothing less.