16 ms·

We always tell our candidates in advance what algorithms we'll be quizzing them on. And it's pretty much always: + fibbonacci + a sort + a linked list I lik

• arethuza 6y ago
  "write out these problems on paper" I write on paper so infrequently that I actually find it pretty difficult to write more than a few words. I certainly wouldn't want to write something out longhand in an interview! Edit: It seems to me it would be rather unfair of me to ask people to write out their thoughts in Org Mode in VS Code just because that's how I happen to like writing notes :-)
  • ajuc 6y ago
    Writing speed isn't the bottleneck hopefully :)
    • fenomas 6y ago
      It's not a matter of writing speed, it's familiarity. I've been programming for 30 years and I don't think I've ever written code down on paper. Why ask an interview candidate to do something they've never done before and will never do again? You might as well ask them to type their code using only one hand.
      • toomanybeersies 6y ago
        As a heavy smoker, I'd be quite good in an interview where I was forced to type with one hand.
      • TedDoesntTalk 6y ago
        > I've been programming for 30 years and I don't think I've ever written code down on paper I did it once or twice when I was 8 years old and didn’t have a computer yet :)
    • arethuza 6y ago
      Writing speed probably would be the bottleneck for me - plus whatever I wrote would almost certainly be illegible to anyone else.
  • robotron 6y ago
    I had to do a timed exercise to write code on paper IN PEN at a job interview. Talk about feeling like I had to get it correct the first time. Glad they didn't give me an offer because I would've had to consider accepting it.
    • arethuza 6y ago
      You problem used tabs rather than spaces ;-) Seriously though - how long ago was that - not recently I hope?
• fanf2 6y ago
  Why would anyone use recursion to calculate Fibonacci numbers other than as a microbenchmark for function call performance?
  • bbarn 6y ago
    It's a great showcase of how a flashy looking solution is the wrong approach. A good candidate will know it can be written in 2 lines recursively, but that the stack will explode with a fairly low term number, and that iterating with a for loop is more efficient.
    • eru 6y ago
      In eg Python you can just add a memoization decoration, and get a linear solution from the naive recursive one. That's pretty neat.
      • dotancohen 6y ago
        In almost any language, a hashtable check after the base case check could be used in a similar manner.
        • eru 6y ago
          Yes. I just singled out Python, because the language is well-known, and adding the memoization is particularly straight-forward.
    • dotancohen 6y ago
      > iterating with a for loop I'm struggling to understand what you mean? This is a learning opportunity for me, if you wouldn't mind posting a code sample or elaborating further.
      • ajuc 6y ago
        Something like this (might be subtly wrong, I wrote it in 2 minutes). int fib(int n) { if (n<=2) return 1; int fibNMinus2= 1; int fibNMinus1 = 1; int tmp; for (int i=3; i<=n; i++) { tmp = fibNMinus2+ fibNMinus1 ; fibNMinus2 = fibNMinus1; fibNMinus1 = tmp; } return fibNMinus1; } vs recursive solution which is pretty but slow (and will fail when you run out of stack) int fib(int n) { if (i<=2) return 1; return fib(n-1)+fib(n-2); }
• the_mitsuhiko 6y ago
  > I like having candidates write out these problems on paper because it shows that they know how to think about code. Is this really a useful exercise? Why not present them with an actual problem that is relevant to your field and see how they approach it?
  • entha_saava 6y ago
    To filter out naive people that don't have proper understanding of fundamentals and just having some framework plumbing knowledge, I guess. These are considered pretty basic stuff that every programmer should know..
    • p1necone 6y ago
      In my experience it's pretty necessary to do this. Probably depends on your local job market, but there are a shocking number of candidates that just don't know how to code. The explanation I've heard is that good devs generally get hired after only a handful of interviews, whereas really bad devs are going to do a lot more interviews on average before they get hired, so you get a pretty skewed sampling even if there aren't that many really bad candidates around.
      • entha_saava 6y ago
        Yes, Joel Spolsky and IIRC Jeff Atwood have written somewhat extensively about it. We are in a bubble, if we read programming blogs and think about programming in our free time, we are definitely not the kind that FizzBuzz exists to filter out. But from the perspective of companies, it makes sense if they really understood pointers or recursion or graph manipulation, because there are so many people lying on their resumes, not having sufficient analytical skills despite doing some resume driven cargo cult development etc.. And as an industry we don't really have an alternative to these algorithm interviews at scale, at the point we rely on non technical HR people to filter out resumes for us and they literally grep for framework/language experience.
        • 6y ago
• deadgunslinger 6y ago
  How do you figure from a Fibonacci exercise that the candidate understands recursion? It's 5 lines of code to memorize.
  • wadkar 6y ago
    By the way they discuss the implementation. First level is ensuring that base cases are covered (i.e. correct implementation of recursion) Second level is how they explain the simple recursion that’ll hit stack limits (i.e. without tail recursion) Third level is using accumulator/tail recursion. See how they can express these ideas and are they able to effectively communicate their intentions.
    • dotancohen 6y ago
      Serious request, as a developer who would probably code a naive Fibonacci that doesn't meet your standard: Could you provide a code sample that does meet your standard? This looks like an important learning opportunity for me. Thanks.
      • Smaug123 6y ago
        Instead of recursing twice, recurse once, by carrying around not fib(n-1) but the pair (fib(n-2), fib(n-1)).
        • dotancohen 6y ago
          True, but then the "worker" fib() method should be called fib_calculate() and should be wrapped by fib() which then returns a single integer. I believe that breaks the spirit of the question.
          • Taek 6y ago
            Really it's about this type of discussion. Already with your 'but then' you are showing that you know your way around a program. I'd still have you write the full thing out, but I'm guessing you'd do just fine.
• lootsauce 6y ago
  This sounds like a reasonable approach and that is why software interviews remain broken. I'm sure it works for your organization, not saying you are bad at hiring or anything but it still smacks of the kind of hoop-jumping that turned me off so much from the process last time I was interviewing. This included on-the-spot coding exercises, massive take-home projects that required many hours of undifferentiated grunt work, totally useless whiteboard sketching and pseudo-code sessions, obscure Google-like quiz questions. The interview process for the job I have now was a massive breath of fresh air. The application asked for code samples and a cv. It was a small company and the CEO, CTO and direct co-workers all drove the interview process. The process was entirely conversational. First an intro phone call with the CTO and then a questionnaire via email in which I answered about 30 questions on various topics that were all very practical daily software development type stuff. It was painless to respond to each with about a paragraph in detail. Then a call with a direct co-worker about the questionnaire and this was my opportunity to ask questions of him about the company. Before getting the interview they actually read my code samples and reviewed my Github account. In the interview there was a ton of discussion about the company, its culture and all the of the above discussions. Following this was compensation negotiation with the CEO. Everything about the hiring process said to me yes this is the place, they get it!
  • psds2 6y ago
    Many people would consider a 30 question take home project massive. You discuss your second experience as if it is some novel Utopian experience but when I read it sounds like an experience that was well suited to your strengths but wouldn't be suited to mine.
    • lootsauce 6y ago
      It definitely favored verbal skills, I am assuming that was a feature not a bug in the hiring process. The questions were not a project but a conversation in the context of my experience With a specific tech stack such as... “How do you keep a server from getting hacked”, “how do you handle conflicting dependencies”, “how do you know your code is ready to deploy to production”
  • 6y ago
• rimliu 6y ago
  If you use recurssion for Fibbonacci, you do not understand neither recurrsion nor Fibbonacci.
  • WalterBright 6y ago
    "You, Sir, are employing a double negative." -- Mr. Spock
    • rimliu 6y ago
      Am I?
      • WalterBright 6y ago
        It's "not understand either" or "understand neither".
      • c17r 6y ago
        “You understand neither recursion nor Fibonacci” Or “You do not understand recursion nor Fibonacci”
        • egman_ekki 6y ago
          Ain't nobody got time for that.
          • WalterBright 6y ago
            Ain't nobody got no time for that. FTFY
  • elcomet 6y ago
    That's a bold claim. You can very much solve Fibonacci with recursion efficiently. It's just not in the naive way. (You can look up "accumulator")
    • 6y ago
• deepGem 6y ago
  I think someone's ability to understand and explain recursion like am a child is very undervalued. It's not about testing whether you know the base case or the fact that you write less lines of code in recursion but the fact that there is a built-in stack for you to use without creating one. What are the practical applications of recursion though ? Other than sorting and DFS ( well even DFS can be done iteratively with stacks ). I'll be curious to know. I find testing for HashTable/HashMap knowledge to be far more practical than testing for LinkedLists simply because you can't escape HashTables in today's world.
  • ajuc 6y ago
    > What are the practical applications of recursion though ? Traversing and transforming nested data structures. Just last month I had to write code that maps flat data from one system into a nested structure required by another system. We wrote mappings as map literals and the code traverses them creating a new instance of the map filling the leaves with data from the input row and running some business logic on it.
• tchaffee 6y ago
  I already don't want the job because of the interview process. Talking to someone about code they have written and the decisions and thinking around their own code is so much more respectful and gives better signal. You should be doing everything you can to put the candidate on their own turf and letting them shine. I have a lot of advice about interviews but one of the best I've heard over the years: whatever impression you have of the candidate try to prove yourself wrong. Using that advice, I've found a lot of great programmers that other companies skip over. Some people who are great at coding are bad at interviews and bad at live problem solving with an audience. If you really feel the need for a test, a paid take home coding assignment will give you the best signal.
  • haggy 6y ago
    I agree with this 100%. I'd also like to add that because of this I adapted the traditional whiteboarding exercise at my current company to be about problem solving and design, and not about how many data structures you've memorized. When a candidate comes in, I give them a fake-yet-realistic product requirement (like count elements in a real-time stream from field sensors) and let them run with it however they see fit. I put zero restrictions on the tech side of things in order to let the candidate shine (hopefully) in whatever tech they are most comfortable with. I make sure to ask for feedback on the exercise and I've gotten all positive feedback from candidates.
    • tchaffee 6y ago
      It sounds like you're trying which is encouraging. I'll give you a few tips that I hope help. > I adapted the traditional whiteboarding exercise Lots of engineer types freeze when they have to make a presentation. I remember a meeting early in my career with literally three people in a conference room and I almost had a panic attack. No white board. People I already knew. All I had to to do is explain my ideas to three people. I did improve. I've given many public talks sometimes to hundreds of people and today I like public speaking. But I'll never forget where I started and that the person I'm interviewing might be very nervous. Putting them up on a whiteboard and into presentation mode only amplifies that nervousness. Just talk to people. Get them into that flow that comes from talking about something familiar that they are excited about. For most people a whiteboard test is not exciting. But if you give me a paid take home coding exercise, that's exciting. I like code, and I like to get paid for it. So if you really think you need a test, consider a very high signal test that is the exact work they will be doing. > I make sure to ask for feedback on the exercise and I've gotten all positive feedback from candidates. In an unequal relationship like that you are going to get a lot of false positives. If I really needed a job my response would be "loved the exercise, looking forward to talking to you more and discussing next steps if I'm the right candidate".
• blackrock 6y ago
  Are you hiring for first year beginners? Or is this also a test for your senior software engineers? Your question topics are completely useless to normal software engineering work. And this proves how immature your company is, in understanding the nature of the work. Perhaps you should consider asking them instead, what their technique is to ensure reliability, throughout, and redundancy in their code? Can they make their code self-heal itself? Or to make some minor decisions to restart itself, if optimal conditions are not met. You know.. basic software engineering stuff.
• theelous3 6y ago
  Making people write code on paper is just ridiculous - way outside of testing and checking reality - and your reasoning of >"because it shows that they know how to think about code" means nothing at worst, and at best indicates you'll only be happy to work with people who are replicas of yourself. Take home is the way to go, unless the position is some sort of public exhibitionist analogue developer position. The least I think you can do is move from paper to machine, and inform them they should bring their own machine, or offer them use of one with many envs preconfigured.
  • collyw 6y ago
    Take homes are usually very time consuming.
    • psalminen 6y ago
      This varies a lot. I had a take-home for a data engineer role which just asked to get and parse an xml and post a cleaned, limited json of the data. Took ~1hr. Perfect for an initial threshold.
      • collyw 6y ago
        That's fair. Usually they involve writing some sort of miniature application. Setup of the project will usually be in the range of an hour.
  • toomanybeersies 6y ago
    The problem with take home interviews is that it could take one candidate an hour, and another every evening for a week. Ideally the interviewer shouldn't be concerned about absolute code correctness, such as syntax or argument position, and should be interested more in how you're able to solve the problem, which should be a novel, yet simple task that doesn't require studying up on 200 level algorithms. You want to hire developers (for permanent full time roles, at least) who have a good conceptual grasp of programming and logic, rather than their particular knowledge of a language or framework, or their ability to search on stackoverflow and run their code through a linter. The worst interview problem I've been given was to write an AngularJS directive, I think literally to simply take an attribute and display it. I can't remember at the best of times the syntactical oddities of AngularJS, let alone when writing with pen and paper in an interview with no resources. One of the better problems I was given was around parsing XML, from memory validating that opening tags matched closing tags, while allowing for self-closing tagsI remember the problem specifically didn't include any more complex facets of XML. Another was to reverse a string in-place ("hello world" -> "dlrow olleh"), and then to modify the algorithm to reverse the words but keep them in place ("hello world" -> "olleh dlrow"). Obviously in the real world you'd just use built in methods, but it's a problem that should be solvable without digging up your old lecture notes. I've always felt comfortable writing code (or at least psuedocode) with a pen, but I think it's unfair to require a candidate to solve the problem on paper or whiteboard if they feel more comfortable typing on a computer instead, all that achieves is disadvantaging otherwise capable candidates who for one reason or another can't write code with a pen and paper. As long as they aren't googling "how to reverse a string in place", it immaterial what writing tool they use. If they feel more comfortable using a brush and papyrus, or carving a runestone, then that should be perfectly acceptable too (provided they bring their own writing material).
• P-ala-din 6y ago
  I feel like these are poor choices. * linked lists shouldn't be used anyway. and if they are used, you should use the standard implementation * directly applying fibbonacci is trivial. * sort: This is just a memorisation task, what's the point? (99% of the time, you shouldn't implement your own sort) although, I agree with the open-book approach in the problem solving part.
• thiagocesar 6y ago
  12 years as a developer. Used recursion only once. Once. (but that specific time recursion was really a life saver)
  • LandR 6y ago
    Depends on the language. When programming in Clojure I use recursion a LOT.
• pps43 6y ago
  > Fibbonacci allows us to see that they have basic recursion understanding I see no reason to use recursion when asked to calculate Fibonacci numbers. A loop looks like a more reasonable choice that also avoids typical pitfalls associated with recursion. Maybe that's because I did embedded programming for a while. I suspect recursion is introduced in CS classes with this example, but people understand it as "you are supposed to use recursion to calculate Fibonacci numbers".
  • paulryanrogers 6y ago
    Recursion is often less efficient but looks more elegant and simpler. It breaks the problem down to is essence. Then you can trade some complexity for more run-time efficiency.
    • pps43 6y ago
      > more elegant and simpler Beauty is in the eye of the beholder, but a loop is hard to beat as far as simplicity goes, and you don't depend on your compiler being clever enough to optimize tail recursion. If you need to traverse a tree then sure, but with Fibonacci you don't even need the stack to begin with. You only need to keep a previous number.
      • deleted 6y ago
        [deleted]
      • duskwuff 6y ago
        You don't even need a loop. Binet's formula gives a closed-form expression for the Fibonacci sequence. (And of course I don't remember that formula off the top of my head, but I know it exists, so I'd be 90% of the way to solving a problem which required it.)
        • pps43 6y ago
          This will open another can of worms (floating point errors).
• watwut 6y ago
  I think that your test if fairly easy and since it requires very little time before that, I dont understand the opposition of other people. But, you are not seeing how people think about code. You are seeing presentation prepared before hand. That whole part abour seeing how people think, as much as it is repeated, is nonsense, so maybe it is not much of loss.
• ricksharp 6y ago
  This sounds like an inspection of whether the person has had a class in basic algorithms rather than if they have ever coded anything in real life. In school I played with sorting algorithms, in business if I ever found a developer manually writing a sorting algorithm, I would consider them inept (unless there were very specific reasons to do so). If someone didn’t know how to sort a list using the built in or standard library of whatever language they are using, I would know very quickly that they have almost no experience writing anything useful.
  • ricksharp 6y ago
    In fact now that I think about it, it might be a good test to see if they are passionate enough to be a great problem solver: When was the last time you wrote a sorting algorithm? Acceptable answers: - You mean sorting a list? - In school - Why would I write a sorting algorithm? - Never - (Glazing eyes and other body language that indicates frustration) Red Flags: - Anything that indicates they think writing a sorting algorithm is a perfectly logical thing to do during the course of software development. (Note: The problem is sorting may seem like a well-understood problem, but it’s actually not. Only a person who studied the algorithms in school as an assignment would feel comfortable with that code.)
    • craftinator 6y ago
      Acceptable answer: it depends on what I'm sorting. Is it a primitive like char strings, numbers, or a more complex data type? Could it have null values and type mismatches, am I using a strongly typed language? Does it need to be cleaned first? I think the ability to come up with relevant and important questions to ask about the task given is more crucial than whether they can solve it. You can look up answers to questions from hundreds of good sources, but you need to be able to generate the right questions that need to be answered first.
      • maaaaattttt 6y ago
        > you need to be able to generate the right questions Completely agree with this statement. I would add that having the proper vocabulary is an important part of generating the right questions.
• no_wizard 6y ago
  I’ve been interviewing at a lot of places lately. I _never_ white board interviewed before this round of interviews I’ve done And at first I have to say that I hated it so much. In a weird way though, I’ve at least grown to understand why it’s so popular, and I don’t think it’s just because FAANGS do it (though I think that’s how it came to prominence). It boils down to showing as an engineer your capable of being flexible and malleable your change and understanding. Some places definitely do this better than others, and I think it says a lot about company culture if they are Adversarial about it or not. In my experience rather unfortunately even good places to work can be adversarial about it. The massive downside is and always will be it puts so much onerous on the candidate because you don’t really know what they are going to ask and freezing up or getting stumped is very frowned upon in these style interviews from what I experienced. My tip to anyone though is just to practice, but I’ve yet to encounter places that don’t employ some technique to test algorithmic thinking and understanding of complex systems in some way.
• onion2k 6y ago
  I like having candidates write out these problems on paper because... ...because you like working through problems on paper, and your interview process is designed to find people like you.
• ivanhoe 6y ago
  Seems over-complicated, e.g. I probably wouldn't go for recursion for Fibbonacci, so I'd miss your expectations completely. Why not just ask a direct question on things that you're looking for? If you care about recursion, ask them to implement simple recursive tree walker or something. Equally linked lists are something that in modern languages almost no one will have to manage by hand. If you care about understanding the concept of pointers/refs, why just not asking directly about that.
• pantaloony 6y ago
  Have you tried just having a conversation about pointers and recursion? Does that not work as well (or better)? Kudos for letting candidates know what’s going to happen, it’s just that when I see problems that are clearly just a stand in for “do you know X?” I always wonder why interviewers don’t cut to the chase and just ask directly. “Are you comfortable with recursion? Can you describe it? When does it tend to be applicable?”
  • ajuc 6y ago
    Some people (myself included) can bullshit through such questions pretty well even when we don't know the answers. It's a skill, a combination of reading body language for clues, being confidently vague in the right places and turning attention away from dangerous questions with charisma. You learn it quickly when teachers do oral exams at university :) Code doesn't lie, so I understand why people like to check candidates that way instead of relying on talk alone. I would just prefer if it wasn't a hit-or-miss test on what algorithms you memorized.