11 ms·
Embarrassing code I wrote under stress at a job interview
- zyxley 12y agoThis kind of thing is why the best "code interview" I ever had involved being given a problem (in this case, a small message sending/receiving library) and told to work on it over the weekend.
- azatris 12y agoSame here. I've had two of these and they are just so enjoyable, not to mention the incredibly positive feedback.
- nothrabannosir 12y agoThis type of work-intensive interview gets old real fast when the umpteenth company declines. I fully understand the pros of looking at a more comprehensive, realistic body of work. But if that's what you're looking for; I got a whole Github profile full of stuff to discuss. Spending every weekend on yet another throwaway application until you get hired; I'd rather not. EDIT: removed some bitterness. :)
- yason 12y agoI would assume that a longer programming task would only take place in the very final rounds of interviews, where it's clear that the candidate is a potential hire and the company just wants to be sure that the candidate can do non-trivial work, walk through his code, have it reviewed and discuss the problems found. Starting with a programming problem that takes hours is simply being lazy from the company's part. It's easy to hand out and review but a lot of work for the candidate.
- personx 12y agothat's the dream but there are some companies which send out their pre-baked "weekend projects" after the initial hr screening and I'm talking about large corporations (the new york times for example) which isn't terrible at first but results in lots of trying to look up what practices the company in question follows and prefers and what they are actually looking for personally I really need human feedback rather then 8 hours at my desk guessing and searching for what's being looked for it's one of those situations where I see the value for the interviewer but as the applicant it's completely sucks especially when you have 4 sample projects to write at home while juggling phone interviews and you know having a life/job
- meowface 12y agoIt's the lesser of the other evils, I think. It's very important that the company is transparent about this process before you even apply, though, so that they don't waste your time and their own time. That way at least you know exactly what you're getting into before you submit an application. If you're sick of work sample tests and if the company clearly mentions this, you can move on and apply elsewhere. Matasano (founded by tptacek) does a good job at this: http://matasano.com/careers/ http://matasano.com/careers/
- leovander 12y agoI got four hours to write a mini-game in C++ as long as I didn't use any libraries. I had a blast, especially since it was relevant to the field in which in the company is in.
- ZanyProgrammer 12y agoYeah, but then that gets into the realm of doing a lot of work in your spare time for free, for a job you may or may not get.
- jiaweihli 12y agoAre there any good IDEs for Clojure? If so, most of the stumbling could have been avoided. Coding without one tends to fall into the "ball-of-mud" problem where wrong code is built on top of other wrong code. Or alternatively, is there any way to continuously compile Clojure?
- wging 12y agoEmacs is good for this. A buffer of clojure code in cider-mode can be (re-)compiled easily when you're jacked into a running session (as he does above). Of course, some of the issues the author faced can't be solved by Clojure's compilation step. When his code fails at runtime in the repl, it compiles successfully.
- 6d0debc071 12y agoLightTable has an insta-REPL if that's what you mean by that last bit :)
- virmundi 12y agoFrom my personal experience I love Counterclockwise. Easy shortcuts in Mac make intelligence pissibke. Quick repl with testing. It's pretty great once you get use to load into repl, replay test commands.
- loganmhb 12y agoEmacs has plenty of power here. My preferred Clojure workflow actually involves evaluating Clojure code in a buffer rather than directly at the REPL (so you don't have to do any copy/pasting to edit the code and eval it again). It's easy to build up complex functions piecewise this way.
- MrGando 12y agoHey man, I get terribly nervous too. I've gotten just a bit better with time, if you ever want to talk about it let me know :) Skype n_goles
- droopyEyelids 12y agoPart of this was nerves, part of it was insecurity, and part of it was two people being bad at communicating with each other. Bad situation, but I don't draw any conclusion from it. There are lots of inherently hard things in life that get messed up if you are nervous, insecure and can't communicate. That isn't necessarily an argument against them.
- arthurcolle 12y agoSex immediately comes to mind too.
- dllthomas 12y agoRegardless of the topic at hand.
- sergiosgc 12y agoThanks for the great post. The author, even if he were a bad programmer, is a great writer. The text grabs the reader and makes him sweat in the interviewee's shoes. Live programming interview tests are rubbish, because: a) They produce a huge rate of false negatives. People who do not "interview well" flounder in a programming task with someone peering over the shoulder. b) They can only test "algorithmic" tasks (for lack of a better definition). Most programming is not algorithmic, it's higher level: glueing already written libraries, with very light data manipulation or validation.
- nowarninglabel 12y agoI'm not sure I agree with you on this. Live programming interviews should not be the sole quality of judging someone, but if we've first given them a coding exercise to do on their own time and they passed that, then it's useful to have them come in and do some coding to show that they can walk through their code and add additions/fix bugs to it without problem. Which on that same note, I'm not sure why you would say they can only test "algorithmic" when we can do like I just described and have them for instance code a new feature in an existing code project of theirs. That said, I agree with everyone else that they shouldn't be rushed, should allow the interviewee any and all resources they care to look up, and should shoot for "real-world" exercises over made-up scenarios.
- sergiosgc 12y agoI was speaking about live programming, during the interview. I much prefer asking candidates to write a task on their own time, and then use that code as basis for conversation during the interview. You get all the insights on how good a programmer he is, without the sweaty palms effect.
- yoklov 12y agoB isn't universally true. Most of what I do on a given day does not fall into that category, really at all. Same applies for most people I interview, with few exceptions.
- 12y ago
- jlcfly 12y agoThis sort of interview is insulting. There are real problems to solve in business and elegant solutions to the 'next number in sequence' isn't one of them.
- hackerboos 12y ago"Yesterday I went to a job interview, at a company in New York that had once built their stack (for managing online advertising) in Ruby but who are now transitioning all of their stuff to Clojure." I would have probably walked out or at least snarkily asked them if these types of algorithms are what's done day to day. The answer more than likely being no.
- recursive 12y agoThere's not really time in a 30 minute interview to pose a real business problem, much less have any meaningful representative work done, by which to judge the candidate.
- rhizome 12y agoWhy would you only allow 30min at the stage where the candidate is writing code? 30min is for the phone screen, in-person is when you're serious.
- ianstallings 12y agoAgreed. If I have you in the office I may talk to you for the rest of the day and I schedule accordingly.
- rhizome 12y agoAnd if you're LinkedIn you never communicate with them again.
- learc83 12y agoAnd by sticking to that limitation, you're seriously undermining the predictive power of your interview.
- bra-ket 12y agothat's why the top topcoder coders use java under pressure
- seanwilson 12y agoI'd be more comfortable coding something more concrete and familiar than Collatz and Happy number sequences personally.
- jacquesm 12y agoYou're liable to see Collatz sequences and such in interviews because the interviewers can look up the answers to project Euler problems online to see how your solution compares to those coded up by others.
- theVirginian 12y agoNo matter how badly I was doing in the interview I would walk out when I saw the engineer pull out his phone and start checking messages. How embarrassing for the company to have someone that disrespectful conducting interviews. An interview should be a conversation between potential peers and him pulling his phone out is just as rude as if you had pulled out yours because you were bored of hearing about the company.
- jacquesm 12y agoI even do this IRL. If I come to visit you or you come to visit me then that takes precedence over social media. If that's not the case I'll be more than happy to walk. It's rude beyond insult to do this during a job interview, whoever decided that was ok to do is basically sending you a very large warning message that even hiring is a job that does not require full attention.
- alok-g 12y agoCounter opinion: I have done this in the past to signal the candidate that I am not watching over his shoulder, just to help the person relax as he figures things out. I feel glad now that I have done this after explicitly indicating this to the respective candidates.
- eranation 12y agoAwesome post. You have some really good memory! I wish I would see more post interview analysis in this depth here in HN. Great read. P.s. You are not a bad programmer... Pressure can mess your mind. My secret to finding great developers that everyone else misses is by making them feel calm (giving them an easy problem and giving them encouragement so interview stress becomes less a factor, best way to find good developers who just are bad at interviews)
- leovander 12y agoNot OP, but I have going through a string of interviews. Hopefully I can post a couple soonish.(In the middle of studying for another one)
- tinco 12y agoVery nice write-up, I can just feel the stress. Regarding the interview, there's this trick I learned that presenters do when they come on the stage. Instead of focusing on the audience and their talk immediately, they first drink a glass of water slowly. It lets you set your own pace, and deal with the first high of adrenaline a little. In this case, they asked you a question and you immediately fired up a repl and started typing away as if it's a race. But if no one is holding a stop watch it's not really a race. If you're going to have to do this kind of interview more often, perhaps practice on your generic problem solving strategy. If it were me, I'd probably ask for a piece of paper, and then write down the components of problem on the highest level, then drill down the details of each component. At each level of detail check with the interviewer if the requirements of the component match their intentions. When you're confident you've got the algorithm down on paper, then you can start on working it out in the REPL. Also, I'm not a LISPy guy so no idea how you usually do this, but those first three mistakes you made were horrible. Obviously you were nervous, but these kinds of mistakes don't happen if you have a good IDE and disciplined code style. You can't miss matching brackets if every opening bracket starts a new line and a new indentation level. You can always clean up the new lines when your algorithm is done. Practice and preparation are the best countermeasure to stress. Not that I agree with this interview style at all by the way. You are most likely an excellent developer, and if they don't decide on hiring you they probably are making a big mistake. If I was hiring Clojure people I'd be surprised I'd get someone that would work a REPL like that without internet reference at all.
- intelliot 12y ago> Interviews are weird: the pressure of time, and not being able to look things up, distorts the code. In the interviews I do, I tell the candidate that: 1. There is no time pressure. Work at a normal pace, as if you were working here. This is not a speed test. I don't expect you to finish. I mainly want to know how you think. 2. You should look things up. Behave the same way you would when coding at home. Use Google, Stack Overflow, documentation, etc. This probably works better for the interviews I give because the problem is not implementing an existing algorithm. It's a realistic task, something that we've actually built on-the-job.
- voltagex_ 12y agoCan I interview with you? Normal tech interviews make me physically ill.
- eru 12y agoYou might also want to talk to Matasano. They are really keen on work sample tests.
- jerematasno 12y agoNote that our work-sample tests are, not-insanely, done in the comfort of your own home, at your own pace, on your own schedule, and represent the work we actually do. As co-head of recruiting for NCC US (aka head of recruiting for Matasano), I think the answer to the in-person interview question of "write code to do this," is "thank you for your time, I'll see myself out."
- mianos 12y agoI wish, I did a google code interview once. The guy said we had only a short amount of time. When I solved the first one really quickly he told me, 'oh, ok, can we do another puzzle we don't have much time'. Suffice to say I went down in flames somewhat like the topic.
- serve_yay 12y agoI don't think that's good enough. It's unfair to ask candidates to write code on the spot.
- learnstats2 12y agoI find the % operator (div and mod) essential - and not only in interview questions. As far as this interview question is "Do you %?", I like it as a test. For the rest, I feel sorry for the author. Good luck next time :)
- gajomi 12y agoI feel compelled to point out, as a native English speaker familiar with this sort of mathematics, that the phrasing to "go infinitely" doesn't make much sense. Or, if it makes sense, it is at least ambiguous (with plenty of room for the interpretation "diverges to infinity"). The clarification that the author makes about looping (or even better, repeating) is much clearer.
- rdtsc 12y agoAs a non-native English speaker who also interviews candidates, I try make sure to see if the candidate understood and always say it in another way -- For example after saying "go infinitely" (which is a silly way to phrase it) I would also say "it basically loops around", "creates a cycle". Maybe even draw out a little example on a whiteboard.
- jonathankoren 12y agoI have to agree. Reading this article, made me think that the interviewer is either a dick, or bad at conducting interviews. The whole thing seemed to turn on using a word in a nonstandard way to deliberately obscure the problem definition. That's just stupid.
- stevepike 12y agoThis is a tricky problem. Here are some things I've found helpful on the other side of the table: - Pick a real world task (e.g. text munging). - Suggest in advance that they bring a laptop with their preferred work environment. Allow any reasonable language if you're willing to train them on your stack. - Write the problem down ahead of time. Have someone else at your company read it. - Do the problem yourself. Ballpark your estimate for a great candidate at 3x the time it took you. - Tell them there is no penalty for using stack overflow over the language docs. - After you give them the problem, give them a few minutes in peace (leave the room) while they think it over. Talk about their approach out loud before they begin working. - Ask them to spend 5-10 minutes re-factoring their code once it's working.
- spectre256 12y agoThat 3x to do it yourself time seems excessive, but we once did exactly the same thing at a previous company. We chose problems we knew, worked with tools we knew, in a comfortable environment. Even if you aren't intentionally trying to do the opposite, which unfortunately many interview techniques, like whiteboard coding effectively do, conducting interviews where a candidate is comfortable and at their best is ridiculously hard.
- stevepike 12y agoAgreed, but it's worth trying to do well. You get a lot of information out of how someone handles programming live vs. what you get in a homework assignment.
- UnoriginalGuy 12y agoI love your list. Full of great ideas for productive interviewing. I'd further expand this one: - Write the problem down ahead of time. Have someone else at your company read it. You also need to have someone else (not you) at the company complete the problem. Ideally have a "model employee" do it. If they are unable to "pass" your interview question (under near-interview conditions) then maybe the question is a bad indicator. Keep in mind that asking a co-worker to complete it is much lower stress/easier for them than a candidate, as they likely have near nothing on the line (maybe reputation). So if they find it hard, an interviewee will likely find it near impossible.
- mpeg 12y agoI have very little love for code interviews of this kind. Here's an alternative I would propose to hiring managers: Give the candidate a research paper in PDF, then ask them to implement the algorithm described there in code. You get the same feedback on whether they can actually code, and what kind of code they write, but it takes the pressure off having to think of what kind of algorithm to use, what the big O complexity of it is, and a thousand other factors that will probably never relate to what their day job will consist of.
- celadon 12y agoFor some companies/teams/hiring managers/interviews, having someone who can reason about big-O complexity and design their own algorithms is important and necessary. There won't always be problems that have a preexisting algorithmic solution.
- zak_mc_kracken 12y agoMy dislike of dynamically typed languages went through the roof reading through this article.
- slowmovintarget 12y agoYour dislike for an interview question that tests knowledge of number theory instead of programming is what should have increased. Writing Clojure functions under pressure is like gardening at 55 MPH. You're trying to make something still and beautiful and overdoing it (or missing entirely) as you drive by.
- zak_mc_kracken 12y agoMy point is that most of the runtime errors that the OP had to suffer through would have been caught at compile time with a statically typed language (STL). No interviewer will ever ding you for writing code that doesn't quite compile yet, because it's just part of the process of writing code in an STL. However, with a DTL, every time you run your program and it crashes, the interviewer mentally takes away points. Which is not really fair since it's how DTL's work, but it's a reality: a runtime crash is much more damning than a program that doesn't compile. Stepping back, I think the simple fact that the company this person went to interview with recently switched from Ruby to Clojure would have already been a huge red flag to me.
- zak_mc_kracken 12y ago> Your dislike for an interview question that tests knowledge of number theory "Number theory" is a bit exaggerated. This is a warm up question to see if the candidate is able to decompose number 530 into digits five, three and zero. If you can't do this in a few minutes, you're probably out of the running from the get go.
- seba_dos1 12y agoOn my first job interview, despite having already quite a bit of experience with personal and free software projects in various languages and frameworks, I somehow managed to struggle with FizzBuzz. I didn't know that it's supposed to work as a basic filter so I was looking for some catch thinking that it cannot be as easy as it looks. As I couldn't find any I figured out I should go with trying to write the prettiest, most elegant and clever way, started fiddling with modulo division and managed to screw it up under nerves and the fact that I was writing it on paper with no ability to run and check. Also, despite of being told "use whatever language you want", for some irrational reason I worried about correct syntax, which probably added up to my nervousness. Fortunately, they didn't stop there and I was able to do harder tasks better later on ;) I reacted pretty much in the same way on my driving exam. Both that interview and that exam weren't telling you anything about how I actually program or how I actually drive - even under extreme conditions. Being judged is just a completely different experience that makes me behave in completely different way.
- XorNot 12y agoI had an interview a few days ago, and just punched the problem I was asked to do in Python into iPython. Immediately did it a much simpler way, and also spotted my logic error (if you want deciles you actually divide by 9, not 10, since you have 9 columns with 10 edges). Took me about 2 minutes to do. Whereas in the interview I wrote entirely the wrong thing initially, then went "oh wait, that makes no sense".
- mockery 12y ago"I’m suddenly self-conscious about the prettiness of my code — it doesn’t matter if I can solve the problem, since I’m also competing against candidates who can solve the problem, so the real competition is probably about how elegant and idiomatic our code is." This is an incorrect assumption, at least when I interview people. A live coding interview has (almost) nothing to do with the "quality" of your code, and doesn't necessarily even demand complete correctness. It's about observing your process, and trying to simulate what it would be like to work with you: Do you approach a problem with caution until you're sure you understand it, or jump in head first and start writing code you hope is correct? Can you verbalize your thought process and communicate it to others? How good are you at reasoning about the runtime behavior and correctness of your solution? Do you consider edge cases and naturally want to test them? Things like that are won't show up in a take-home coding test, and tell me a huge amount about what kind of programmer you are, and whether I want to hire you. See: http://www.yacoset.com/Home/signs-that-you-re-a-bad-programmer http://www.yacoset.com/Home/signs-that-you-re-a-bad-programm... - there's a lot of truth to this article, and many of these flaws will be glaringly obvious in a live coding session. And yes, of course some people interview poorly or are just having a bad day. That's unfortunate, but I'm not about to give up a powerful interview tool just because it can have false negatives. Until I find a divining rod that will point out the best programmer in a room, asking a candidate to write some code is the fastest way to learn what kind of programmer they actually are. (And also immediately weed out people who can't actually write real code.)
- usaphp 12y ago> "It's about observing your process, and trying to simulate what it would be like to work with you" But coding at an interview under stress and time pressure has nothing to do with a work process in a normal company, unless you also force your employees to work under stress and strict timelines with you sitting behind their shoulder and watching every keystroke...
- celadon 12y agoIf you aren't prioritizing for code quality and beauty, do you also explicitly tell candidates that? I think it's very difficult for candidates to understand exactly what the interviewer wants—and, of course, all interviewers are different. I think that, for better or worse, many people worry that they need to perform perfectly during the interview and actually deliver a perfect solution—instead of just approaching and developing a solution. I'm a designer, not a programmer, but I've found that I interview best when I get explicit guidance from the interviewer. "I want to hear more about x, don't worry about y. What I want to learn about you is z." It makes the interview feel like a collaborative process (especially helpful when interviewing people you will work directly with, as you're pre-selling them on the team dynamic they'll experience!). It allows me to provide the information the interviewer needs most, in order to effectively evaluate my abilities and fit. It also clarifies for the applicant what things are actually worth stressing out about.
- rcthompson 12y agoThis is a sentiment I hear expressed a lot: > But I wanted to appear smart, so I didn’t express any confusion. And I don't get it. When I ask questions, if anything, I get told that I seem smarter for it. Asking questions is a sign that you're paying attention and actively trying to understand things. I don't think I've ever had anyone question my intelligence for asking questions for clarification. (I'm not trying to criticize the OP in particular for this. I've heard it from a lot of places, and wanted to point out the fallacy.)
- lotyrin 12y agoYep. This has been the primary source of frustration for me in my communicating with software developer peers. I'll explain the task I'm delegating carefully: why it exists, the big picture of how it should be implemented, what tradeoffs I feel like will need to be made, and what corner cases are likely to exist and they'll nod like they understand to defend their ego then go and implement roughly none of it.
- jmilloy 12y agoIt makes testing for this behavior important, and it sounds like the OP exhibited just this behavior, doesn't realize it, and blames the interview technique despite it ascertaining exactly what it needed to.
- Klinky 12y agoPerhaps you've just never been criticized or had someone look at you like you were stupid. Maybe you've never had someone dismiss your concerns immediately, give you a rushed response which has nothing to do with your question, and act like they had to do the work for you. This happens all the time, in all areas of life. I am impressed you've never run into it.
- rcthompson 12y agoThere's a difference between "I think you're stupid because you're asking questions" and "I don't have the time/patience/interest/whatever to answer your questions." I've certainly encountered my share of the latter, but I don't interpret it as an insult to my intelligence. (Or even worse, there's also "I don't like your questions because my idea won't stand up to close scrutiny." I get that every once in a while too.)
- S4M 12y agoI think the OP made the mistake of trying to solve the problem directly, and when he got errors, he got nervous which made him get more errors. Instead the right strategy would be to think aloud "well, how do I get the digits of a number? first, cast the number into a string then try to see if I can treat it as a list. Ok, let's try (seq (str 10)) on the repl....". Having an instant feedback and being able to no exactly if a small instruction works or not would have helped him to focus better, and avoid nervousness.
- shortly 12y agothat he did not take this approach makes me think the candidate is inexperienced, and probably coming to clojure from an imperative mindset.
- tonyarkles 12y agoYeah, that's exactly what I look for in problems like that. How does this person approach the problem? How do they decompose the problem? For that specific problem, I'd probably be satisfied if they wrote a function that took a number like 341 and returned [3, 4, 1], and then mumbled something about a set or a hash (or a list even) for storing the already seen numbers.
- logicallee 12y agoTechnical interviews always get your hopes up, and then you accept the job and over the next six months not once does an engineer come into your office and ask you if you know what a Collatz number sequence is, then explain it to you and ask you to write some functions that would allow him to find the longest iterations through the Collatz sequence, given a set of starting numbers. It's practically bait and switch. (EDIT: this was actually a joke...)
- sdenton4 12y agoI recently had a good long discussion with a fellow engineer about the number of sequences of coin flips with no streaks longer than length k. (turns out the answer is a generalized Fibonacci number!) So it /can/ happen...
- bkcooper 12y agoI related to this a lot. Having somebody watching over my shoulder (especially in a judgmental capacity) means that when I inevitably make some stupid minor mistake, instead of just laughing it off as I normally would, I get anxious. This then increases the chances that I will make another mistake, and so on.
- fsk 12y agoAlso, the interviewer didn't even know his own question. As I understand it, you are taking the sequence n -> (sum of the squares of the digits of n) First, the sequence never diverges to infinity. For example, 9999999999 -> 9*81. Second, not all numbers converge to 1. There is a stable cycle that does not include one. Consider 4 -> 16 -> 37 -> 56 -> 61 -> 37 -> ... So, any positive integer either 1. Converges to 1 2. Converges to the stable cycle I just mentioned above. So the interviewer should be fired for not understanding the question he was asking.
- 6d0debc071 12y agoInterviewer said it would converge either to one or infinitely: 'The next sentence of English is where the problem started. I _thought_ he said: “The sequence will either go to one or to infinity.” but he actually said: “The sequence will either go to one or infinite_ly_.”' [My emphasis] (Firing's also a bit harsh for getting an interview question wrong)
- fsk 12y agoThat also is incorrect - the sequence either converges to one or a stable cycle - not infinitely. That's also a horrible question for illustrating functional programming style. It would be much more efficient to have a simple loop caching the array n->f(n) and then finding the ones that converge to 1.
- deleted 12y ago[deleted]
- int3 12y ago... the interviewee misunderstood the question. The interviewer understood it just fine.
- deleted 12y ago[deleted]
- solve 12y agoLooks like more of an advertisement against Clojure than anything else.
- Matthias247 12y agoAt least like an advertisement against coding anything directly in a REPL. Typing in an editor (probably with Send-to-repl functionality) would have caught a lot of errors. But yes - doing it with a proper IDE or even a statically typed language would really had helped to focus in the problem and not on getting-it-to-run.
- mavidser 12y agoI remember that my first interview was kind of similar. Though it was a phone interview on Hackerrank Codepair. I was really nervous, and since it was a phone interview, I tried to speak my thought process, which didn't quite work out due to me constantly stammering. So I just took to typing all the time so that my interviewer wouldn't think I was taking too long coming up with a language or copying answers. I started making silly mistakes like using `int sum=0` in python. I took the input as a number, converted it to a string, and then further converted it back to a number, and did mathematical operations on it, trying to solve the problem. Every time I thought I did it, it would get stuck in another case. Ultimately, the interviewer deleted 50 lines out of my 60-line code, and just added a print statement on a variable I was already using for storing things temporarily, which turned out to be the correct answer. Needless to say, I blew the interview. I haven't done an interview since, and I'm gonna be up for it very soon. I'm not sure if I'd do better this time, but I'd be ready with a glass of water, and try to be as relaxed as possible.
- leovander 12y agoHow long do you normally wait between interviews?
- AndyD1st 12y agoInteresting article, but ironically the interviewee's solution is still incorrect at the end of his post. You'll notice that he only squares the first digit, and then adds the second digit rather than squaring it. E.g. when he calls (happy 97) it prints 88. However, that's 9^2 + 7, when in fact the answer is 9^2 + 7^2 = 130.
- learc83 12y agoThe way I see it, you can master coding interviews by practicing solving small problems quickly under pressure. But this kind of practice takes time--time that is probably better spent mastering the skills you'll use day to day. The studies that get brought out every time this comes up are very clear. The best predictor of future success is a work sample test. Solving a bitesize problem in 20 minutes while someone watches over your shoulder is not a work sample test--it's about as far away from a work sample as you can get and still call it programming. At the very least why not let the candidate work on the problem on their own for 30 minutes and then check back in. I've said it before, the best interview process I've ever heard of is this: Pair the candidate with an interviewing engineer, give them an hour or two to solve a problem as a team. The interviewer isn't an adversary; their job is to assist the candidate like they would if they were working on a real problem. Repeat this process if necessary. Get everyone together and talk about past projects the candidate has worked on. Have the interviewers evaluate the candidate, and make your decision. You know whether the candidate can code, and you've removed the adversarial nature and unnecessary stress from the interview process. Most importantly, you got to see them work in a much less artificial environment that's closer to what they'll be doing day to day.
- PublicEnemy111 12y agoI once had to implement a simple API during an interview. I'd done it many times, but the stress of having an interviewer breathing over my shoulder made it a painful experience and I completely flopped. Not to mention there was another interview trainee in the room. I can write white board code with ease as those are almost always two way conversations
- mikekchar 12y agoWhen we do coding at our interviews we do ping-pong pair programming. One of the things we want to see is if the person can deal with actually doing TDD. Usually there are 2 of us and one candidate. We explain the problem to the candidate and ask, "Do you want to write the first test, or shall we?". We've done the problem hundreds of times so we know a very, very simple first test that will lead forward. This allows the candidate to "warm up" a bit before they have to start thinking hard about the problem. Sometimes they hit the ground running and are keen to write the first test, which is also fine. The idea is that we switch back and forth. One of us writes a failing test, then the candidate writes the production code. The candidate then writes the next failing test and one of us writes the production code and the next failing test. If the candidate gets stuck, we usually try to talk through the situation and if they are really stuck, one of us will offer to take over. The candidate is allowed to look things up on the internet and even ask questions. Often we will suggest things. For instance, after the candidate writes some production code, we might say, "That works well. But how about refactoring it using inject," for example. I often use a pomodoro timer set to 20 minutes. We'll do as much as we can in the first set. After that first set we'll ask the candidate how they think it is going. We'll offer some advice about technique and such. If it was an absolute disaster (happened a couple of times), we'll just leave it there and thank the person for their time. Otherwise we'll ask if they are up for another round. Usually the first set is pretty bad because the person may never have done real TDD before, or may find the ping-pong awkward at first, or may be very nervous. Talking about how they are feeling at the break usually helps and the second set is much, much better. After the second set we'll ask the candidate how they think they did. I think this is important because if the candidate says, "It went really well" and it was actually awful, then we have a pretty good idea of their skill level. If they say, "I wasn't really happy with my performance, but I enjoyed the style of programming", then we will have to take into consideration a variety of different factors to see if we believe that the person can do better. If the person says, "I really didn't like working that way", then we can rule them out as a candidate regardless of their skill level (also happened a few times unfortunately). The feedback we've gotten from candidates on the process seems to indicate that they really enjoy this interview style. I think it removes a lot of the spotlight from the person and allows them to relax a bit. Especially having us come in and help out in sticky situations allows the candidate to get over stupid blind spots (like the converting between string and integer in the article). So far, I think it has helped us spot potential in a few people that I'm sure we would have overlooked using a more standard, "Here, solve this problem" approach. On the downside, there is still considerable room for improvement. Language lawyers (know every detail about the programming language but are still poor programmers) can often look very, very good in this kind of test. Similarly, inexperienced but very talented people can often be frustratingly mediocre because the unfamiliar method of development can hamper their style. You need to be very aware of the amount that the person improves during the interview. One final comment about this approach. We have occasionally been in a situation where we said, "I'm not sure how good this person is. They seem like their skills are fine, but whether they will be really excellent, I don't know. However, it was really fun programming with them." In those cases we have hired the person and never regretted it.
- ricardobeat 12y agoGoing on a tangent, but that Clojure code looks incredibly convoluted. Compare to this: next = (n) -> "#{n}".split('').reduce ((p,c) -> p + c*c), 0 happy = (n, set = []) -> return false if n in set return true if n is 1 happy next(n), set.concat(n) console.log(n, happy n) for n in [1..100] That complexity certainly makes it harder to solve the problem under pressure. This is really an example of an interview process that focuses on specific language skills and not actual programming abilities.
- grayclhn 12y agoTo be fair, from the description of the job it looks like language specific skills matter.
- QuercusMax 12y agoWhat language is this?
- nadaviv 12y agoCoffeeScript.
- wging 12y agoThe Clojure in the article isn't idiomatic, as the author admits. You could do something very similar in Clojure, though the details are different. In fact when I tried this problem my solution was shaped about like yours.
- deleted 12y ago[deleted]
- deleted 12y ago[deleted]
- blakecaldwell 12y agoAnother idea, if you really hate the pressure of interviewing, is to ask for a medium-sized project that you'd hand in the next day. That's more real-world scenario, anyway. Try it - I've done this!
- benwaffle 12y agoIn scala: def happy(n: Int) = n.toString.map(_.asDigit).map(Math.pow(_, 2)).sum.toInt def find_happiness(n: Int, seen: List[Int]): Boolean = { if (happy(n) == 1) true else if (seen.contains(happy(n))) false else find_happiness(happy(n), seen :+ happy(n)) } I think OP's answer is wrong
- detrino 12y agoI think the author may be missing the point of this exercise. Solving this problem requires the following things: 1) Decompose a number into digits. Less experienced candidates will likely convert the number into a string and then the characters back into numbers while more experienced candidates will tend towards a small loop using div and mod. 2) Use some kind of library to insert and test membership in a set data-structure. Less experienced candidates may not be able to do this without stackoverflow, big red flag. 3) Some basic flow control wrapping it all together. Less experienced candidates may fail here similar to fizzbuzz. The interviewer likely thinks these things are a good proxy for the quality of a candidate. For example, the author would have failed #1 even without miscommunication/stress/time constraints.
- pete23 12y agoEuler addicts. Although some function decomposition of the problem would have been nice to see!
- istvan__ 12y agoAn interview that forces you to do something that is otherwise not part of your daily routine and measures how good you are based on that is bad. I understand that you need to get insight into the skill of the candidate but forcing her to work on an editor she does not know, giving limited time etc. is probably not the best way to get that. I used to interview software engineers for a big company and we usually gave them a problem that they could solve in 48 hours using anything they want (internet, library etc.) and we just asked them to explain their solution in person during the final round of interviews. You are interested in how good the candidate is not how fast she can fail a synthetic test that has nothing to do with the actual work you are doing.
- sudeepj 12y agoI won't put a candidate in a situation which I myself won't want to be in. While interviewing, I tell the candidate the problem and then leave the room. He is alone and comfortable (I hope). I check back after 30 min. If not done I still give him more time.
- Decade 12y agoPay me a fair wage for my trouble, especially if I succeed at the problem, and maybe I'll feel a lot better about the coding exercise.
- d0m 12y ago2 things that I think would make your life so much easier.. 1) Agree with the interviewer before starting to code on the algorithm and problem. I.e. You could say I need function X that would be used like such, and function Y that would loop through such and such. Even better is drawing a high-level example on the board. That way, the interviewer knows that you understood the problem and can be systematic about it. (If you don't have a whiteboard, just write in comment at the top, whatever) 2) Once you start coding, start small.. especially in the REPL. I.e. instead of starting with the whole function, start with the string, then separate it in digits, then sum it up, then work from there. That way, if something doesn't compile, it's perfectly clear what step it was and once you have your function, you're 100% sure it works. TDD style.
- jcadam 12y agoI am horrible at these kinds of interviews. I remember once being so nervous that I completely blanked. I'd been asked to reverse a linked list. A very simple task, one I'd even practiced a few times in various languages prior to my interview and should have been able to breeze through. But I froze. My hands were visibly shaking as the interviewer stared at my back... I shut my eyes tight, trying to think through the problem (I knew this was a simple task, and I was frustrated that I somehow couldn't recall the solution). At first I tried to write out a recursive solution to the problem, but my anxiety-riddled brain just couldn't cope with recursion that morning. So I erased the board and started over trying to find an iterative solution. That went even worse. "Um, I need to repeat this block of code, I think, maybe. There must be some way, some kind of construct that causes a block of code to be executed several times, almost as if one were looping through the code." AGH! Think! But I was coming up empty, I searched my memory, ready to seize on the first seemingly helpful thing I could find. And so my mind wandered back to a time when I was about 8 years old, learning to program for the first time on my Apple II. I had just discovered the magic 'GOTO' command, which was the perfect tool to cause uncomplimentary messages about my older sister's hygiene to scroll down the green mono display for all eternity (or until someone hit Ctrl-C). So... I completed my solution on the whiteboard using a GOTO. The interviewer put his face in his hands and began laughing. Eventually, he stopped and said "Um, ever heard of a for loop?" "Well.... yes."
- Jach 12y agoI have a dream I'll one day be asked to interview someone, and get to try out my unconventional idea... (Or have it done to me one day.) I hate standard coding exercises, and I expect the candidate to have already been vetted for being able to code by either having some open source work or if none is available being given a take-home fizzbuzz-ish problem. My idea is to pick a problem off my own personal list of things I'd like to explore, things I'd like to reinvent code for from high level descriptions if I had more time/discipline (for example drawing voronoi diagrams), and do this alongside the candidate, so together we can attack the problem with a whiteboard and a shared computer or two for wikipedia/pseudo-code/real-code/etc. We may not get very far in just an hour, we might not even get to code, but it will be good information for both myself evaluating the candidate and the candidate evaluating me about how we collaborate on a problem neither of us knows the complete solution to in advance.
- chetanahuja 12y agoI have ranted before about the cargo-cult style used in hiring processes across our industry. Most of the "write-code-on-whiteboard" and "how-many-golf-balls-a-school-bus" style of bullshit has been handed down through folklore from old Microsoft interview techniques from the 80's. Now that I'm running a company, I've used the opportunity to define policies by basically banning those practices from our engineering recruitment process. Instead, we give a problem to the candidate (of the sort that we might be solving in day-to-day work ... not "create this data structure and be sure to use recursion horse-manure) and ask them to take the whole day or more if they want, in their own environment (home, cafe, wherever they find focus), as if this is a real problem they might be solving for work, and produce working code. Now I know this is not perfect, but I'm convinced this is way better than the traditional coding interview.
- zak_mc_kracken 12y ago> I've used the opportunity to define policies by basically banning those practices from our engineering recruitment process. Good for you but FYI, brain teasers have been banned in most companies in Silicon Valley for a solid decade. The fact that they are no indicator of the quality of an engineer candidate is a well known fact.
- PopeOfNope 12y ago> Good for you but FYI, brain teasers have been banned in most companies in Silicon Valley for a solid decade. I think you mean "specific, but highly visible companies" instead of "most companies." Having recently gone through a round of interviews, I can tell you the brain teaser is alive and well at quite a few hiring companies in SF and SV. I think people know they don't work, but hiring is difficult and most people are lazy, especially at companies where the interviewers would rather be coding.
- chetanahuja 12y agoWell not quite. I myself have been subjected to brain teasers and puzzlers in technical interviews well within this 10 year window. But yes, I do believe the industry is moving away from the puzzler type interviews slowly... especially after Google publicly disavowed them recently. http://www.businessinsider.com/google-hiring-practices-interviews-2014-7 http://www.businessinsider.com/google-hiring-practices-inter... I would also like to reiterate the cargo-culting part of my criticism and expand my rant a bit to point some fingers. One of the worst things that happened is the pernicious belief (mostly popularized by Jeff Atwood in his blog[1]) based on an non-peer-reviewed, and later retracted study[2] that implied that programming ability is a genetic trait, instead of just a skill and a craft like any other. The same blogger is also responsible for popularizing the idea that most candidates for engineering jobs are charlatans trying their best to fool you into hiring them. To be clear, I'm not implying that this one blogger is responsible for all the ills of the industry recruiting practices. But I don't think I'm exaggerating when I say that the interview part of the process for engineering hires in the industry is far more adversarial than it needs to be and those with influential soapboxes who've brought us here have to accept some responsibility. The state today is, that far from the adversarial process being a necessary evil, it's actually a point of pride for certain companies (some of which I've worked for in the past). One can only hope that these attitudes change over time like those about the brain-teasers. [1] Here's Jeff's blog http://blog.codinghorror.com/separating-programming-sheep-from-non-programming-goats/ http://blog.codinghorror.com/separating-programming-sheep-fr... published in 2006 [2] Here's the surprisingly detailed and personal retraction from the author of the original study... published last year. http://retractionwatch.com/2014/07/18/the-camel-doesnt-have-two-humps-programming-aptitude-test-canned-for-overzealous-conclusion/ http://retractionwatch.com/2014/07/18/the-camel-doesnt-have-... I've heard countless people in the industry repeat this belief of a programming gene to me over the last few years. They may all not remember where they originally heard this but those who do invariably point to Jeff's blog rather than the original study itself. I can only hope that Jeff uses his platform to beat the drum of this retraction as loudly as he did for the original mistaken study.
- sopooneo 12y agoIt's weird. I have the opposite experience. I do not have a CS degree. I do not know formal algorithms or data structures. But I have technical aptitude and significant stage time, including in front of drunk audiences from another life that didn't exactly lead to stardom. So I enjoy technical interviews because what limited knowledge I have is instantly accessible and I thrive in front on an audience. So it seems here is a an instance of where life was not fair... in my favor. But now I'm in a position to hire other people. So I don't want to judge them in the same way I was. I want to find out who's got the chops completely apart from who can dance on cue.
- deleted 12y ago[deleted]
- sopooneo 12y agoIt's weird. I have the opposite experience. I do not have a CS degree. I do not know formal algorithms or data structures. But I have technical aptitude and significant stage time, including in front of drunk audiences from another life that didn't exactly lead to stardom. So I enjoy technical interviews because what limited knowledge I have is instantly accessible and I thrive in front on an audience.
- cxseven 12y agoOut of curiosity, what's the best solution to this? One thing I noticed is that every loop will pass through an entry less than 100, so you only need to remember the last 99 numbers below 100 when checking what's been seen-so-far. You could also precalculate or cache the answer for 1 through 100 to save rerun time. But maybe a little bit more math would reveal much better optimizations.
- sukilot 12y agoA lot of the trouble here comes from Clojure's cryptic function names and non-static-typing making it hard to get work done. The only real mistake I see a unprofessional choice of language. The mistakes and successful debugging are totally fine.
- jmilloy 12y agoThe important mistakes that the author here made were assuming the interviewer wanted him to work quickly, without looking anything up, without asking for clarification, and without collaboration. The author seems to still be making this mistake by assessing his performance by the code he wrote, rather than the (lack of) dialogue he had with the interviewer. Consider that the interviewer has now seen that this person will choose to, without clear understanding of either the goals of the task or the task itself, work alone as though he must solve the problem in isolation in order to prove himself. The most important thing that a candidate needs to be able to do on the job is discuss expectations; failing to do this in the interview is more egregious than any compiler error. Another important thing is to understand the problems they are working on; failing to even discuss the problem is more egregious than any compiler error. Another is collaboration and humility; you can demonstrate these skills in a coding interview as well. This interview demonstrated many more important indicators of a poor fit than typing ones. Just because you pose a coding problem doesn't mean you're unable to assess candidates on the things that matter.
- metaphorm 12y agoYour code isn't embarrassing (its just rushed/nervous). Their interview technique is embarrassing.
- nadaviv 12y agoCoffeeScript solution: (sorry, couldn't resist trying!) happy = (n) -> sum = 0 while (sum += Math.pow n%10, 2 ; n = 0|n/10) then sum happyness = (n, s=[]) -> (n is 1) or (n not in s) and (happyness (happy n), [ s..., n ]) console.log n for n in [1..100] when happyness n Edit: and a JavaScript one: function happy(n) { for (var sum = 0; n; sum += Math.pow(n%10,2), n = 0|n/10); return sum } function happyness(n, s){ s || (s=[]) return n==1 || !~s.indexOf(n) && happyness(happy(n), s.concat(n)) } Edit 2: And the golf version: function h(n,s){for(s=0;n;s+=Math.pow(n%10,2),n=0|n/10);return s} function H(n,S){return n==1||!~(S=S||[]).indexOf(n)&&H(h(n),S.concat(n))}
- dba7dba 12y agoI took 2 different tests for 2 different companies. One was a very simple task, setting up a server as a customer would at an ISP using WebMin type tool. Really simple stuff. Guess what. I couldn't figure it out in time. Maybe because I had been consciously staying away with gui stuff to stay sharp with cli. Or maybe the proprietary tool the ISP was using was very unintuitive. Maybe the suit and tie I put on for the first time in 2 years got to me. Either way, had I NOT been in an interview setting, I would've figured it out. But with this interview, I couldn't figure it out. In the 2nd company, I was giving an online test using https://trueability.com/ https://trueability.com/, to complete from home. Set amount of time to complete some test scenarios. Far more difficult stuff than setting up a small web server at an ISP. And I would say it was a far more realistic test of my skills. IMHO, interview should really only focus on compatibility, not actual tech skills. If your company is really spending time on tech skill test DURING interview (especially onsite), you are doing it wrong. just my 2 cents.
- Decade 12y agoI hate TrueAbility. It gives you so little time to do the test, and for example the Linux skills test is really about your intimacy with the dark corners of an outdated version of CentOS instead of anything current. Then, if you bomb a test, it doesn't allow you to try again.
- dba7dba 12y agoI love TrueAbility. You are not expected to finish 100% or even 80% of the given tasks completed during the test. I read online somewhere that he/she got barely 50% done but still got an interview. The recruiter giving out the test on TrueAbility is looking for how you solve the problem, not how much of it you solve. Also, the way I understand it, you can keep a personal profile on TrueAbility and point recruiters to it for them to review your tech skill level.
- personx 12y agoI don't fully understand the direction you were going with some of the solutions, something like this would work no? (defn digits [num] (let [ x (map str (str num)) s (map read-string x)] (apply + (map #(* % %) s)))) I do think the interviewer should have pointed you in the right direction or offer some sort of hint to gain an understanding of how comfortable you are with the language rather then just having you fumble around but depending on the role they were hiring for these questions and this practice don't seem bad to me
- gcb0 12y agoonce i interviewed at a company because my current employer was under aggressive take over from Microsoft. in the interview i fluked a question about js scope because the whiteboard handwrite of the interviewer made it hard to see which variable was i and which was j... but after he explained why i got wrong and i realized the letter mistake i was too stressed and dumbfounded to make a case, so i just left. 6 mo later, my current employer is still independent while that company is now owned by Microsoft...
- quantumtremor 12y agoI realize that the interviewee was in time pressure, but really should've made smaller helper functions - probably would have helped ease the stress a lot. Possibly also unfamiliar with Clojure/functional programming as someone mentioned, given that his "happy" function uses loop unnecessarily. Here's my solution. (defn int-to-digits [n] (map #(Character/getNumericValue %) (str n))) (I had to Google Character/getNumericValue - doubt anyone expects you to memorize that). (defn next-happy [n] (reduce + (map #(* % %) (int-to-digits n)))) (defn happy? [n] (loop [n n seen #{}] (if (contains? seen n) (== n 1) (recur (next-happy n) (conj seen n))))) A lot simpler to reason about, even if the initial implementation did have bugs.
- dllthomas 12y ago"really should've made smaller helper functions" I couldn't agree more. Especially when you're under pressure, bite off smaller pieces. Not only is it possibly better practice in general, but in a time of diminished cognitive capacity (such as when much of your bandwidth is being eaten up wondering how you're coming off) they will be easier to get right, and small successes will help ease your stress as much as they help solve the problem.
- nbevans 12y agoIt's quite clear that a lot of your pain was caused by Clojure's type system. Those exception messages are something you'd not expect in the 21st century.
- spion 12y agoWhat helped me I think was going to meetups at the local hackerspace and preparing presentations involving live coding without previous preparation. The cost of screwing up there is small and yet its excellent exercise in coding in front of an audience.