23 ms·

(sorry for sidetracking the excellent piece but...) When I examine the ~13,000 hours I've spent programming I find it hilarious that interviews should centre a

(sorry for sidetracking the excellent piece but...) When I examine the ~13,000 hours I've spent programming I find it hilarious that interviews should centre around algorithmic problems. I've been guilty of it myself and failing FizzBuzz is definitely a true negative but it's so little of a true positive it's not even funny. What I would really love to know about you as a candidate is: - do you know how to actually name functions and variables well (unbelievably important) - do you know your chosen languages and frameworks well enough to avoid cack-handedly reinventing them on paid time - do you understand how to code an application that someone else (possibly just you) will quickly understand on coming to it cold in 18 months time - do you understand the trade-offs between features and maintenance, the technical debt that features, designs and toys incur and when to invest in them and when to avoid them - are you diligent and careful and do you check and re-check your code or just chuck it in the mix for other people to fix - do you actually do real work for at least four hours each day - do you take the time to write up the things you've done and share decisions and architecture with the rest of the team - does your addition to the team on average make your team mates become better or worse coders - do you understand the exquisite balance between too much testing and too little In 13,000 hours I have had to wrestle with the consequences of O(n) complexity or binary tree search algorithms approximately NO TIMES. I did not mean to sidetrack Rob's excellent, excellent piece on finding a job in Silicon Valley however I did want to take the opportunity to state the things that I have empirically found as a professional developer to actually matter.

sergiotapia 13y ago
If you work at Google or Facebook or any other of the tech giants, you need to know your algorithm-type questions. For the other 98% of companies, there's just no need. I've also never ever had to do strange things with binary trees.
- mpeg 13y ago
  Why? Do Google or Facebook engineers live in a magical world in which they need to know off the top of their heads the big-O complexity of every possible sort function ever mentioned in an academic paper? I see this argument used time and time again, but it makes no sense to me. Surely they can just search for it when they need it too :)
  - sergiotapia 13y ago
    They deal is data volumes so large and so interconnected, it can't hurt to know those sort of things. Surely you agree?
    - doctorcroc 13y ago
      Agree, but what you described is something that can be googled and quickly learned, whereas all the intangibles op listed should be second-nature.
      - MichaelGG 13y ago
        I highly doubt that someone that does not know what binary search is, that cannot think for a minute and come up with a small implementation, is going to "google and quickly learn" algorithms and the related thinking. The issue isn't if you can write on simple binary search (considering such a search is a intro-to-programming task[1], that should be a given), but if you have an understanding of the topic in general. When your project calls for a certain performance bound, will you flail around or have some idea what you're looking for? 1: "Guess my number between 1 and 100!"
        randomdata 13y ago
        I don't think it is difficult as you make it sound. The most difficult part is finding the term "binary search", but even that is not very difficult. All you have to do is generalize your problem and state it to Google. Binary search will almost invariably come up in the results. It even works for algorithms that are far more obscure.
        MichaelGG 13y ago
        My point isn't that if you don't know what binary search is then you're going to have a hard time doing a lot of algorithm searches. Just like if you didn't know what a linked list was, or a hashtable. Writing a hashtable or reasoning out the properties of a linked list, is not the kind of thing you should need to look up. It should be easy to talk it out during an interview. These are basics. Same for strings, too. A programmer should be able to decisively explain how strings work in their language. Where do you draw the line? Arrays are just another data structure, is it OK if they don't know the properties of arrays since they can look it up?
- recursive 13y ago
  You should know enough to avoid doing nested loops to find the intersection of two lists. Things like that come up on a regular basis for me, although I don't work at any tech giant.
  - rhizome 13y ago
    You mean like this built-in from Ruby's standard Array class? intersection = ary1 & ary2
    - jw2013 13y ago
      he is probably talking about using hashtable, but that needs linear memory so there is a trade off.
      - recursive 13y ago
        Ruby's method uses something like a hashtable internally.
    - recursive 13y ago
      Yes, exactly.
      - rhizome 13y ago
        So, is that really knowing "enough" to avoid the things you mention, or can the heuristic be that you should know the standard library?
        recursive 13y ago
        There are things built into some standard libraries that are able to be combined in a way that produces a list intersection, but that are O(n^2). I prefer working in high level languages as much as the next person, but there's no substitute for knowing basic algorithms and data structures.
- spiralpolitik 13y ago
  You need people who know how to find the answer to such questions. I would much rather hire a Java developer who knows how to implement equals() and hashCode() correctly, with a unit test to validate it, and knows that if they have any questions on say searching and sorting that they should reach for their copy of Knuth v3 first before writing a single line of code. That to me is a much more valuable employee than one who can spout off how a Linked List works. 90% of programming is problem solving. Knowing how to solve a problem is much more useful than being able to spout out the right answer. (To echo the first poster. Number of times in 20 years outside of a job interview I've had to implement a Linked List: 0) IMHO Google, Facebook et al are largely the cause of the current recruiting mess because companies who don't understand what makes a good employee for their company have been cargo-culting Google, Facebook et al in the hope that will "make it rain" for them.
  - georgemcbay 13y ago
    As someone else who has also been in the industry for quite a while, it used to be fairly common for me to implement linked lists back when I was programming primarily in C. But lately, yeah, it has been mostly abstracted away, even in languages where doing pointer operations is useful or allowed. As far as companies attempting to emulate Google or Facebook when it comes to interviewing, this sort of thing is even older than either of those companies -- in the mid-90s it was common to attempt your own spin on the "Microsoft interview". I totally agree with the basic point, though... for all of the supposed rational thinking that goes on in tech, hiring people is mostly cargo cult and voodoo magic.
  - legojoey17 13y ago
    Your last paragraph really resonated with me. I personally could not emphasis my feelings and opinion towards "companies who don't understands what makes a good employee for their company" by any means. I'm currently a CS student and I do find many of the startups locally do involve loads of problem solving on the job, which is beneficial from general algorithm knowledge. Although I believe it's more so the ability to understand the concepts as opposed to spouting knowledge for any specific abstract data type or algorithm. But by any means all companies are not similar, and outside of the purpose of prodding for problem solving aptness it is definitely not the best topic to discuss in an interview to find the /right/ employee for many of the companies of which do ask it.
temuze 13y ago
I think most interviews don't focus enough on systems. I expect every software engineer to know: - How virtual memory works - How threads work - How TCP works - How ports work - How ethernet works - How DNS works - How a web server works. And so on. A lot of these things are more important than theory (but I think theory is important, too!).
- petenixey 13y ago
  This is purely anecdotal however I've been doing Rails dev (and prior to that Javascript, PHP and even Matlab) for 14 years and I have only a vague grasp how most of that list works. That's not because I'm lazy or scared or even disinterested. I've exhaustively learned everything about anything that what I do involves and how most of what it touches works as well. However the simple truth for me has been that I've never worked on things that needed to know about the things you're talking about. I constantly do need to know more about the fundamentals of the systems I actually work with - Rails, Angular, HTML, caching, Node etc. I'm sure there will come a point when I need to know more about some of those things too. However there is a tonne that I don't know even about the things that I need to know about and I will always invest my time in learning those things. That's why I would always focus interviews on the languages and frameworks that someone actually uses. Those may be the ones you describe but for plenty of developers may well not.
  - MichaelGG 13y ago
    Maybe you've been lucky? Being forced down the stack seems to happen either when you need more performance, or when stuff blows up. I only drill into a framework or language when someone writes that they're an expert on it. Otherwise, learning a new framework or language might be bumpy but if they have skill then it shouldn't be a problem.
    - mattmanser 13y ago
      That's not the stuff that typically goes wrong. TCP? DNS? More like persistent cache misses in SQL or some weird edge case caused by an errant vertical tab or a filename getting too long or some limit in array length causing your compiler to do weird stuff. Knowing how any of that list works is more for sysadmins than programmers.
onion2k 13y ago
Most software isn't hard to invent; all software is hard to maintain. For the overwhelming majority of software development, being organised is more important than being clever.
- ramayac 13y ago
  "Most software isn't hard to invent; all software is hard to maintain." -- Now that's a "money quote".
- rogeroga 13y ago
  I say that if you can organize well a messy closet or kitchen you have a basic skill to be a good ok programmer. Not necessarily means that all good programmers are superb closet organizers, but they should be able to face clutter and leave things much better than how they found them.
  - lmm 13y ago
    I don't think those are the same skills at all. Organizing a program is about merging the things that are the same and separating the things that are different. Organizing a closet is about putting things in categories, but 20 identical shoes need just as much space as 20 different shoes.
- r00fus 13y ago
  A great observation - in fact, that could apply to more than just software.
sliverstorm 13y ago
Not a software engineer here. I've still tackled O(n) in real work, while writing ancillary scripts. I'm glad I learned it. (think parsing and searching monster flat text databases from disk)
mrfusion 13y ago
You sure you wouldn't prefer someone who's really good at implementing binary search trees ...
- integraton 13y ago
  There are plenty of people who are great at CS fundamentals yet write messy, excessively complex, and/or over engineered code. For many software roles I'd much rather have someone who can write clear, maintainable, and performant code first, with deep knowledge of CS fundamentals only a requirement depending on the nature of the role and product.
  - rhizome 13y ago
    There are plenty of people who are great at CS fundamentals yet write messy, excessively complex, and/or over engineered code. Augh, PTSD trigger.
    - markcampbell 13y ago
      The one thing that you have to remember is that no one wants to write bad, unmaintainable code.
conanbatt 13y ago
I am now fairly involved in my company's interview process and Im constantly surprised that none of the resumes I get mention anything about the applicants character or professional demeanor. For all the fear of being "culturally unfit" for a company, highlighting what kind of role you play and how you interact with your coworkers is fundamental. Are you diligent and consistent with your work? Are you the kind of person that bursts through work in a flash? Do you prefer to work alone or in a team? How do you feel working with people below your position or above it? etc. These questions have the issue, however, that you rarely ask them in an interview. You just gauge them from a conversation, that really doesnt speak to any of them. If someone is a complete technical ace, but is silent 100% of the interview besides technical points, i still get red flags. A co-worker is not a cog in a machine, its someone you will be spending 40 + hours a week with. I disagree with hard theory NOT being important. Im a drop-out but i still went through all the algorithms and data structures classes out there and they gave me knowledge to communicate about hard problems, even though Im not the one solving them (we got some phds for that). And above all, at least in our case currently, several of the algorithm questions we do are actual problems we had in our product. In particular i wouldnt even call O(n) "hard". Its maybe the single most important performance computer science knowledge you need, and its not hard to calculate for the vast majority of applications.
- djb_hackernews 13y ago
  I'm not sure how you could convey your character or professional demeanor on a resume. I mean sure, everyone is just going to say they are wonderful and professional, no one is going to say they are terrible and sloppy. It's up to the interviewers to make that determination with the help of professional references.
- vladimirralev 13y ago
  This is crazy. You probably end up hiring the most convincing bullshitters. How can't you see that. The reality for most engineers is that it depends on outside factors 99%. Engineers try to be rational. Here is what the real-world answers to your questions look like and I bet you never heard them. Are you diligent and consistent with your work? IF it's being rewarded, yes. If I get yelled for missing the deadline, then no. Do I get credit for doing diligent work or the credit goes to somebody else who managed to get more visible things done less dilligently? Are you the kind of person that bursts through work in a flash? That's a straight-out stupid question. There is work that should be done in a burst(like a fix) and there is async work that can be done in chunks or in the background(planning, monitoring or support). Nobody is exclusively committed to burst/no-burst, or at least it's very rare. Do you prefer to work alone or in a team? Nonsense question. It's more of a question for you rather than the interviewee. Everybody wants to be on a good team and everybody hates to be on a bad team. Also is teamwork rewarded, how are politics resolved? How do you manage politics? Who gets credit/blame for the teamwork? How do you feel working with people below your position or above it? Same as the previous question. How do you manage politics? How is credit/blame distributed? What power do I have to push changes up and down the chain? How would you handle an under-performing member up the ranks?
nyrulez 13y ago
I don't think this debate is as complicated. There are a certain set of things you can do with the knowledge outlined above. And there is a certain set of things that you can do with semi-advanced or advanced algorithmic knowledge, knowing how the cache works, knowing how distributed algorithms work and so on. Some companies don't need the latter. Some companies do. The latter companies do want to hire someone who can do both, and not be stuck to a special set of tasks that they can do i.e. they want a generalist who can be assigned to any project of varying complexity. Personally speaking, many of the tasks I do don't involve the algorithmic skill set. But some do - now without that skill set would I just outsource it to the "brighter" folks in my company or would the company just prefer that everyone who they hire know that stuff ?
awakeasleep 13y ago
How do you get info about whether they do 4 hours of work a day?
pkteison 13y ago
What I want to find out when conducting the interview is, are you really the awesome person your resume says you are? Or did you sit next to that awesome person on a team at your last job and just goof off all day and now put everything that guy did on your resume? I'd love to have any means of better answering that question than going with "did you pay attention in class/last few jobs?" sorts of questions like "Can you work with this linked list on a white board" simple programming problems, but right now I don't know a better way. So I don't consider programming puzzles meaningless on the assumption that the guy who slacked off won't do well with them while the guy who paid attention and loves to program will know and demonstrate a thing or two. I know with some potential hires I can review a github repository, but that has similar problems. I've handed an interviewee code from his own github repo where he had fixed a defect and asked him to point out the defect he fixed on the page, and he couldn't find it. Does he just have a bad memory, or is he lying about that being his code? How can I tell?
- chetanahuja 13y ago
  I'll addressing two things from your post 1) is there a better way and 2) show me the defect that you fixed. 1) There definitely is a better way. It involves engaging with your potential long-term officemate for longer than a 45 minute face-to-face session. Have them write actual, working code (or whatever... depending on their intended role) -- maybe even pay them for the time they spend on this process with you, so they don't feel like you wasted their time if you decide not to hire them. Basically, approach this function with the same level seriousness and goodwill that you'd bring to any business dealing with people outside your company. What is that you say? You don't have time for that style of hiring process? Well you can either have a better process or a fast/simple process for judging people for long term compatibility. People generally don't get into long term relationships with other people after a 45 minute (mostly one-way) quiz. 2) Do you really expect a working professional to remember the details of each bug that they fixed in their career? Won't it have been better to simply concoct another piece of code with the bug they fixed and see if they can spot it with the familiarity of someone who's seen something like it before.
- Sukotto 13y ago
  One way to approach this is to say something like: "I have a selection of (simplified) problems we've faced recently. They're representative of the sorts of issues you would be taking care of if you join our team. Let me walk you through them one at a time and we can discuss. We'll start just by verbally going over them, then either move to a whiteboard or to a workstation to dig into them a little deeper. The goal here is to see how well we can communicate with each other as well as your ability to actually do the sort of work we need done." Imho, there are only three things you really need to know about the candidate: 1) Will this person fit into the current team with the minimum of fuss? 2) Can this person do the job professionally and in a timely way? 3) Is hiring this person a financial risk we're willing to take?
dinkumthinkum 13y ago
On your first bullet, naming functions and variables, I think that is important, sure but I think, and this may be blasphemy, that it is a little overblown. Many would make that seem like the most important thing but I think you can be a competent programmer and a valuable without being great at naming. For one, it is very subjective. You may think 10 compound words resulting in 100 character variable name, ala Java or .NET, makes perfect sense, while others think it is ridiculous. Also, I'm not sure I think "technical debt" is a real thing. If you have not dealt with complexity or algorithms then you may not be doing the kind of programming many other people are doing. Also, as a programmer, if you don't know basic algorithms and data structures, for me all the knowledge of what is hip is not a great substitute. But I can agree with a lot of what you're saying here.
- thedufer 13y ago
  > Also, I'm not sure I think "technical debt" is a real thing. Can you explain what you mean by this? Are you not familiar with the term, or do you not believe it exists?
  - dinkumthinkum 13y ago
    Oh, I'm familiar with the term. I tend to not think it is real.
GFK_of_xmaspast 13y ago
"In 13,000 hours I have had to wrestle with the consequences of O(n) complexity" then maybe you're not solving very challenging problems.
fayyazkl 13y ago
For all the arguments against the algorithmic type questions - i would add that in my ~16000 hours of professional programming, i have had to worry about O(n) to choosing Hash tables, quiet a lot of times. Although not too often (compared to factors mentioned already), but it depends upon the domain too. I worked in embedded for the most part where the liberty of using frameworks, libraries - is far scarce, so it matters which area / programming environment are we talking about in general. Also, i am yet to run into a good interviewer + programmer (whether more experienced or junior) who doesn't value these things as a good predictor of some one's coding ability. And we are not talking about only scale of companies like Google or Facebook and in my humble opinion, those might get a bit tooo algorithmic as well. But you should be able to recognize that a design you did won't scale when you have say 100k or more packets (instances) of inputs thrown at it. It won't be a problem ONLY UNTIL your list of traversal, get big enough, and frankly any software worth being discussed - gets big enough at some point. Or that your linear traversal should dramatically improve if you could code and use a hash table instead. Ah - and yes, loved the idea of 'can do serious work for at t least four hours a day', but wonder if there is a way to determine that.
- jussij 13y ago
  > For all the arguments against the algorithmic type questions - i would add that in my ~16000 hours of professional programming, i have had to worry about O(n) to choosing Hash tables, quiet a lot of times. I've got ~36000 hours of professional programming behind me and like you, there have been many a time where initial testing has highlighted a performance issues. So out comes the hash table, the binary search, the double checking of the memory allocations or the some new index on the SQL table. Now I know Big O tries to formalise these sort of things (or at least I hope that is the case), but is knowing the answers to these Big O questions that important? Since I have Engineering degree I certainly can’t give a credible answer to a Big O question, but I have absolutely no trouble fixing sluggish code. > But you should be able to recognize that a design Unfortunately, at a lot of the places I've worked, not much time is ever allocated to design :( Managers seem to want easy to read, high level, non technical design documents to take to their managers meetings and once those are approved they then want something coded ready for QA.
skybrian 13y ago
re: do you know how to actually name functions and variables well (unbelievably important) It's also subjective and can be taught. If I asked people to name some functions in an interview, what would I really learn? Similarly, the other things you mention, while important, don't seem particularly testable. They don't give me anything I can give to the hiring committee to back up my answer. Actually learning something real about a stranger in 45 minutes is pretty hard. Asking them to solve a problem means you can have a technical conversation in front of a whiteboard. It doesn't answer much but it does let me know whether it will be worthwhile asking the candidate to help me solve a tricky problem, or whether they'll be coming to me for help all the time. After all, ideally I'm looking to hire someone smarter than me.
thedufer 13y ago
> In 13,000 hours I have had to wrestle with the consequences of O(n) complexity That is what I would expect someone who has had to wrestle with big-O problems but didn't recognize them to say. I honestly don't know what you're working on if its actually true. I had a time complexity issue just this week. On front-end code, no less. I probably work on an issue involving time complexity once a month, if not more often.
dleskov 13y ago
Have you ever had to wrestle with the consequences of the complexity of analyzing a not-so-simple-and-well-researched data structure for which no generic implementation exists in any language?
gaius 13y ago
Algorithmic trivia questions are designed to bias an "objective" recruitment process towards recent graduates who have just revised all that stuff for their exams. It's a way to sneak ageism past HR.
jwmoz 13y ago
You've just put into words what I've always been thinking. In the 7 years I've worked and contracted web dev across 6 different companies I have never, let's reiterate, NEVER had to implement a sorting algorithm. However, if needed it would be quite simple to research and implement the best solution. All of the other points are what actually matter.

sergiotapia 13y ago

If you work at Google or Facebook or any other of the tech giants, you need to know your algorithm-type questions. For the other 98% of companies, there's just no need. I've also never ever had to do strange things with binary trees.

mpeg 13y ago
Why? Do Google or Facebook engineers live in a magical world in which they need to know off the top of their heads the big-O complexity of every possible sort function ever mentioned in an academic paper? I see this argument used time and time again, but it makes no sense to me. Surely they can just search for it when they need it too :)
- sergiotapia 13y ago
  They deal is data volumes so large and so interconnected, it can't hurt to know those sort of things. Surely you agree?
  - doctorcroc 13y ago
    Agree, but what you described is something that can be googled and quickly learned, whereas all the intangibles op listed should be second-nature.
    - MichaelGG 13y ago
      I highly doubt that someone that does not know what binary search is, that cannot think for a minute and come up with a small implementation, is going to "google and quickly learn" algorithms and the related thinking. The issue isn't if you can write on simple binary search (considering such a search is a intro-to-programming task[1], that should be a given), but if you have an understanding of the topic in general. When your project calls for a certain performance bound, will you flail around or have some idea what you're looking for? 1: "Guess my number between 1 and 100!"
      - randomdata 13y ago
        I don't think it is difficult as you make it sound. The most difficult part is finding the term "binary search", but even that is not very difficult. All you have to do is generalize your problem and state it to Google. Binary search will almost invariably come up in the results. It even works for algorithms that are far more obscure.
        MichaelGG 13y ago
        My point isn't that if you don't know what binary search is then you're going to have a hard time doing a lot of algorithm searches. Just like if you didn't know what a linked list was, or a hashtable. Writing a hashtable or reasoning out the properties of a linked list, is not the kind of thing you should need to look up. It should be easy to talk it out during an interview. These are basics. Same for strings, too. A programmer should be able to decisively explain how strings work in their language. Where do you draw the line? Arrays are just another data structure, is it OK if they don't know the properties of arrays since they can look it up?
recursive 13y ago
You should know enough to avoid doing nested loops to find the intersection of two lists. Things like that come up on a regular basis for me, although I don't work at any tech giant.
- rhizome 13y ago
  You mean like this built-in from Ruby's standard Array class? intersection = ary1 & ary2
  - jw2013 13y ago
    he is probably talking about using hashtable, but that needs linear memory so there is a trade off.
    - recursive 13y ago
      Ruby's method uses something like a hashtable internally.
  - recursive 13y ago
    Yes, exactly.
    - rhizome 13y ago
      So, is that really knowing "enough" to avoid the things you mention, or can the heuristic be that you should know the standard library?
      - recursive 13y ago
        There are things built into some standard libraries that are able to be combined in a way that produces a list intersection, but that are O(n^2). I prefer working in high level languages as much as the next person, but there's no substitute for knowing basic algorithms and data structures.
spiralpolitik 13y ago
You need people who know how to find the answer to such questions. I would much rather hire a Java developer who knows how to implement equals() and hashCode() correctly, with a unit test to validate it, and knows that if they have any questions on say searching and sorting that they should reach for their copy of Knuth v3 first before writing a single line of code. That to me is a much more valuable employee than one who can spout off how a Linked List works. 90% of programming is problem solving. Knowing how to solve a problem is much more useful than being able to spout out the right answer. (To echo the first poster. Number of times in 20 years outside of a job interview I've had to implement a Linked List: 0) IMHO Google, Facebook et al are largely the cause of the current recruiting mess because companies who don't understand what makes a good employee for their company have been cargo-culting Google, Facebook et al in the hope that will "make it rain" for them.
- georgemcbay 13y ago
  As someone else who has also been in the industry for quite a while, it used to be fairly common for me to implement linked lists back when I was programming primarily in C. But lately, yeah, it has been mostly abstracted away, even in languages where doing pointer operations is useful or allowed. As far as companies attempting to emulate Google or Facebook when it comes to interviewing, this sort of thing is even older than either of those companies -- in the mid-90s it was common to attempt your own spin on the "Microsoft interview". I totally agree with the basic point, though... for all of the supposed rational thinking that goes on in tech, hiring people is mostly cargo cult and voodoo magic.
- legojoey17 13y ago
  Your last paragraph really resonated with me. I personally could not emphasis my feelings and opinion towards "companies who don't understands what makes a good employee for their company" by any means. I'm currently a CS student and I do find many of the startups locally do involve loads of problem solving on the job, which is beneficial from general algorithm knowledge. Although I believe it's more so the ability to understand the concepts as opposed to spouting knowledge for any specific abstract data type or algorithm. But by any means all companies are not similar, and outside of the purpose of prodding for problem solving aptness it is definitely not the best topic to discuss in an interview to find the /right/ employee for many of the companies of which do ask it.

temuze 13y ago

I think most interviews don't focus enough on systems. I expect every software engineer to know: - How virtual memory works - How threads work - How TCP works - How ports work - How ethernet works - How DNS works - How a web server works. And so on. A lot of these things are more important than theory (but I think theory is important, too!).

petenixey 13y ago
This is purely anecdotal however I've been doing Rails dev (and prior to that Javascript, PHP and even Matlab) for 14 years and I have only a vague grasp how most of that list works. That's not because I'm lazy or scared or even disinterested. I've exhaustively learned everything about anything that what I do involves and how most of what it touches works as well. However the simple truth for me has been that I've never worked on things that needed to know about the things you're talking about. I constantly do need to know more about the fundamentals of the systems I actually work with - Rails, Angular, HTML, caching, Node etc. I'm sure there will come a point when I need to know more about some of those things too. However there is a tonne that I don't know even about the things that I need to know about and I will always invest my time in learning those things. That's why I would always focus interviews on the languages and frameworks that someone actually uses. Those may be the ones you describe but for plenty of developers may well not.
- MichaelGG 13y ago
  Maybe you've been lucky? Being forced down the stack seems to happen either when you need more performance, or when stuff blows up. I only drill into a framework or language when someone writes that they're an expert on it. Otherwise, learning a new framework or language might be bumpy but if they have skill then it shouldn't be a problem.
  - mattmanser 13y ago
    That's not the stuff that typically goes wrong. TCP? DNS? More like persistent cache misses in SQL or some weird edge case caused by an errant vertical tab or a filename getting too long or some limit in array length causing your compiler to do weird stuff. Knowing how any of that list works is more for sysadmins than programmers.

onion2k 13y ago

Most software isn't hard to invent; all software is hard to maintain. For the overwhelming majority of software development, being organised is more important than being clever.

ramayac 13y ago
"Most software isn't hard to invent; all software is hard to maintain." -- Now that's a "money quote".
rogeroga 13y ago
I say that if you can organize well a messy closet or kitchen you have a basic skill to be a good ok programmer. Not necessarily means that all good programmers are superb closet organizers, but they should be able to face clutter and leave things much better than how they found them.
- lmm 13y ago
  I don't think those are the same skills at all. Organizing a program is about merging the things that are the same and separating the things that are different. Organizing a closet is about putting things in categories, but 20 identical shoes need just as much space as 20 different shoes.
r00fus 13y ago
A great observation - in fact, that could apply to more than just software.

sliverstorm 13y ago

Not a software engineer here. I've still tackled O(n) in real work, while writing ancillary scripts. I'm glad I learned it. (think parsing and searching monster flat text databases from disk)

mrfusion 13y ago

You sure you wouldn't prefer someone who's really good at implementing binary search trees ...

integraton 13y ago
There are plenty of people who are great at CS fundamentals yet write messy, excessively complex, and/or over engineered code. For many software roles I'd much rather have someone who can write clear, maintainable, and performant code first, with deep knowledge of CS fundamentals only a requirement depending on the nature of the role and product.
- rhizome 13y ago
  There are plenty of people who are great at CS fundamentals yet write messy, excessively complex, and/or over engineered code. Augh, PTSD trigger.
  - markcampbell 13y ago
    The one thing that you have to remember is that no one wants to write bad, unmaintainable code.

conanbatt 13y ago

I am now fairly involved in my company's interview process and Im constantly surprised that none of the resumes I get mention anything about the applicants character or professional demeanor. For all the fear of being "culturally unfit" for a company, highlighting what kind of role you play and how you interact with your coworkers is fundamental. Are you diligent and consistent with your work? Are you the kind of person that bursts through work in a flash? Do you prefer to work alone or in a team? How do you feel working with people below your position or above it? etc. These questions have the issue, however, that you rarely ask them in an interview. You just gauge them from a conversation, that really doesnt speak to any of them. If someone is a complete technical ace, but is silent 100% of the interview besides technical points, i still get red flags. A co-worker is not a cog in a machine, its someone you will be spending 40 + hours a week with. I disagree with hard theory NOT being important. Im a drop-out but i still went through all the algorithms and data structures classes out there and they gave me knowledge to communicate about hard problems, even though Im not the one solving them (we got some phds for that). And above all, at least in our case currently, several of the algorithm questions we do are actual problems we had in our product. In particular i wouldnt even call O(n) "hard". Its maybe the single most important performance computer science knowledge you need, and its not hard to calculate for the vast majority of applications.

djb_hackernews 13y ago
I'm not sure how you could convey your character or professional demeanor on a resume. I mean sure, everyone is just going to say they are wonderful and professional, no one is going to say they are terrible and sloppy. It's up to the interviewers to make that determination with the help of professional references.
vladimirralev 13y ago
This is crazy. You probably end up hiring the most convincing bullshitters. How can't you see that. The reality for most engineers is that it depends on outside factors 99%. Engineers try to be rational. Here is what the real-world answers to your questions look like and I bet you never heard them. Are you diligent and consistent with your work? IF it's being rewarded, yes. If I get yelled for missing the deadline, then no. Do I get credit for doing diligent work or the credit goes to somebody else who managed to get more visible things done less dilligently? Are you the kind of person that bursts through work in a flash? That's a straight-out stupid question. There is work that should be done in a burst(like a fix) and there is async work that can be done in chunks or in the background(planning, monitoring or support). Nobody is exclusively committed to burst/no-burst, or at least it's very rare. Do you prefer to work alone or in a team? Nonsense question. It's more of a question for you rather than the interviewee. Everybody wants to be on a good team and everybody hates to be on a bad team. Also is teamwork rewarded, how are politics resolved? How do you manage politics? Who gets credit/blame for the teamwork? How do you feel working with people below your position or above it? Same as the previous question. How do you manage politics? How is credit/blame distributed? What power do I have to push changes up and down the chain? How would you handle an under-performing member up the ranks?

nyrulez 13y ago

I don't think this debate is as complicated. There are a certain set of things you can do with the knowledge outlined above. And there is a certain set of things that you can do with semi-advanced or advanced algorithmic knowledge, knowing how the cache works, knowing how distributed algorithms work and so on. Some companies don't need the latter. Some companies do. The latter companies do want to hire someone who can do both, and not be stuck to a special set of tasks that they can do i.e. they want a generalist who can be assigned to any project of varying complexity. Personally speaking, many of the tasks I do don't involve the algorithmic skill set. But some do - now without that skill set would I just outsource it to the "brighter" folks in my company or would the company just prefer that everyone who they hire know that stuff ?

awakeasleep 13y ago

How do you get info about whether they do 4 hours of work a day?

pkteison 13y ago

What I want to find out when conducting the interview is, are you really the awesome person your resume says you are? Or did you sit next to that awesome person on a team at your last job and just goof off all day and now put everything that guy did on your resume? I'd love to have any means of better answering that question than going with "did you pay attention in class/last few jobs?" sorts of questions like "Can you work with this linked list on a white board" simple programming problems, but right now I don't know a better way. So I don't consider programming puzzles meaningless on the assumption that the guy who slacked off won't do well with them while the guy who paid attention and loves to program will know and demonstrate a thing or two. I know with some potential hires I can review a github repository, but that has similar problems. I've handed an interviewee code from his own github repo where he had fixed a defect and asked him to point out the defect he fixed on the page, and he couldn't find it. Does he just have a bad memory, or is he lying about that being his code? How can I tell?

chetanahuja 13y ago
I'll addressing two things from your post 1) is there a better way and 2) show me the defect that you fixed. 1) There definitely is a better way. It involves engaging with your potential long-term officemate for longer than a 45 minute face-to-face session. Have them write actual, working code (or whatever... depending on their intended role) -- maybe even pay them for the time they spend on this process with you, so they don't feel like you wasted their time if you decide not to hire them. Basically, approach this function with the same level seriousness and goodwill that you'd bring to any business dealing with people outside your company. What is that you say? You don't have time for that style of hiring process? Well you can either have a better process or a fast/simple process for judging people for long term compatibility. People generally don't get into long term relationships with other people after a 45 minute (mostly one-way) quiz. 2) Do you really expect a working professional to remember the details of each bug that they fixed in their career? Won't it have been better to simply concoct another piece of code with the bug they fixed and see if they can spot it with the familiarity of someone who's seen something like it before.
Sukotto 13y ago
One way to approach this is to say something like: "I have a selection of (simplified) problems we've faced recently. They're representative of the sorts of issues you would be taking care of if you join our team. Let me walk you through them one at a time and we can discuss. We'll start just by verbally going over them, then either move to a whiteboard or to a workstation to dig into them a little deeper. The goal here is to see how well we can communicate with each other as well as your ability to actually do the sort of work we need done." Imho, there are only three things you really need to know about the candidate: 1) Will this person fit into the current team with the minimum of fuss? 2) Can this person do the job professionally and in a timely way? 3) Is hiring this person a financial risk we're willing to take?

dinkumthinkum 13y ago

On your first bullet, naming functions and variables, I think that is important, sure but I think, and this may be blasphemy, that it is a little overblown. Many would make that seem like the most important thing but I think you can be a competent programmer and a valuable without being great at naming. For one, it is very subjective. You may think 10 compound words resulting in 100 character variable name, ala Java or .NET, makes perfect sense, while others think it is ridiculous. Also, I'm not sure I think "technical debt" is a real thing. If you have not dealt with complexity or algorithms then you may not be doing the kind of programming many other people are doing. Also, as a programmer, if you don't know basic algorithms and data structures, for me all the knowledge of what is hip is not a great substitute. But I can agree with a lot of what you're saying here.

thedufer 13y ago
> Also, I'm not sure I think "technical debt" is a real thing. Can you explain what you mean by this? Are you not familiar with the term, or do you not believe it exists?
- dinkumthinkum 13y ago
  Oh, I'm familiar with the term. I tend to not think it is real.

GFK_of_xmaspast 13y ago

"In 13,000 hours I have had to wrestle with the consequences of O(n) complexity" then maybe you're not solving very challenging problems.

fayyazkl 13y ago

For all the arguments against the algorithmic type questions - i would add that in my ~16000 hours of professional programming, i have had to worry about O(n) to choosing Hash tables, quiet a lot of times. Although not too often (compared to factors mentioned already), but it depends upon the domain too. I worked in embedded for the most part where the liberty of using frameworks, libraries - is far scarce, so it matters which area / programming environment are we talking about in general. Also, i am yet to run into a good interviewer + programmer (whether more experienced or junior) who doesn't value these things as a good predictor of some one's coding ability. And we are not talking about only scale of companies like Google or Facebook and in my humble opinion, those might get a bit tooo algorithmic as well. But you should be able to recognize that a design you did won't scale when you have say 100k or more packets (instances) of inputs thrown at it. It won't be a problem ONLY UNTIL your list of traversal, get big enough, and frankly any software worth being discussed - gets big enough at some point. Or that your linear traversal should dramatically improve if you could code and use a hash table instead. Ah - and yes, loved the idea of 'can do serious work for at t least four hours a day', but wonder if there is a way to determine that.

jussij 13y ago
> For all the arguments against the algorithmic type questions - i would add that in my ~16000 hours of professional programming, i have had to worry about O(n) to choosing Hash tables, quiet a lot of times. I've got ~36000 hours of professional programming behind me and like you, there have been many a time where initial testing has highlighted a performance issues. So out comes the hash table, the binary search, the double checking of the memory allocations or the some new index on the SQL table. Now I know Big O tries to formalise these sort of things (or at least I hope that is the case), but is knowing the answers to these Big O questions that important? Since I have Engineering degree I certainly can’t give a credible answer to a Big O question, but I have absolutely no trouble fixing sluggish code. > But you should be able to recognize that a design Unfortunately, at a lot of the places I've worked, not much time is ever allocated to design :( Managers seem to want easy to read, high level, non technical design documents to take to their managers meetings and once those are approved they then want something coded ready for QA.

skybrian 13y ago

re: do you know how to actually name functions and variables well (unbelievably important) It's also subjective and can be taught. If I asked people to name some functions in an interview, what would I really learn? Similarly, the other things you mention, while important, don't seem particularly testable. They don't give me anything I can give to the hiring committee to back up my answer. Actually learning something real about a stranger in 45 minutes is pretty hard. Asking them to solve a problem means you can have a technical conversation in front of a whiteboard. It doesn't answer much but it does let me know whether it will be worthwhile asking the candidate to help me solve a tricky problem, or whether they'll be coming to me for help all the time. After all, ideally I'm looking to hire someone smarter than me.

thedufer 13y ago

> In 13,000 hours I have had to wrestle with the consequences of O(n) complexity That is what I would expect someone who has had to wrestle with big-O problems but didn't recognize them to say. I honestly don't know what you're working on if its actually true. I had a time complexity issue just this week. On front-end code, no less. I probably work on an issue involving time complexity once a month, if not more often.

dleskov 13y ago

Have you ever had to wrestle with the consequences of the complexity of analyzing a not-so-simple-and-well-researched data structure for which no generic implementation exists in any language?

gaius 13y ago

Algorithmic trivia questions are designed to bias an "objective" recruitment process towards recent graduates who have just revised all that stuff for their exams. It's a way to sneak ageism past HR.

jwmoz 13y ago

You've just put into words what I've always been thinking. In the 7 years I've worked and contracted web dev across 6 different companies I have never, let's reiterate, NEVER had to implement a sorting algorithm. However, if needed it would be quite simple to research and implement the best solution. All of the other points are what actually matter.