30 ms·

There is no point in giving me binary-tree-traversing questions; I don't know those answers and will never be interested in learning them. Let's presume this i

There is no point in giving me binary-tree-traversing questions; I don't know those answers and will never be interested in learning them. Let's presume this is out of preference and not ability. It's a pretty basic concept. If your preference stops you from learning something as basic as this as a programmer, then it doesn't seem likely that you will be motivated to keep up with even more abstruse concepts. Nearly every programmer nowadays knows that naive string concatenation is inefficient, and so they should use a stream or something like that. I'd rather hire someone who knows exactly why it's O(n^2) and why adding to the end of an array that doubles when it expands is O(n) amortized. Why? Because a different but analogous situation might well come up in a programming job, and the person who likes to think about such things is more likely to spot the potential problem and avoid it altogether! The fact that the op would actually feature the above sentences as a large text excerpt sets off the "Dunning-Kruger" alarm for me. That said, the op still has a good point. There is considerable organizational disconnect being displayed here. Those big companies would do well to have developers or a puzzle website do the initial filtering, rather than waste people's time by alternatively telling them they're supposedly wonderful, then supposedly horrible.

pm90 10y ago
I think you got it right. The fundamental issue seems to be that the recruiter flattered the candidate and made him/her think that they had genuinely looked through their profile and determined that they would be a good candidate. Most recruiters will not do this, simply because their priorities are not aligned that way. I think the OP revealed a very important mechanism: recruiters' job is just to get bodies in the system, which needs more people continuously for replacement and expansion.
CJKinni 10y ago
> Nearly every programmer nowadays knows that naive string concatenation is inefficient, and so they should use a stream or something like that. You and I live in different worlds, or have vastly different definitions of 'programmer.'
- trollsonson 10y ago
  Yeah, I think he meant scipter.
mmmpop 10y ago
> Nearly every programmer nowadays knows that naive string concatenation is inefficient Now that's what I call naive! Or maybe hopeful. Just saying you're giving an awful lot of credit here...
- stcredzero 10y ago
  Just saying you're giving an awful lot of credit here... I did spend awhile as an expensive "consultant" where often I was hailed as a genius just because I applied that tidbit of knowledge and sped up the application by some large fraction. However, I've also noted that there are some mainstream programming communities where people know this about string concatenation and spread this knowledge around.
davidw 10y ago
> I'd rather hire someone who knows exactly why it's O(n^2) "How do we satisfy unlimited wants with limited resources?" - economics to the rescue again. Everyone would love to hire Linus Torvalds for that matter, but there are plenty of programming jobs where you don't really need to, or don't want to, or can't spend that kind of money. There are plenty of useful, productive positions for people who aren't up on their O notation. The important thing is to be clear what kind of person you're looking for.
- dekhn 10y ago
  I would not hire Linus Torvalds. For all his technical capability (which I've followed as a linux and git user for some 25 years now) many of his externally visible statements are not acceptable for any modern workplace (this has been discussed a number of times, I know people have differing opinions, but if Torvalds worked at a modern corporation with a real HR department, his words would get him in trouble.)
  - deleted 10y ago
    [deleted]
  - wyclif 10y ago
    I strongly suspect that Linus Torvalds does not care at all about "real HR departments."
- gaius 10y ago
  Everyone would love to hire Linus Torvalds for that matter Torvalds is very lucky to have found his niche because he is unemployable - the first sweary rant at a teammate and he'd be shown the door. Well except maybe at Uber.
  - maus42 10y ago
    I suspect you've got the cause and effect backwards. More likely, because he found that niche where he does not have to learn to moderate, he does not.
ghoshbishakh 10y ago
Optimal algorithms are not the only most important thing that a software developer should know. It depends entirely on the type of the job. In most cases an experience of "design patterns" is most important.
saycheese 10y ago
There are vast amounts of basic information in the world that provides opportunities. In turn, knowing that information provides the opportunity to learn new information that is now "basic" as a result of learning the prior information. To believe any concept is so basic everyone should know it seems unlikely, since if everyone knows it the odds of being able to find someone that knows it are high and the odds of gaining value from it are small.
Alex3917 10y ago
> If your preference stops you from learning something as basic as this as a programmer, then it doesn't seem likely that you will be motivated to keep up with even more abstruse concepts. No one is arguing that there isn't any value in knowing CS. Rather, the argument basically is that for the vast majority of developers, studying algorithms is a net loss because it's time that could be better spent learning more valuable skills. If you're the person whose job is creating Redis then yeah you should probably know something about about algorithms and data structures. For most other people, having a cocktail party level familiarity with that stuff and a good understanding the phrase "tools not rules" is probably good enough.
- stcredzero 10y ago
  Rather, the argument basically is that for the vast majority of developers, studying algorithms is a net loss because it's time that could be better spent learning more valuable skills. But the op is basically implying that you don't even need the "cocktail party level familiarity." Knowing just enough first principles chemistry to know how CO2 and CO are produced can save your life. It's one thing to just know the rule you shouldn't run your car in a closed garage. It's another thing to know the general conditions where you might be producing CO, so you also know not to run your laser cutter in a poorly ventilated room. First principles knowledge are a series of tools for reasoning about the world, your program, your software libraries, etc. Programmers thinking they don't need to know the most basic algorithm knowledge is basically the anti-intellectual stance of eschewing first principles knowledge.
  - remar 10y ago
    I'm curious to meet these devs that claim that even having a basic understanding of algorithms/data structures fundamentals is not worth their time. Something tells me that the work they do is more related to design/front end and as a consequence they've either never needed to use computer science fundamentals or have been able to get away with naive implementations due to working on trivial problems. Usually I don't bother engaging in arguments with these people because I know that the standard algorithms interviews will weed these people out so that I never have to deal with them but I've started to notice a trend in more of these people finding their way into the "big 4" type companies and ending up on large scale/infrastructure projects where they end up making very critical mistakes, see https://news.ycombinator.com/item?id=13700452 https://news.ycombinator.com/item?id=13700452
arenaninja 10y ago
I think you're misquoting the article, and the "Dunning-Kruger" is uncalled for. Here's the full quote: > If she would have started her email with "We're looking for an algorithm expert," we would never have gotten any further and would not have wasted our time. Clearly, I'm not an expert in algorithms. There is no point in giving me binary-tree-traversing questions; I don't know those answers and will never be interested in learning them. We should avoid the notion that naive string concatenation is a problem that impedes our ability to deliver software, except for niche applications, this is not the case.
- SomeCallMeTim 10y ago
  > We should avoid the notion that naive string concatenation is a problem that impedes our ability to deliver software, except for niche applications, this is not the case. The attitude that really basic Computer Science concepts like algorithms and algorithmic complexity are irrelevant is exactly why software projects are so frequently FUBAR. The Dunning-Kruger reference is spot on. The original author doesn't even know what they don't know, or why they should want to learn it. Being proud of ignorance of a cornerstone topic isn't something to be celebrated.
  - chrshawkes 10y ago
    Can you provide an example of an open source code base which is messed up due to ones inability to understand algorithms?
    - SomeCallMeTim 10y ago
      I don't have an open source example; I tend to actively avoid such projects, and so I tend to accumulate lists of the ones that seem well engineered rather than the opposite. The Quora app, though: If I'm writing a reasonably long answer and I delete a paragraph, it can take more than 10 seconds to complete. There's some profound inability to understand algorithms in there somewhere, I can guarantee it. There was just a headline on Hacker News a few days ago about a "reject!" function, if I remember correctly, that ended up with an n^2 algorithm for several major Ruby releases because someone fixing a bug didn't understand the consequence of their change. I don't have the link, though. EDIT to fix the name of the Ruby function and to add the link. [1] Thanks to user nighthawk454 who dug it up! [1] https://news.ycombinator.com/item?id=13691303 https://news.ycombinator.com/item?id=13691303
glangdale 10y ago
I agree. Personally, I'm a bit horrified at the idea that someone who wants to be an "expert at object oriented design" would turn up their noses at "binary-tree-traversing questions". It sounds like a formula for aspiring Architecture Astronauts. It's also not realistic, given the wheat-to-chaff ratio out there, for a manager to interview all the candidates directly without an elaborate screening process, although the 'get interviewed by some generic programmer who has a cheat sheet for the Hard Questions you are working through on the fly' seems like an anti-pattern. I have talked to all of our groups hires as a near-final step. There's a valid point in there somewhere, though. The recruiters that Google uses locally, for example, seem clueless enough to not care that their approach is quite offensive to someone who is not junior and/or desperate for a job. For several years, every few months, I got a come-on from our local Google office that seemed to be implying that working for Google was So Neat that I would probably want to drop 2-3 levels down the SE -> Senior SE -> Staff SE -> Senior Staff SE -> Principal Engineer chain, AND I would only have to carry a pager 1 week out of 4 as a Site Reliability Engineer. Well, hey, that sounds like a real step up from running a team doing something I really like at my current employer and getting to dream up SIMD tricks and algorithms all day! I'll get right on that. My very own pager!
- aorloff 10y ago
  Well said. The problem is, many recruiters actually wouldn't understand that sarcasm. And that's the problem the OP is talking about. For a lot of recruiters, they are so excited to be working at a big tech firm that they don't understand why anyone else would be any less excited.
- michaelt 10y ago
  It's also not realistic, given the wheat-to-chaff ratio out there, for a manager to interview all the candidates directly without an elaborate screening process Sure, but that screening process should be completed before you invite a candidate for an on-site interview. I'm a hiring manager. If I say someone should spend 8 hours attending an in-person interview before I'll spend 5 minutes reviewing their resume/github, I'm saying my time is a hundred times as valuable as theirs. I can understand someone taking umbrage at that - especially someone who had better skills than me. And I want to hire people with better skills than me.
hueving 10y ago
>Let's presume this is out of preference and not ability. It's a pretty basic concept. If your preference stops you from learning something as basic as this as a programmer, then it doesn't seem likely that you will be motivated to keep up with even more abstruse concepts. This same exact argument could be used to require every interview candidate to know assembly. >and the person who likes to think about such things is more likely to spot the potential problem and avoid it altogether! I find that developers who constantly get caught up in the performance of individual algorithms will waste incredible amounts of time optimizing them and will miss major optimizations that come from seeing the system as a whole. For example, I would rather take the developer who points out that a particular program can make use of the fact that most of the code doesn't need sorted widgets rather than the one who spent the whole time optimizing the widget sorting algorithm.
- JustSomeNobody 10y ago
  > For example, I would rather take the developer who points out that a particular program can make use of the fact that most of the code doesn't need sorted widgets rather than the one who spent the whole time optimizing the widget sorting algorithm. And I'm pretty sure that the person who doesn't want to learn binary-tree traversing will never be able to point that out. That's the point you missed of the post you replied to.
- ubernostrum 10y ago
  This same exact argument could be used to require every interview candidate to know assembly. You're not thinking big enough. My usual extension of the argument is to suggest that part of the interview process should be to give the candidate a bucket of sand and some ore, and make them smelt everything and build their own CPU from scratch. Because, y'know, it's important to cover fundamentals!
  - dekhn 10y ago
    That sounds like a really fun interview. "Given a bucket of sand, build a machine that computes pi to the nth decimal". (I'd give people extra credit for coming up with creative and interesting variants based on Buffon's needle, rather than building the full infrastructure to do lithography).
roguecoder 10y ago
It is a basic question about one very narrow skill set that is relevant for some, but not all, programming jobs. It is trivial only for people who had to slog through only-sort-of-relevant CS degrees, who may or may not be the most productive programmers. I could just as easily say "we should be asking every programmer to handle a six-box grid layout" on a white board. It is just as trivial, it is relevant to the same percentage of programmers, but if that were the intro criteria I would probably have a problem hiring people to do the algorithms work.
- stcredzero 10y ago
  It is a basic question about one very narrow skill set that is relevant for some, but not all, programming jobs. I could just as easily say "we should be asking every programmer to handle a six-box grid layout" on a white board. It's a skill set that's relevant to almost all of programming jobs. Quick: give me an example of how time/space complexity can be relevant to layout manager code. (Can't do it? Dunning-Kruger just reared its ugly head again.) You don't necessarily need to write your own layout manager. But to properly shop for one for some demanding use cases, you may well benefit from just cocktail-party level first principles knowledge, so you can pick the right library. Or, do you just have faith that Apple or [Big Company] knows what it's doing, and assume that everything can handle everything you throw at it. That works over 90% of the time. It's the exceptional case where you need the 1st principles, and such cases usually come with outsized penalties if you don't know.
  - jdlshore 10y ago
    > Can't do it? Dunning-Kruger just reared its ugly head again. @stcredzero, I've seen your name pop up time and again on this thread. I don't think you realize how rude you're being. You clearly think that Data Structures 101 is important knowledge, to the point of saying that most software project failures are caused by lack of that knowledge. Others in this thread take a more moderate position. Can you accept that this is a difference of opinion, not a sign of incompetence, and stop being so rude about it?
    - 10y ago
amorphid 10y ago
Instead of requiring someone to know a b-tree, how about just teaching it to them in an interview, and then walking through an exercise to see if they get it? That'd be more impressive to me. If someone claims to know what a b-tree, test them on a more advanced concept that builds on using a b-tree that they are unlikely to know. Then teach them that and see if they get it. Make the interview more about working together and capacity to learn, and less about computer science trivia night at the pub with no beer. Your ability to efficiently teach people stuff that you claim is important is a chance to hold yourself accountable for how well you actually know something AND whether it is actually important at all. If an interviewer taught me something I didn't know, and then quizzed me on it, I'd be impressed as heck, and I'd wanna work with that person (if they were not an asshole).
- sratner 10y ago
  This has worked quite well for me. I tend to ask one of two types of algorithm questions: 1. Pick a simple but relatively obscure data structure, something they are unlikely to have crammed the night before. I always start by asking the candidate if they are familiar with it; the answer is almost universally "no". I then pull out a wikipedia printout and a notepad, and spend 10 minutes explaining it to them, with diagrams. Once they are sure they have understood the basic operations, I ask them to implement one of these basic operation we just walked through. The amount of code here should be ~10 lines; keep on adding simplifying assumptions until it is. 2. Pick a fundamental data structure from a high-level language runtime, something you would use without thinking: python lists, javascript objects, that kind of thing. I emphasise that familiarity with said language is not required, and list some real-world properties and performance characteristics (access speed, iteration, ordering, mutation), as well as common and less-common use cases. I then ask the candidate how they think it is implemented under the hood (i.e., if you wanted these semantics in a language that didn't natively provide them, how would you do it?) I often don't have a full answer myself, so we brainstorm the requirements and implementations together; no code, just open-ended discussion. The best candidates have often emailed me afterwards, having looked up an actual open-source implementation.
  - amorphid 10y ago
krzyk 10y ago
In every single company I've been for the last 15 years, I haven't had any algorithmic problem to solve, most programmer jobs is just making software as quickly as possible and fix performance issues only when they appear. I really don't think that every programmer in Amazon or Google is faced with algorithm problems everyday, that's probably localized to some projects that deal with those, not the majority of programmer population. Expecting every programmer to know how to solve given problem on a whiteboard is like expecting every life gourd to know how to do a water escape (because it involves swimming AFTER you solve a problem of tied hands).
- JustSomeNobody 10y ago
  This gourd could solve it: http://veggietales.wikia.com/wiki/Mr._Lunt http://veggietales.wikia.com/wiki/Mr._Lunt
- ryandrake 10y ago
  I agree. Most companies SAY they want algorithm experts and API ninjas, and computer science wizards, because it sounds like the right kind of thing to say. But most of the actual work out there is either 1. plumbing some data from one layer in the stack to the other (typical CRUD app) or 2. writing glue code to integrate one vendor's middleware to another vendor's middleware, or 3. fixing bugs in some 10 year old legacy application, or if you're lucky, 4. getting an application to work barely well enough in order to ship it on time. An in-depth knowledge of traversing binary trees is not required for any of this stuff.
  - stcredzero 10y ago
    But most of the actual work out there is either 1. plumbing some data from one layer in the stack to the other (typical CRUD app) or 2. writing glue code to integrate one vendor's middleware to another vendor's middleware, or 3. fixing bugs in some 10 year old legacy application, or if you're lucky, 4. getting an application to work barely well enough in order to ship it on time. And most of a lifeguard's job is sitting around blowing a whistle at troublemakers. Does that mean you'd be fine with a lifeguard who only has those two actions in his skillset? Also, as someone who has held a number of jobs that involve your 1 through 4 above: knowing basic algorithms is beneficial to the job. You don't need that knowledge often, but when you do, it has outsized benefits. Also, you wouldn't know that, unless you had that knowledge while doing that job. If you didn't have that knowledge, you wouldn't know how it would have benefited you. The fact that "in-depth knowledge" is applied to "traversing binary trees" makes me sigh and feel uneasy.
sidlls 10y ago
Conjecture: the majority (by far, probably on the order of 75%-80% or more) of programming and engineering problems to be solved in a typical company or typical application will not see significant differences in performance by selecting a naive implementation. For example, in your string concatenation example, the naive solution is good enough except in situations where large numbers of strings are to be concatenated in a given run, or the strings are huge, etc., relative to the compute environment. Does it really matter if one uses an O(n^2) solution when a few dozen (or even a few hundred) such operations are applied on "small enough" strings in a given execution on modern computer hardware? No, it just doesn't. Select candidates who are keenly interested in and knowledgeable about algorithms for positions where it's important (i.e. part of the regular course of development), not because of that slight chance there is one edge case where one adjustment to a more efficient algorithm might possibly be useful at some indeterminate point in the future.
- sbpayne 10y ago
  Sure. But at the scale of e.g. Google, Amazon, etc. how often do you think they are performing these lower level computations? From my experience: very frequently. So it's useful at these corporations for all engineers to have this understanding, I think.
  - sidlls 10y ago
    I haven't worked at any of these companies so I wouldn't know how often they're performing these computations. My conjecture is broad, of course, and a statistical suggestion at that: it seems unobjectionable to claim that for some companies the "typical application" lives in the 20%-25% "outlier" region most of the time.
  - jboggan 10y ago
    From my admittedly limited experience at Google, given the size of the input data even a "small" project deals with those little algorithmic inefficiencies really add up quickly. You have to do a lot of optimizing and using clever data structures to make something work at all.
- 10y ago
Jach 10y ago
I'd rather hire someone who can actually get the job done in a timely manner. We can optimize it later, especially after profiling to know exactly what we need to optimize, and especially if there are security implications that mean we can't ruthlessly optimize everything. People who optimize too soon end up with solutions that are hard to change later, or solutions that don't even do the job they're supposed to. It's all too easy to get a half-working version that's super fast by focusing on the speed part more than the working part. https://alibgoogle.wordpress.com/2011/02/18/scheme-vs-c/ https://alibgoogle.wordpress.com/2011/02/18/scheme-vs-c/ is worth a read. "Real efficiency comes from elegant solutions, not optimized programs. Optimization is always just a few correctness-preserving transformations away." There are some "free" optimizations I'd expect a lot of seasoned programmers to be familiar with, like as you mention the string concatenation issue, but those are easy to catch during code review. Similarly for certain optimizations that are even 'freer' in the sense that modern compilers will take the easier-to-read (if naively slower) version and produce the fast version, I expect to not have to tell people during code review that the 'slower' version isn't slow because the compiler does the right thing.
- hashseed 10y ago
  Often enough, implementing the optimal solution is not really more time-consuming than the brute force solution. Often it's not about micro-optimizations, but a difference between O(n^3) and O(n*logn).
  - Jach 10y ago
    I guess I think of programming in a big company as a team exercise. And thus the hiring pipeline can take advantage of specialization and good-enough economics, as well as teaching people more on-the-job. It's a large burden if you demand everyone on the team know the same first principles (of course there may be disagreement on what those are). Even if personally I want to know as much as I can and get along with others who do too, I'm not really going to hold it against a team member if they produce a poor-complexity algorithm that in review I (or someone else, I think it is good to have at least one person on the team who has algorithm knowledge) notice and can suggest an alternative that's easy to use instead. If they do it again (for the exact same thing) I might raise an eyebrow and remind them of the repeat mistake. If they do it a third time I might write them off as incapable of learning new things. But this pattern applies to other aspects of software too. e.g. Getting people to write testable code can itself be a hassle if they haven't been exposed to that before. Or something as dead simple as getting people to use the rest of the team's coding style guidelines, I've seen interns who still had problems with that near the end of the summer internship, I wouldn't be very happy if it was a senior colleague...
BeetleB 10y ago
>Nearly every programmer nowadays knows that naive string concatenation is inefficient, and so they should use a stream or something like that. I'd rather hire someone who knows exactly why it's O(n^2) I'd love to hire a programmer that knows this is actually O(n^3), and not O(n^2). (Well, it is if you are naively concatenating N strings, each of length N characters). (Had a manager who insisted it was exponential. Wisely did not argue with him). (I await attempts to recruit me based on this comment).
- stcredzero 10y ago
  I'd love to hire a programmer that knows this is actually O(n^3), and not O(n^2). Hint: Don't ever work for or hire anyone who would exploit the ambiguity of the English language in a hastily written comment to gain the false appearance of geeky superiority. (Exercise: how would you interpret the situation referred to in the comment to wind up with O(n^2) and how you interpret it to wind up with O(n^3)?)
  - BeetleB 10y ago
    While I wrote it without much seriousness, I think my comment does highlight a problem with the whole discussion here. People like to boast about how important it is to know these kinds of complexities, but in reality they just use mental heuristics to come up with them (which is how we got n^2 and exp(n) from my manager). For string concatenation, is it important they know how to do it in a linear fashion? Or is it important that they can actually calculate the complexity? Or do you want an in-between where it is OK that they do not really know the complexity, but can tell you that it is definitely super-linear? I've seen people be fussy that they should be able to explain why it is n^3 (or n^2 or whatever), in a somewhat rigorous fashion. I say "somewhat" because when I then turn to them and ask them to derive the exact expression (not just in big-Oh notation), they will usually fail. Then they will go through hoops trying to explain why it is important to know it in big-Oh notation but not all that important to be able to derive the exact formula. (There is, of course, a camp that does not believe much in big-Oh and actually prefers to know the leading constant, etc. My example is not contrived.) I find people will nitpick to their level of granularity, and it is always easy to come up with some justification for their level of preference. But to others, it is just nitpicking. For me, it is important to know that this is super-linear, whereas one can do it linearly. I don't care if the candidate knows it is n^3 or n^2. That is also why I did not point out my manager's error at saying it is exp(n).
lorenzhs 10y ago
> why adding to the end of an array that doubles when it expands is O(n) amortized Not to be overly nit-picky here, and technically O(n) is correct as well (it's also the un-amortized worst case of insertion), but you probably meant to say that the amortized time is O(1), or θ(1) to be even more precise :)
- stcredzero 10y ago
  to be even more precise :) Or, you should demonstrate the self awareness to realize that you're just playing with the ambiguity of English in a hastily written comment. Exercise: in what precise context would time/space complexity be O(n), and in what precise context would it be O(1)? (Though the emoticon is probably an indicator that you already knew all this.)
  - lorenzhs 10y ago
    I'm well aware how to analyze a dynamically growing array (each insert "pays" for two moves in the future), but I'm not sure what you're getting at. The amortized complexity of appending an element to the end is θ(1), worst-case non-amortized θ(n) when the growing needs to happen.
    - stcredzero 10y ago
      Then do that N times. Then re-read the text and think of the context being discussed.
rampage101 10y ago
Whenever I hear a programmer talk badly about algorithms it leaves a poor impression with me. It means they have not taken the time to do basic research about their field and shows their aversion to researching new topics. If you look at the current AI, machine learning, and deep learning fields it's an absolute must that you have some experience with algorithms.
kirykl 10y ago
could you explain what you mean by stream ?
BurningFrog 10y ago
I have done professional programming for decades. I have never written code to traverse a binary tree. I almost certainly never will. If I ever have to write it, it's a pretty simple thing to look up. This piece of algorithm trivia has no relevance for software engineering jobs in 2017. There is of course one reason to learn it: It keeps coming up in interviews.
skywhopper 10y ago
Actually, there are lots of skills and competencies that are valuable on engineering teams other than the ability to have all basic algorithms on call in your head at all times. If you filter the engineers you are willing to hire based on any one factor (unless you are looking for that specific specialty), then you are missing out on a variety of perspectives and experience that could make a better team. You don't need everyone on your team to be an algorithm expert. If you don't recognize that there are a huge variety of other skills necessary to successful software projects, then you are the one experiencing the Dunning-Kruger effect, not the op.
- stcredzero 10y ago
  Point of clarification: I don't want everyone to be an algorithm expert. I do want every programmer to have the basic background knowledge. If you are passingly familiar with binary trees and recursion, then you can figure out the answer from First Principles. If you are not familiar with the skills at that level, and don't have the basic skills you're supposed to get by studying such things, then perhaps one would characterize that as merely memorizing. Actually, there are lots of skills and competencies that are valuable on engineering teams other than the ability to have all basic algorithms on call in your head at all times. Where did I ever say such a preposterous thing? Please provide a quote. And again, if you understand algorithms at a basic level from First Principles, then you don't have to memorize every algorithm like baseball card trivia. The important thing is having the background knowledge. If you don't think such knowledge is foundational background, then you probably don't know enough to know that. Hence: Dunning-Kruger.

pm90 10y ago

I think you got it right. The fundamental issue seems to be that the recruiter flattered the candidate and made him/her think that they had genuinely looked through their profile and determined that they would be a good candidate. Most recruiters will not do this, simply because their priorities are not aligned that way. I think the OP revealed a very important mechanism: recruiters' job is just to get bodies in the system, which needs more people continuously for replacement and expansion.

CJKinni 10y ago

> Nearly every programmer nowadays knows that naive string concatenation is inefficient, and so they should use a stream or something like that. You and I live in different worlds, or have vastly different definitions of 'programmer.'

trollsonson 10y ago
Yeah, I think he meant scipter.

mmmpop 10y ago

> Nearly every programmer nowadays knows that naive string concatenation is inefficient Now that's what I call naive! Or maybe hopeful. Just saying you're giving an awful lot of credit here...

stcredzero 10y ago
Just saying you're giving an awful lot of credit here... I did spend awhile as an expensive "consultant" where often I was hailed as a genius just because I applied that tidbit of knowledge and sped up the application by some large fraction. However, I've also noted that there are some mainstream programming communities where people know this about string concatenation and spread this knowledge around.

davidw 10y ago

> I'd rather hire someone who knows exactly why it's O(n^2) "How do we satisfy unlimited wants with limited resources?" - economics to the rescue again. Everyone would love to hire Linus Torvalds for that matter, but there are plenty of programming jobs where you don't really need to, or don't want to, or can't spend that kind of money. There are plenty of useful, productive positions for people who aren't up on their O notation. The important thing is to be clear what kind of person you're looking for.

dekhn 10y ago
I would not hire Linus Torvalds. For all his technical capability (which I've followed as a linux and git user for some 25 years now) many of his externally visible statements are not acceptable for any modern workplace (this has been discussed a number of times, I know people have differing opinions, but if Torvalds worked at a modern corporation with a real HR department, his words would get him in trouble.)
- deleted 10y ago
  [deleted]
- wyclif 10y ago
  I strongly suspect that Linus Torvalds does not care at all about "real HR departments."
gaius 10y ago
Everyone would love to hire Linus Torvalds for that matter Torvalds is very lucky to have found his niche because he is unemployable - the first sweary rant at a teammate and he'd be shown the door. Well except maybe at Uber.
- maus42 10y ago
  I suspect you've got the cause and effect backwards. More likely, because he found that niche where he does not have to learn to moderate, he does not.

ghoshbishakh 10y ago

Optimal algorithms are not the only most important thing that a software developer should know. It depends entirely on the type of the job. In most cases an experience of "design patterns" is most important.

saycheese 10y ago

There are vast amounts of basic information in the world that provides opportunities. In turn, knowing that information provides the opportunity to learn new information that is now "basic" as a result of learning the prior information. To believe any concept is so basic everyone should know it seems unlikely, since if everyone knows it the odds of being able to find someone that knows it are high and the odds of gaining value from it are small.

Alex3917 10y ago

> If your preference stops you from learning something as basic as this as a programmer, then it doesn't seem likely that you will be motivated to keep up with even more abstruse concepts. No one is arguing that there isn't any value in knowing CS. Rather, the argument basically is that for the vast majority of developers, studying algorithms is a net loss because it's time that could be better spent learning more valuable skills. If you're the person whose job is creating Redis then yeah you should probably know something about about algorithms and data structures. For most other people, having a cocktail party level familiarity with that stuff and a good understanding the phrase "tools not rules" is probably good enough.

stcredzero 10y ago
Rather, the argument basically is that for the vast majority of developers, studying algorithms is a net loss because it's time that could be better spent learning more valuable skills. But the op is basically implying that you don't even need the "cocktail party level familiarity." Knowing just enough first principles chemistry to know how CO2 and CO are produced can save your life. It's one thing to just know the rule you shouldn't run your car in a closed garage. It's another thing to know the general conditions where you might be producing CO, so you also know not to run your laser cutter in a poorly ventilated room. First principles knowledge are a series of tools for reasoning about the world, your program, your software libraries, etc. Programmers thinking they don't need to know the most basic algorithm knowledge is basically the anti-intellectual stance of eschewing first principles knowledge.
- remar 10y ago
  I'm curious to meet these devs that claim that even having a basic understanding of algorithms/data structures fundamentals is not worth their time. Something tells me that the work they do is more related to design/front end and as a consequence they've either never needed to use computer science fundamentals or have been able to get away with naive implementations due to working on trivial problems. Usually I don't bother engaging in arguments with these people because I know that the standard algorithms interviews will weed these people out so that I never have to deal with them but I've started to notice a trend in more of these people finding their way into the "big 4" type companies and ending up on large scale/infrastructure projects where they end up making very critical mistakes, see https://news.ycombinator.com/item?id=13700452 https://news.ycombinator.com/item?id=13700452

arenaninja 10y ago

I think you're misquoting the article, and the "Dunning-Kruger" is uncalled for. Here's the full quote: > If she would have started her email with "We're looking for an algorithm expert," we would never have gotten any further and would not have wasted our time. Clearly, I'm not an expert in algorithms. There is no point in giving me binary-tree-traversing questions; I don't know those answers and will never be interested in learning them. We should avoid the notion that naive string concatenation is a problem that impedes our ability to deliver software, except for niche applications, this is not the case.

SomeCallMeTim 10y ago
> We should avoid the notion that naive string concatenation is a problem that impedes our ability to deliver software, except for niche applications, this is not the case. The attitude that really basic Computer Science concepts like algorithms and algorithmic complexity are irrelevant is exactly why software projects are so frequently FUBAR. The Dunning-Kruger reference is spot on. The original author doesn't even know what they don't know, or why they should want to learn it. Being proud of ignorance of a cornerstone topic isn't something to be celebrated.
- chrshawkes 10y ago
  Can you provide an example of an open source code base which is messed up due to ones inability to understand algorithms?
  - SomeCallMeTim 10y ago
    I don't have an open source example; I tend to actively avoid such projects, and so I tend to accumulate lists of the ones that seem well engineered rather than the opposite. The Quora app, though: If I'm writing a reasonably long answer and I delete a paragraph, it can take more than 10 seconds to complete. There's some profound inability to understand algorithms in there somewhere, I can guarantee it. There was just a headline on Hacker News a few days ago about a "reject!" function, if I remember correctly, that ended up with an n^2 algorithm for several major Ruby releases because someone fixing a bug didn't understand the consequence of their change. I don't have the link, though. EDIT to fix the name of the Ruby function and to add the link. [1] Thanks to user nighthawk454 who dug it up! [1] https://news.ycombinator.com/item?id=13691303 https://news.ycombinator.com/item?id=13691303

glangdale 10y ago

I agree. Personally, I'm a bit horrified at the idea that someone who wants to be an "expert at object oriented design" would turn up their noses at "binary-tree-traversing questions". It sounds like a formula for aspiring Architecture Astronauts. It's also not realistic, given the wheat-to-chaff ratio out there, for a manager to interview all the candidates directly without an elaborate screening process, although the 'get interviewed by some generic programmer who has a cheat sheet for the Hard Questions you are working through on the fly' seems like an anti-pattern. I have talked to all of our groups hires as a near-final step. There's a valid point in there somewhere, though. The recruiters that Google uses locally, for example, seem clueless enough to not care that their approach is quite offensive to someone who is not junior and/or desperate for a job. For several years, every few months, I got a come-on from our local Google office that seemed to be implying that working for Google was So Neat that I would probably want to drop 2-3 levels down the SE -> Senior SE -> Staff SE -> Senior Staff SE -> Principal Engineer chain, AND I would only have to carry a pager 1 week out of 4 as a Site Reliability Engineer. Well, hey, that sounds like a real step up from running a team doing something I really like at my current employer and getting to dream up SIMD tricks and algorithms all day! I'll get right on that. My very own pager!

aorloff 10y ago
Well said. The problem is, many recruiters actually wouldn't understand that sarcasm. And that's the problem the OP is talking about. For a lot of recruiters, they are so excited to be working at a big tech firm that they don't understand why anyone else would be any less excited.
michaelt 10y ago
It's also not realistic, given the wheat-to-chaff ratio out there, for a manager to interview all the candidates directly without an elaborate screening process Sure, but that screening process should be completed before you invite a candidate for an on-site interview. I'm a hiring manager. If I say someone should spend 8 hours attending an in-person interview before I'll spend 5 minutes reviewing their resume/github, I'm saying my time is a hundred times as valuable as theirs. I can understand someone taking umbrage at that - especially someone who had better skills than me. And I want to hire people with better skills than me.

hueving 10y ago

>Let's presume this is out of preference and not ability. It's a pretty basic concept. If your preference stops you from learning something as basic as this as a programmer, then it doesn't seem likely that you will be motivated to keep up with even more abstruse concepts. This same exact argument could be used to require every interview candidate to know assembly. >and the person who likes to think about such things is more likely to spot the potential problem and avoid it altogether! I find that developers who constantly get caught up in the performance of individual algorithms will waste incredible amounts of time optimizing them and will miss major optimizations that come from seeing the system as a whole. For example, I would rather take the developer who points out that a particular program can make use of the fact that most of the code doesn't need sorted widgets rather than the one who spent the whole time optimizing the widget sorting algorithm.

JustSomeNobody 10y ago
> For example, I would rather take the developer who points out that a particular program can make use of the fact that most of the code doesn't need sorted widgets rather than the one who spent the whole time optimizing the widget sorting algorithm. And I'm pretty sure that the person who doesn't want to learn binary-tree traversing will never be able to point that out. That's the point you missed of the post you replied to.
ubernostrum 10y ago
This same exact argument could be used to require every interview candidate to know assembly. You're not thinking big enough. My usual extension of the argument is to suggest that part of the interview process should be to give the candidate a bucket of sand and some ore, and make them smelt everything and build their own CPU from scratch. Because, y'know, it's important to cover fundamentals!
- dekhn 10y ago
  That sounds like a really fun interview. "Given a bucket of sand, build a machine that computes pi to the nth decimal". (I'd give people extra credit for coming up with creative and interesting variants based on Buffon's needle, rather than building the full infrastructure to do lithography).

roguecoder 10y ago

It is a basic question about one very narrow skill set that is relevant for some, but not all, programming jobs. It is trivial only for people who had to slog through only-sort-of-relevant CS degrees, who may or may not be the most productive programmers. I could just as easily say "we should be asking every programmer to handle a six-box grid layout" on a white board. It is just as trivial, it is relevant to the same percentage of programmers, but if that were the intro criteria I would probably have a problem hiring people to do the algorithms work.

stcredzero 10y ago
It is a basic question about one very narrow skill set that is relevant for some, but not all, programming jobs. I could just as easily say "we should be asking every programmer to handle a six-box grid layout" on a white board. It's a skill set that's relevant to almost all of programming jobs. Quick: give me an example of how time/space complexity can be relevant to layout manager code. (Can't do it? Dunning-Kruger just reared its ugly head again.) You don't necessarily need to write your own layout manager. But to properly shop for one for some demanding use cases, you may well benefit from just cocktail-party level first principles knowledge, so you can pick the right library. Or, do you just have faith that Apple or [Big Company] knows what it's doing, and assume that everything can handle everything you throw at it. That works over 90% of the time. It's the exceptional case where you need the 1st principles, and such cases usually come with outsized penalties if you don't know.
- jdlshore 10y ago
  > Can't do it? Dunning-Kruger just reared its ugly head again. @stcredzero, I've seen your name pop up time and again on this thread. I don't think you realize how rude you're being. You clearly think that Data Structures 101 is important knowledge, to the point of saying that most software project failures are caused by lack of that knowledge. Others in this thread take a more moderate position. Can you accept that this is a difference of opinion, not a sign of incompetence, and stop being so rude about it?
  - 10y ago

amorphid 10y ago

Instead of requiring someone to know a b-tree, how about just teaching it to them in an interview, and then walking through an exercise to see if they get it? That'd be more impressive to me. If someone claims to know what a b-tree, test them on a more advanced concept that builds on using a b-tree that they are unlikely to know. Then teach them that and see if they get it. Make the interview more about working together and capacity to learn, and less about computer science trivia night at the pub with no beer. Your ability to efficiently teach people stuff that you claim is important is a chance to hold yourself accountable for how well you actually know something AND whether it is actually important at all. If an interviewer taught me something I didn't know, and then quizzed me on it, I'd be impressed as heck, and I'd wanna work with that person (if they were not an asshole).

sratner 10y ago
This has worked quite well for me. I tend to ask one of two types of algorithm questions: 1. Pick a simple but relatively obscure data structure, something they are unlikely to have crammed the night before. I always start by asking the candidate if they are familiar with it; the answer is almost universally "no". I then pull out a wikipedia printout and a notepad, and spend 10 minutes explaining it to them, with diagrams. Once they are sure they have understood the basic operations, I ask them to implement one of these basic operation we just walked through. The amount of code here should be ~10 lines; keep on adding simplifying assumptions until it is. 2. Pick a fundamental data structure from a high-level language runtime, something you would use without thinking: python lists, javascript objects, that kind of thing. I emphasise that familiarity with said language is not required, and list some real-world properties and performance characteristics (access speed, iteration, ordering, mutation), as well as common and less-common use cases. I then ask the candidate how they think it is implemented under the hood (i.e., if you wanted these semantics in a language that didn't natively provide them, how would you do it?) I often don't have a full answer myself, so we brainstorm the requirements and implementations together; no code, just open-ended discussion. The best candidates have often emailed me afterwards, having looked up an actual open-source implementation.
- amorphid 10y ago

krzyk 10y ago

In every single company I've been for the last 15 years, I haven't had any algorithmic problem to solve, most programmer jobs is just making software as quickly as possible and fix performance issues only when they appear. I really don't think that every programmer in Amazon or Google is faced with algorithm problems everyday, that's probably localized to some projects that deal with those, not the majority of programmer population. Expecting every programmer to know how to solve given problem on a whiteboard is like expecting every life gourd to know how to do a water escape (because it involves swimming AFTER you solve a problem of tied hands).

JustSomeNobody 10y ago
This gourd could solve it: http://veggietales.wikia.com/wiki/Mr._Lunt http://veggietales.wikia.com/wiki/Mr._Lunt
ryandrake 10y ago
I agree. Most companies SAY they want algorithm experts and API ninjas, and computer science wizards, because it sounds like the right kind of thing to say. But most of the actual work out there is either 1. plumbing some data from one layer in the stack to the other (typical CRUD app) or 2. writing glue code to integrate one vendor's middleware to another vendor's middleware, or 3. fixing bugs in some 10 year old legacy application, or if you're lucky, 4. getting an application to work barely well enough in order to ship it on time. An in-depth knowledge of traversing binary trees is not required for any of this stuff.
- stcredzero 10y ago
  But most of the actual work out there is either 1. plumbing some data from one layer in the stack to the other (typical CRUD app) or 2. writing glue code to integrate one vendor's middleware to another vendor's middleware, or 3. fixing bugs in some 10 year old legacy application, or if you're lucky, 4. getting an application to work barely well enough in order to ship it on time. And most of a lifeguard's job is sitting around blowing a whistle at troublemakers. Does that mean you'd be fine with a lifeguard who only has those two actions in his skillset? Also, as someone who has held a number of jobs that involve your 1 through 4 above: knowing basic algorithms is beneficial to the job. You don't need that knowledge often, but when you do, it has outsized benefits. Also, you wouldn't know that, unless you had that knowledge while doing that job. If you didn't have that knowledge, you wouldn't know how it would have benefited you. The fact that "in-depth knowledge" is applied to "traversing binary trees" makes me sigh and feel uneasy.

sidlls 10y ago

Conjecture: the majority (by far, probably on the order of 75%-80% or more) of programming and engineering problems to be solved in a typical company or typical application will not see significant differences in performance by selecting a naive implementation. For example, in your string concatenation example, the naive solution is good enough except in situations where large numbers of strings are to be concatenated in a given run, or the strings are huge, etc., relative to the compute environment. Does it really matter if one uses an O(n^2) solution when a few dozen (or even a few hundred) such operations are applied on "small enough" strings in a given execution on modern computer hardware? No, it just doesn't. Select candidates who are keenly interested in and knowledgeable about algorithms for positions where it's important (i.e. part of the regular course of development), not because of that slight chance there is one edge case where one adjustment to a more efficient algorithm might possibly be useful at some indeterminate point in the future.

sbpayne 10y ago
Sure. But at the scale of e.g. Google, Amazon, etc. how often do you think they are performing these lower level computations? From my experience: very frequently. So it's useful at these corporations for all engineers to have this understanding, I think.
- sidlls 10y ago
  I haven't worked at any of these companies so I wouldn't know how often they're performing these computations. My conjecture is broad, of course, and a statistical suggestion at that: it seems unobjectionable to claim that for some companies the "typical application" lives in the 20%-25% "outlier" region most of the time.
- jboggan 10y ago
  From my admittedly limited experience at Google, given the size of the input data even a "small" project deals with those little algorithmic inefficiencies really add up quickly. You have to do a lot of optimizing and using clever data structures to make something work at all.
10y ago

Jach 10y ago

I'd rather hire someone who can actually get the job done in a timely manner. We can optimize it later, especially after profiling to know exactly what we need to optimize, and especially if there are security implications that mean we can't ruthlessly optimize everything. People who optimize too soon end up with solutions that are hard to change later, or solutions that don't even do the job they're supposed to. It's all too easy to get a half-working version that's super fast by focusing on the speed part more than the working part. https://alibgoogle.wordpress.com/2011/02/18/scheme-vs-c/ https://alibgoogle.wordpress.com/2011/02/18/scheme-vs-c/ is worth a read. "Real efficiency comes from elegant solutions, not optimized programs. Optimization is always just a few correctness-preserving transformations away." There are some "free" optimizations I'd expect a lot of seasoned programmers to be familiar with, like as you mention the string concatenation issue, but those are easy to catch during code review. Similarly for certain optimizations that are even 'freer' in the sense that modern compilers will take the easier-to-read (if naively slower) version and produce the fast version, I expect to not have to tell people during code review that the 'slower' version isn't slow because the compiler does the right thing.

hashseed 10y ago
Often enough, implementing the optimal solution is not really more time-consuming than the brute force solution. Often it's not about micro-optimizations, but a difference between O(n^3) and O(n*logn).
- Jach 10y ago
  I guess I think of programming in a big company as a team exercise. And thus the hiring pipeline can take advantage of specialization and good-enough economics, as well as teaching people more on-the-job. It's a large burden if you demand everyone on the team know the same first principles (of course there may be disagreement on what those are). Even if personally I want to know as much as I can and get along with others who do too, I'm not really going to hold it against a team member if they produce a poor-complexity algorithm that in review I (or someone else, I think it is good to have at least one person on the team who has algorithm knowledge) notice and can suggest an alternative that's easy to use instead. If they do it again (for the exact same thing) I might raise an eyebrow and remind them of the repeat mistake. If they do it a third time I might write them off as incapable of learning new things. But this pattern applies to other aspects of software too. e.g. Getting people to write testable code can itself be a hassle if they haven't been exposed to that before. Or something as dead simple as getting people to use the rest of the team's coding style guidelines, I've seen interns who still had problems with that near the end of the summer internship, I wouldn't be very happy if it was a senior colleague...

BeetleB 10y ago

>Nearly every programmer nowadays knows that naive string concatenation is inefficient, and so they should use a stream or something like that. I'd rather hire someone who knows exactly why it's O(n^2) I'd love to hire a programmer that knows this is actually O(n^3), and not O(n^2). (Well, it is if you are naively concatenating N strings, each of length N characters). (Had a manager who insisted it was exponential. Wisely did not argue with him). (I await attempts to recruit me based on this comment).

stcredzero 10y ago
I'd love to hire a programmer that knows this is actually O(n^3), and not O(n^2). Hint: Don't ever work for or hire anyone who would exploit the ambiguity of the English language in a hastily written comment to gain the false appearance of geeky superiority. (Exercise: how would you interpret the situation referred to in the comment to wind up with O(n^2) and how you interpret it to wind up with O(n^3)?)
- BeetleB 10y ago
  While I wrote it without much seriousness, I think my comment does highlight a problem with the whole discussion here. People like to boast about how important it is to know these kinds of complexities, but in reality they just use mental heuristics to come up with them (which is how we got n^2 and exp(n) from my manager). For string concatenation, is it important they know how to do it in a linear fashion? Or is it important that they can actually calculate the complexity? Or do you want an in-between where it is OK that they do not really know the complexity, but can tell you that it is definitely super-linear? I've seen people be fussy that they should be able to explain why it is n^3 (or n^2 or whatever), in a somewhat rigorous fashion. I say "somewhat" because when I then turn to them and ask them to derive the exact expression (not just in big-Oh notation), they will usually fail. Then they will go through hoops trying to explain why it is important to know it in big-Oh notation but not all that important to be able to derive the exact formula. (There is, of course, a camp that does not believe much in big-Oh and actually prefers to know the leading constant, etc. My example is not contrived.) I find people will nitpick to their level of granularity, and it is always easy to come up with some justification for their level of preference. But to others, it is just nitpicking. For me, it is important to know that this is super-linear, whereas one can do it linearly. I don't care if the candidate knows it is n^3 or n^2. That is also why I did not point out my manager's error at saying it is exp(n).

lorenzhs 10y ago

> why adding to the end of an array that doubles when it expands is O(n) amortized Not to be overly nit-picky here, and technically O(n) is correct as well (it's also the un-amortized worst case of insertion), but you probably meant to say that the amortized time is O(1), or θ(1) to be even more precise :)

stcredzero 10y ago
to be even more precise :) Or, you should demonstrate the self awareness to realize that you're just playing with the ambiguity of English in a hastily written comment. Exercise: in what precise context would time/space complexity be O(n), and in what precise context would it be O(1)? (Though the emoticon is probably an indicator that you already knew all this.)
- lorenzhs 10y ago
  I'm well aware how to analyze a dynamically growing array (each insert "pays" for two moves in the future), but I'm not sure what you're getting at. The amortized complexity of appending an element to the end is θ(1), worst-case non-amortized θ(n) when the growing needs to happen.
  - stcredzero 10y ago
    Then do that N times. Then re-read the text and think of the context being discussed.

rampage101 10y ago

Whenever I hear a programmer talk badly about algorithms it leaves a poor impression with me. It means they have not taken the time to do basic research about their field and shows their aversion to researching new topics. If you look at the current AI, machine learning, and deep learning fields it's an absolute must that you have some experience with algorithms.

kirykl 10y ago

could you explain what you mean by stream ?

BurningFrog 10y ago

I have done professional programming for decades. I have never written code to traverse a binary tree. I almost certainly never will. If I ever have to write it, it's a pretty simple thing to look up. This piece of algorithm trivia has no relevance for software engineering jobs in 2017. There is of course one reason to learn it: It keeps coming up in interviews.

skywhopper 10y ago

Actually, there are lots of skills and competencies that are valuable on engineering teams other than the ability to have all basic algorithms on call in your head at all times. If you filter the engineers you are willing to hire based on any one factor (unless you are looking for that specific specialty), then you are missing out on a variety of perspectives and experience that could make a better team. You don't need everyone on your team to be an algorithm expert. If you don't recognize that there are a huge variety of other skills necessary to successful software projects, then you are the one experiencing the Dunning-Kruger effect, not the op.

stcredzero 10y ago
Point of clarification: I don't want everyone to be an algorithm expert. I do want every programmer to have the basic background knowledge. If you are passingly familiar with binary trees and recursion, then you can figure out the answer from First Principles. If you are not familiar with the skills at that level, and don't have the basic skills you're supposed to get by studying such things, then perhaps one would characterize that as merely memorizing. Actually, there are lots of skills and competencies that are valuable on engineering teams other than the ability to have all basic algorithms on call in your head at all times. Where did I ever say such a preposterous thing? Please provide a quote. And again, if you understand algorithms at a basic level from First Principles, then you don't have to memorize every algorithm like baseball card trivia. The important thing is having the background knowledge. If you don't think such knowledge is foundational background, then you probably don't know enough to know that. Hence: Dunning-Kruger.