This 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.
This 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.
I 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.
that'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
It'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.
I 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.
Are 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?
Emacs 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.
From 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.
Emacs 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.
Part 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.
Thanks 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.
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.
I 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.
B 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.
This 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.
"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.
There'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.
You'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.
No 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.
I 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.
Counter 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.
Awesome 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)
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.
> 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.
Note 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."
I 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.
Ask your friends who aren't software engineers. How many of them solve problems they've never seen before while someone watches over them during an interview?
The vast majority of other professions spend their time talking about past projects.
For instance all my designer friends show off their portfolios, then maybe they get a take home work sample. My writer friends submit samples of their work. And my engineer friends discuss past projects they've worked on.
Maybe if you give the candidate four hours. But in the hour or so that is ubiquitous among individual interviews (even if repeated four or five times with different interviewers), you aren't going to be any meaningful information out of anything the interviewee will have time to code. An hour is enough time to write something trivial. Anything that really pushes a developer's skills is going to need a big part of that hour just for them to put pen to paper for design. The best interviews I ever had involved a week-long spare-time development project at my own pace. Those are the only interviews I ever was able to really show what I'm capable of. Incidentally, my interview at the Googleplex I thought was worthless.
Well, I would say the total tasks were tasks taking about a handful of hours, but the deadlines were about a week out from when they were given. So essentially, they were spreading the "normal" five or six hours worth of interviewing with developers and doing trivial tasks (that I think don't really show the interviewer what kind of programmer I am), but compressed into one project, meanwhile time-wise spread out across a week. I've interviewed maybe five times like this (most recently twice last year). Definitely I felt like the code they got was a good representation of the kind of code I write normally. I would never agree to working for a week for a job interview without pay. Though most recently I had an interview where the guys didn't even ask for my resume once. They only ever looked over my Github, which for me was a nice touch, and made me feel like those guys know wtf they're doing. I should mention here that I interview for fun continually, otherwise I would have taken the one the guys offered who didn't even ask for my resume.
I have had my share of bad interviews but I don't agree with this sentiment, why is it unfair? Haven't you ever been in a situation where you have to create a hot fix and deploy it as fast as you can. Haven't you ever gone through a crunch period where the deadline is closing in and and you have to fix that elusive bug. There is limited time for everything, the sooner we realize that the better.
Having control over your nerves when s* hits the fan is a valuable quality, which we should all strive for.
Most of these interviews are tests to see your approach to solving a problem. The best practice is to come up with a strategy before you hit the first key, ask as many questions as you can and find as many corner cases as you can. All the sane interviewers will appreciate that even if you don't end up with the best solution. And please treat all interviews as a learning experience, you will be much better off.
I must've been working in a much different environment than you. I've never had to solve a difficult problem in 15 minutes while someone who knew the solution watched over my shoulder and did their best to answer my questions without answering them too well. Ohh yeah and the results of my performance had potentially life changing consequences.
The adversarial and extreme time boxed nature of a coding interview is something that is truly outside the day to day experience of the vast majority of programmers.
>Having control over your nerves when s* hits the fan is a valuable quality, which we should all strive for.
That may be true, but think about that for a minute. Go back to college and think of how many people in the class were comfortable going up to the board and solving problems in front of everyone.
When I was taking Automata, we could get an extra point on our final grade by going to the board and correctly working out a problem that we hadn't seen before. Only myself and 2 other people ever did it--in a class of 60.
Do you think that your company is solving problems so hard and paying so well that you can can only consider 3 out of every 60 developers (or whatever the real ratio is) who are otherwise qualified who have also mastered control of their nerves far beyond what is required 99% of the time on the job? Maybe if you're Google, for the rest of us we need to find a better solution.
By the way, even though I was able to solve problems at the board, I hated every minute of it, and I refuse to work for companies that require this kind of interview.
> I've never had to solve a difficult problem in 15 minutes while someone who knew the solution watched over my shoulder and did their best to answer my questions without answering them too well. Ohh yeah and the results of my performance had potentially life changing consequences.
So you've never taken an exam in your entire life?
I don't mean to be snarky. I just don't understand this extreme disdain for coding interviews, even when they're very forgiving and flexible. Yes, exams aren't fun, but they're necessary.
Even if you can look up whatever you want, use whatever language you want, take as long as you want, do it right on a real desktop (not a whiteboard), and if you're asked a reasonable, real-world problem, not an algorithmic brainteaser, you'll still have people say it's a horrible process and it's unfair. And that's already way more forgiving than any exam I ever took in school.
I mean, are programmers expected to not be able to do anything at all in an interview setting? Like you can't be expected to produce any code of any kind, as if you don't know how to program at all? I think it is a bad sign if someone who is a talented programmer utterly buckles under a little bit of pressure. To me, that means they either really aren't nearly as talented as they think they are, or they won't be able to deal with the pressure of the job anyway.
So what, if I hire you and at some point need you to hotfix something in, is that unfair? Maybe I do know how to do it myself but don't have time because I'm busy with something else. That situation doesn't seem all that different from the interview, except it would actually be higher pressure because there's a real problem, not a fake one.
>So you've never taken an exam in your entire life?
You missed the context where we're talking about a professional setting.
>And that's already way more forgiving than any exam I ever took in school.
You took exams in school were the professor was looking at what you were writing the entire time? Your exams were in front of several people on a whiteboard?
>To me, that means they either really aren't nearly as talented as they think they are, or they won't be able to deal with the pressure of the job anyway.
And you'd be wrong. I've worked with very talented programmers who are absolutely terrible at interviewing. The problem is you're biased by your experience. You are probably good at this kind of interview and you are probably a good programmer, so you assume that any good programmer must be a good interviewer.
I know for a fact that these 2 processes are orthogonal. Books like cracking the coding interview exist because it is possible to practice and game the system. I've met just as many people who are good at interview questions, but are terrible software engineers, as I have people who are bad at interviews and are excellent software engineers.
The fact is that our current hiring processes are broken. Other professions don't conduct interviews like this. Go talk to some mechanical engineers who've been working for 10 years and ask them if they interview like this. Newspaper writers work on deadlines, but they don't have to write an article on the spot while someone watches them type.
Studies have constantly shown that work sample tests are really the only form of interview that shows real predictive power (that and general intelligence tests). The closer you can make the work sample to real work, the better. Finding the nth item of some arbitrary sequence in 15 minutes while someone watches your every move is not close enough to real work to have much predictive power.
>So what, if I hire you and at some point need you to hotfix something in, is that unfair?
If you're regularly giving me life or death tasks that I have 15 minutes to solve, I don't want to work there. I'm also probably very familiar with the domain, and it's not some artificial problem that I may have never seen before. But more than that, why don't you see the difference between a hotfix and an artificial situation where someone who already knows the answer is standing there watching your every keystroke, and judging your value as a programmer?
There are better ways to interview programmers. Here is one:
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.
> You missed the context where we're talking about a professional setting.
I didn't miss it. I just don't see why it's relevant.
Why does your ability to handle that situation differ so greatly depending on whether it's an academic or professional setting?
> You took exams in school were the professor was looking at what you were writing the entire time? Your exams were in front of several people on a whiteboard?
Well, when we give technical interviews we let the candidate sit at a desktop and we don't particularly pay much attention to what they're doing. We definitely don't just stare at them. I know that at some popular companies like Google they may use a whiteboard and they might (but might not) pay more attention as you write your code. I don't really advocate that.
I know that's not always the case, though; I interviewed at Palantir once, for instance, and one of the interviewers ignored me completely until I was ready to present my solution.
That said, in school there were in fact a few occasions when I had effectively an oral exam. There also were occasions when I needed to do some work on a chalkboard in front of several people (if not the entire class). There were some occasions when I even needed to deliver a 45 minute highly technical presentation to the class and that doubled as an exam.
> Other professions don't conduct interviews like this. Go talk to some mechanical engineers who've been working for 10 years and ask them if they interview like this.
Well, my roommate's a chemical engineer at a major oil company. For his current job, he had to give a presentation to the entire interviewing team about his technical work at previous internships. It's not an exactly isomorphic scenario, but I'm sure they paid a great deal of attention to every single thing he said.
Lawyers have to take the bar exam, which I imagine is easily just as hard as an interview at Google. It might trigger social anxiety less, but that won't last long -- by the nature of the profession, you'll be in front of the court eventually.
Doctors have to take similar exams, equal in difficulty (if not greater), plus they are observed extremely rigorously during labs and clinical work.
> If you're regularly giving me life or death tasks that I have 15 minutes to solve, I don't want to work there.
It's not that regular of an occurrence, but it would be a sort of big deal if you were totally unable to act in that sort of situation. There would be a limit in what sorts of projects you would be given.
"Life and death" is an exaggeration, though. It's not any more life and death than a 15 minute quiz.
> 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.
Are you suggesting that you can perform well when you have someone helping you, but you can't when you don't? Or is it just an issue of social anxiety?
>Why does your ability to handle that situation differ so greatly depending on whether it's an academic or professional setting?
I didn't say it did. But just because something happens in a university doesn't make it the optimal way to conduct an interview.
>I don't really advocate that.
That goes a long way towards alleviating the problems that most people have with this type of interview.
> For his current job, he had to give a presentation to the entire interviewing team about his technical work at previous internships.
Talking about past experiences is completely different from solving problems under pressure. Almost all professions require this, and I'm at a loss as to why it's not good enough for software.
>There were some occasions when I even needed to deliver a 45 minute highly technical presentation to the class and that doubled as an exam.
Again not really the same thing at all. Delivering a prepared presentation is an entirely different issue. And if public speaking like this is required for the job, I see no problem in including it in an interview.
> by the nature of the profession, you'll be in front of the court eventually.
Yes, you said it, that kind of thing is an essential part of the job for lawyers, not so much for software engineers.
>plus they are observed extremely rigorously during labs and clinical work.
Yes this is true, but this happens when they are just starting out. No one is going to take a surgeon with 10 years of experience and force him to do an operation for an interview.
>It's not that regular of an occurrence, but it would be a sort of big deal if you were totally unable to act in that sort of situation. There would be a limit in what sorts of projects you would be given.
Again, I have never once encountered a situation where I had 15 minutes to solve a complex problem that had never seen before.
>Are you suggesting that you can perform well when you have someone helping you, but you can't when you don't? Or is it just an issue of social anxiety?
I'm not suggesting that. I do fine in technical interviews the same as I did extremely well on exams in school. However, even though I often made the highest grade on an exam, I hated every minute of it, and I feel the same way about technical interviews.
Here's the bottom line. I do fine in technical interviews, but they cause me more stress than they're worth to me. You may be fine with this kind of interview, but from the comments on hacker news a very large percentage of software developers are not. Many people hate them, and their predictive value is dubious.
The interview format I outlined is objectively more similar to the day to day work of an average developer. Studies have show that work sample tests are the best way to judge a potential employee. Why not strive for a better interview process?
It really comes down to this. If you can eliminate a section of the interview that many people dislike, which isn't critical to the performance of the job, and it will increase the tests predictive value, why wouldn't you do it? Do you want to hire people who are good at interviews or do you want to hire people who are good employees? If company A depends on an interview process for which 50% of otherwise qualified interviews will perform well on, and company B has an interview process for which 60% of otherwise qualified candidates will perform well on, which company will perform better in the long run?
Current technical interviewing techniques are demonstrably terrible. Their predictive power is terrible. The only argument is whether there is a better way to do it. I think there is.
> I didn't say it did. But just because something happens in a university doesn't make it the optimal way to conduct an interview.
I honestly think you're sort of dodging the question here, maybe not intentionally.
> I'm at a loss as to why it's not good enough for software.
Probably because you can say anything you want to impress people, which means that as an interviewer you can't really trust anything they say and must probe them very deeply about any work they've claimed to have done. At that point it's already a sort of technical interview.
We actually use a mix of this. We don't require a formal presentation but one of the interviews involves having the candidate discuss past work in detail.
We definitely would not feel comfortable eliminating coding interviews on the basis of that one interview alone. In the past, we've hired some people on the basis of things like this, ignoring poor results on the technical screen, and those have been our worst hires.
> No one is going to take a surgeon with 10 years of experience and force him to do an operation for an interview.
Well, a surgeon's literal every move is being observed during every single operation. And to get to that point, the surgeon was basically subjected to excruciatingly rigorous daily oral examinations for 5-7 years during residency.
> they're predictive power is terrible.
Honestly, we haven't had many issues with it, so I don't know that I could agree it's terrible.
Actually, and I'm not exaggerating here, every single one of our worst hires has come from giving somebody the benefit of the doubt when they didn't do well in the technical interviews.
---
At the end of the day, I agree with you wholeheartedly that we need to find a way to improve the interview process. I just don't think the current process is that terrible, especially when you get away from large, lumbering places like Google and look at smaller, more forward-thinking companies. Google has absolutely zero ability to adjust to specific candidates.
I understand your frustration with being experienced and still being subjected to technical interviews on BFS or whatever. It's annoying and sometimes even insulting, and in the worst case it demands that you go spend an inordinate amount of free time brushing up on interview material that never actually shows up in the real world. So I'm very much with you on the inadequacies of the current procedure; I just don't think it needs a drastic alteration.
I think replacing whiteboards with actual computers, algorithmic brainteasers with real-world problems, and extreme timeboxes with more open-ended formats are the main changes that are needed. Just let someone sit at a computer and write a program to do something fairly common. And don't stare them down while they do it. I really, honestly do not think this is that unfair or crazy.
It seems a lot simpler than and just as effective as doing a pair programming event where you have to make sure that both people have not seen the particular task before, which basically means the interview will have to be completely customized for each candidate. And that's not necessarily a good thing -- it means it's pretty hard now to compare two different candidates.
>Honestly, we haven't had many issues with it, so I don't know that I could agree it's terrible.
If it works for you, then it works for you.
The one thing I know for sure is that peer reviewed studies over the last 50 years show that work sample tests are the absolute most predictive tests you can perform.
If what you're doing is as close to a real work sample as you can reasonably get, then you're probably doing better than 95% of companies. And from your description of your process it sounds like you are.
>It seems a lot simpler than and just as effective as doing a pair programming event where you have to make sure that both people have not seen the particular task before, which basically means the interview will have to be completely customized for each candidate.
The pair programming isn't necessarily essential in my opinion. The essential part is eliminating the artificial adversarial and timeboxed nature of the traditional whiteboard interview.
>it means it's pretty hard now to compare two different candidates.
That's actually a pretty key insight. The practice that many companies have of allowing interviewing engineers to use any problems they want is completely opposed to this.
>You took exams in school were the professor was looking at what you were writing the entire time? Your exams were in front of several people on a whiteboard?
Yes. Is this not common? I've had a number of teachers who, as a graded form of evaluation, would ask us to present a topic to the class, and/or ask questions about it. This was extremely common on high school, and happened once or twice in the more advanced courses in my college. I also had to defend my thesis to graduate, which was basically a more lengthy version of this.
I've had to do both, but presenting on a prepared topic was much more common. I don´t recall ever being graded on a novel exercise presented to the class, but I certainly have had to solve them.
I've had professors that like to require writing on the board as well. But as in your case the key difference is, they weren't graded.
That being said, a professor student relationship isn't analogous to an employer employee relationship. Hopefully an employer wants to make the interview process as enjoyable as possible to attract as many qualified applicants as possible.
I agree, the relationship is not analogous at all. That's why I said I was going on a tangent: I was more interested in learning about the evaluation system in the US than it's possible parallels with job interviewing,
Context is vary important in problem solving. If your coding a quick fix for something and there is a code frease in 20 minutes your not grasping at straws wondering do they mean 100 numbers list or a 100 gigabyte list etc.
If you aren't judging whether they get a correct working solution (i.e. passes some unit tests after running it through the compiler/interpreter), and actively engaging them on their thought process while they attempt to find a solution, it can be a useful tool (esp. in early filtering with really trivial problems). Interpreting the results, and picking the coding problem, are not easy tasks.
That said, I've certainly found myself in the position described by the story, and all I can say is that I'm glad I've never actually needed to find a job in my career (new opportunities have always come from people who already know me and my track record). You may (though I wouldn't bet on it) get fewer bad "hire" decisions by doing a code interview like the one in the article, but you also get bad "no-hire" decisions. I'd love to see some empirical data on the subject from someone who knows how to design an experiment.
But, an interview technique can be useful for a company or not. Asking candidates to write code on the spot isn't inherently useful or not useful. Assessing a candidates typos and compiler errors smugly is probably not very useful. But assessing their approach to understanding expectations, understanding problems, and solving problems is useful. If a candidate just assumes the expectations without asking in the interview, they are likely to do the same on the job.
We use a variation: the scenario is that us, the interviewer, is a junior developer and we've submitted our code for code review. Then later we ask the candidate to add some trivial functionality.
We've found this works really well. There are unit tests, so its always a promising sign if they go for them first. Depending on what they pick up, change or ask questions about, lets us a lot about the candidate.
Yep we've used a page of code from one of our systems and asked the person to talk through what they can see, what it does, what they would ask further questions about and so on. It almost instantly separates people who know a bit about code from those who don't, as the latter will literally just stare at the page for a while before giving up.
I really like this idea and think it would work wonderfully for me. Plant a couple of easy-to-spot errors in there as well as some more difficult optimizations and see who finds them. :) It takes the pressure away from writing new code, doesn't require a computer, and still allows you to see the thought process of the interviewee.
-- "I mainly want to know how you think." I totally agree with you on this. I hope my case could help contribute to the implementation details.
People have very different working styles. Since interview as a process can't be tailored to all of them, it is rationally refined to suit for the majorities. For the minorities left, I have to say one has to adjust, trying to go through the 5-hour drills.
I, unfortunately, is one of the minorities. Given a hard question, one has to think first. I am the opposite of thinking aloud. In real work, I either stare at walls, or look at the vast void far away, silently. I might have a piece of paper, drawing odd shapes and graphs, because I am primarily a visual thinker. In the interview, it would definitely look odd. It could be awkward as well if I completely fall into silence, ignoring the interviewers.
So I would face to the white board, wrote a few lines of pseudo-code, uttered some words, while trying to get my inner self into my real work routines. Sometimes it works relatively well, sometimes it failed completely, especially the interviewers kept talking that requires my interaction. In many cases, I understand the interviewers were trying to help, giving my hints, while the effect was the opposite of their intents.
It's quite weird how wandering/walking is such a common way to open your mind. I also found that when going abroad I would be filled with creativity. Maybe being removed from my home habits and games. Or maybe because the foreign context stimulates your brain. Somehow it seems like physically changing your perceptions triggers opportunity for your brain to change its view on abstract things too.
So much of your thinking and habits are tied to your immediate environment. For example, people find it much easier to overcome addiction when they move to a new location where all the triggers for their addictive behaviour are removed.
Problem solving is similar in that your current environment constrains your thinking. Getting up and changing your environment changes the constraints on your thought processes. The bigger the change in environment, the more constraints removed and the greater the opportunity for creativity.
A nice twist about environment constraint is mere people presence. My last mission I was shifted one hour later than the usual schedule. At 6pm the office emptied, and as soon as I was alone, felt like my mind expanded against the walls. Freedom and motivation rushed, I could bubble in my ideas without thinking of anything or anybody else.
I think you are not really a minority. Most programmers I know work like that. I realized that this is why I can't really do job interviews. Not only are the problems there not real, so I don't care that much about solving them, the expected way of solving them is very unnatural for me. I'm more than happy to explain the problem in great detail to anybody after its solved, but explaining the things as I go usually does not lead anywhere.
Does anybody believe you when you say those things in a job interview, though? I wouldn't. A job interview is fundamentally a competition against other candidates. If you have two candidates and one finishes the task in half the time he's more likely to get the job. Time is a factor in everything. Same with looking things up. It's considerably more impressive to be able to recall minute technical details without having to look them up.
The resulting cognitive dissonance adds more pressure to the situation instead of relieving it.
> A job interview is fundamentally a competition against other candidates.
That's hardly the case. Hiring for programming is different from hiring for a cashier. The programming world, at least, if you hiring for good programmers, would rarely have a queue of candidates lined-up. You get tons of resumes daily, sift through BS, find someone good, get to know him more and after some rounds, you hire him if he is worth his salt.
Rarely you would hear the phrase, "We hired the other candidate because he was skin-of-teeth better than you." Judging from the lack of engineers, a company would be very lucky to have more than one really good candidate for a position.
this is exactly my experience as well. having very recently completed a round of interviews for new hires, I experienced this directly. we wanted to hire 2 engineers. we interviewed about 20. found 4 that we liked. 2 of those 4 took other offers at other places they interviewed. we hired the 2 (that we liked, they have been good hires so far!) that were left.
there was never anything close to anybody getting "cut" in favor of another interviewee that was fractionally better than they were. we fully intended to make offers to everyone that we thought was good.
> Does anybody believe you when you say those things in a job interview, though? I wouldn't. A job interview is fundamentally a competition against other candidates. If you have two candidates and one finishes the task in half the time he's more likely to get the job.
Not at all.
I have one hour to decide if I want to work with a candidate.
How quickly someone works? Sure, that is important.
How good is their sense of humor? Can they joke around? Can they be involved in a technical deep dive on a problem? How about coming up with test cases?
I have 60 minutes and one programming problem. I've hired people who've taken from 5 minutes to 40.
> Does anybody believe you when you say those things in a job interview, though? I wouldn't. A job interview is fundamentally a competition against other candidates.
I think you are being a bit negative. Why not believe the interviewer? It seems pointless to trick candidates by suggesting they are safe to look things up, then secretly judging them worse than other candidates. I would judge more harshly someone who didn't ask if they could look something up, or assumed they couldn't. Particularly so if they had been told they could but then proceeded to struggle and not look something up or ask the interviewer. I'd rather someone I may work with have a relaxed attitude and inherent curiosity rather than a paralyzing fear of failure.
Also viewing it as fundamentally a competition is focusing a lot on the negative perspective from your side. An interview is about finding a good match between a company and an employee. It can be just as much about you finding somewhere you want to work as it can about them comparing you to other candidates.
There may not even be other candidates, and they could be trying to make you comfortable and give you an idea of what it would be like to work together. Maybe suggesting that they do understand the cognitive dissonance and they do understand that interviews are stressful and hence no need to add additional pressure.
I 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.
As 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.
I 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.
This 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.
That 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.
Agreed, 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.
I 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.
This is a great list as you are using one of the proven interviewing processes that work - testing a candidates ability to preform the work they will be hired to do, not some proxy.
The only difficulty I can see with letting the candidate use any language they like is some languages are inherently easier and faster than other languages to solve certain problem classes. This may make it hard to compare candidates.
On 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.
I 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".
"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.
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.)
> "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...
If 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.
> 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
I frequently hear people say things like this. Now maybe you do think this way and I'm not saying you don't, but I think that makes you exceptional. In about 80% of interviews I've done where I successfully completed the problem, I got an offer; and in 100% of interviews where I did not complete the problem, I did not get an offer. That seems to indicate pretty strongly that solving the problem is by far the most important thing for most interviewers.
I didn't take what he said to mean that solving the problem wasn't important, but that the quality of your solution (in terms of how 'elegant' or 'idiomatic' it is) wasn't important.
> 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.)
Yep. 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.
It 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.
Perhaps 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.
There'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.)
I've long shrugged off the shame of asking stupid questions. You see this phenomena throughout school, university (though for God's sake after the lecture, please) and in the workplace. People are afraid of looking stupid so they sit on their thumbs waiting for things to magically click.
This goes a long way when you're talking to clients or partners too. You often need to ask questions that will appear stupid to them, but that you don't know the answer to. They normally take it that you actually care about the job/problem, and often you'll gain some important insight that you otherwise wouldn't know.
Same here. I am always the first guy in a group to ask the stupid question. Almost never do I get a snide response.
If I did get a snide response to a clarifying question in an interview, it would be an almost certain signal that I should run away from this company. Their rudeness is actually a favor, potentially sparing me months or years of unpleasantness in their company.
> But I wanted to appear smart, so I didn’t express any confusion.
In fact some interviews are intended to flush out behavior like this. Give a candidate an ambiguous problem statement, and see if they ask the necessary clarifying questions.
This meta-problem (ambiguous problems/unclear goals) happens all the time in the real world and bringing clarity to situations like this is a good skill to have.
I'm asked to code a simple matrix in java. I ask about the fill factor, and get told quite low. The constructor takes the dimension and it's assumed square. I ask the interviewer if a csc matrix is ok, and he kind of says he's not sure what a csc matrix is. I tell him it's column sparse, and proceed to quickly write out, on a whiteboard, a simple csc matrix -- basically, an array of dimension columns of ArrayList of tuple <index, value>. The constructor is pretty much
ArrayList<Tuple>[] columns;
void SparseCSCMatrix(int dim){
columns = new ArrayList<Tuple>[ dim ];
}
The interviewer then starts going at me because having, eg, a million columns requires an array with a million elements in it. I say yes, duh. He says it's quite inefficient -- what if I only use 10 columns out of the million? My response is, well, that's fine -- but what you're describing isn't a matrix. It turns out that what he really wanted was a HashMap from tuple: (x idx, y idx) to value, and that a typical load would be perhaps 1k elements in a space of 1 million by 1 million.
We then go at it about whether I should have asked him to clarify, and I basically decide I don't have to play along with stupid gotcha questions so I told him words have meanings and a "matrix" with only 10 non-empty columns is not a matrix. And I don't have time for wankers.
I think I disagree. What he wanted can certainly be called a matrix. An m-by-n matrix has an entry for every (x, y), 0<=x<m 0<=y<n, but that's not a description of the way to represent a matrix in memory. That is an implementation decision. Of course I wasn't there, and I don't know the fine details that got you mad.
I agree that many words "have meanings", including "matrix" in general, and "CSC matrix" in particular. I think you have the wrong definitions for both.
In my experience, "matrix" is a mathematical concept, and is independent of the implementation. As such, an extremely sparse matrix, such as your alleged interviewer described, is absolutely a matrix. And for such a matrix (density 10^-9), such a dictionary-style approach seems fairly reasonable.
Next, it seems to me that "CSC matrix" is a particular encoding that works well for sparse matrices, that is not related to the code that you wrote. It contains no index/value tuples, and it consists of three top-level arrays (that, in the general case, are of different lengths).
Actually, it's not obvious to me how to do arithmetic on it (without converting to a denser format), though the scipy docs say it's fairly efficient, so I'm having a little think about that. Interesting.
Anyway, sounds like you're glad you didn't get that job, and I'd imagine that they're glad they didn't get you, so everybody wins.
3 arrays is directly equivalent to an array of 2 arrays or an array of tuples of index,value. As for how it's efficient, that's obvious: column eg 3 will be an array of tuples like [(1,3), (11,17), (9936,3)] so there are nz values in locations
[1, 3] = 3
[11, 3] = 17
[9936, 3] = 3
so csc makes it efficient to read down columns, ie right multiply by the transpose. My implementation makes it easier to update in the sense of inserting values at indices where previously the value was empty, since you only have to reorder a single column instead of all following data from top to bottom then left to right. Once finished inserting values, if ever, you may want to move to two packed arrays.
What makes me shake my head is you don't understand what csc matrices are but didn't let that stop you from telling me I don't understand them. HN in a nutshell.
I always think candidates seem smarter when they ask questions to clarify the interview questions, even if they're just disambiguation questions like, "did you say 'infinity' or 'infinitely'?"
I 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.
Yeah, 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.
I 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.
For 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.
Your 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.
My 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.
> 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.
Technical 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.
I 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...
I 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.
That 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.
At 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.
186 comments
[ 3.7 ms ] story [ 318 ms ] threadEDIT: removed some bitterness. :)
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.
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
Matasano (founded by tptacek) does a good job at this: http://matasano.com/careers/
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.
Skype n_goles
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.
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.
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.
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.
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.
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)
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.
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.
For instance all my designer friends show off their portfolios, then maybe they get a take home work sample. My writer friends submit samples of their work. And my engineer friends discuss past projects they've worked on.
Having control over your nerves when s* hits the fan is a valuable quality, which we should all strive for.
Most of these interviews are tests to see your approach to solving a problem. The best practice is to come up with a strategy before you hit the first key, ask as many questions as you can and find as many corner cases as you can. All the sane interviewers will appreciate that even if you don't end up with the best solution. And please treat all interviews as a learning experience, you will be much better off.
The adversarial and extreme time boxed nature of a coding interview is something that is truly outside the day to day experience of the vast majority of programmers.
>Having control over your nerves when s* hits the fan is a valuable quality, which we should all strive for.
That may be true, but think about that for a minute. Go back to college and think of how many people in the class were comfortable going up to the board and solving problems in front of everyone.
When I was taking Automata, we could get an extra point on our final grade by going to the board and correctly working out a problem that we hadn't seen before. Only myself and 2 other people ever did it--in a class of 60.
Do you think that your company is solving problems so hard and paying so well that you can can only consider 3 out of every 60 developers (or whatever the real ratio is) who are otherwise qualified who have also mastered control of their nerves far beyond what is required 99% of the time on the job? Maybe if you're Google, for the rest of us we need to find a better solution.
By the way, even though I was able to solve problems at the board, I hated every minute of it, and I refuse to work for companies that require this kind of interview.
So you've never taken an exam in your entire life?
I don't mean to be snarky. I just don't understand this extreme disdain for coding interviews, even when they're very forgiving and flexible. Yes, exams aren't fun, but they're necessary.
Even if you can look up whatever you want, use whatever language you want, take as long as you want, do it right on a real desktop (not a whiteboard), and if you're asked a reasonable, real-world problem, not an algorithmic brainteaser, you'll still have people say it's a horrible process and it's unfair. And that's already way more forgiving than any exam I ever took in school.
I mean, are programmers expected to not be able to do anything at all in an interview setting? Like you can't be expected to produce any code of any kind, as if you don't know how to program at all? I think it is a bad sign if someone who is a talented programmer utterly buckles under a little bit of pressure. To me, that means they either really aren't nearly as talented as they think they are, or they won't be able to deal with the pressure of the job anyway.
So what, if I hire you and at some point need you to hotfix something in, is that unfair? Maybe I do know how to do it myself but don't have time because I'm busy with something else. That situation doesn't seem all that different from the interview, except it would actually be higher pressure because there's a real problem, not a fake one.
You missed the context where we're talking about a professional setting.
>And that's already way more forgiving than any exam I ever took in school.
You took exams in school were the professor was looking at what you were writing the entire time? Your exams were in front of several people on a whiteboard?
>To me, that means they either really aren't nearly as talented as they think they are, or they won't be able to deal with the pressure of the job anyway.
And you'd be wrong. I've worked with very talented programmers who are absolutely terrible at interviewing. The problem is you're biased by your experience. You are probably good at this kind of interview and you are probably a good programmer, so you assume that any good programmer must be a good interviewer.
I know for a fact that these 2 processes are orthogonal. Books like cracking the coding interview exist because it is possible to practice and game the system. I've met just as many people who are good at interview questions, but are terrible software engineers, as I have people who are bad at interviews and are excellent software engineers.
The fact is that our current hiring processes are broken. Other professions don't conduct interviews like this. Go talk to some mechanical engineers who've been working for 10 years and ask them if they interview like this. Newspaper writers work on deadlines, but they don't have to write an article on the spot while someone watches them type.
Studies have constantly shown that work sample tests are really the only form of interview that shows real predictive power (that and general intelligence tests). The closer you can make the work sample to real work, the better. Finding the nth item of some arbitrary sequence in 15 minutes while someone watches your every move is not close enough to real work to have much predictive power.
>So what, if I hire you and at some point need you to hotfix something in, is that unfair?
If you're regularly giving me life or death tasks that I have 15 minutes to solve, I don't want to work there. I'm also probably very familiar with the domain, and it's not some artificial problem that I may have never seen before. But more than that, why don't you see the difference between a hotfix and an artificial situation where someone who already knows the answer is standing there watching your every keystroke, and judging your value as a programmer?
There are better ways to interview programmers. Here is one:
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.
I didn't miss it. I just don't see why it's relevant.
Why does your ability to handle that situation differ so greatly depending on whether it's an academic or professional setting?
> You took exams in school were the professor was looking at what you were writing the entire time? Your exams were in front of several people on a whiteboard?
Well, when we give technical interviews we let the candidate sit at a desktop and we don't particularly pay much attention to what they're doing. We definitely don't just stare at them. I know that at some popular companies like Google they may use a whiteboard and they might (but might not) pay more attention as you write your code. I don't really advocate that.
I know that's not always the case, though; I interviewed at Palantir once, for instance, and one of the interviewers ignored me completely until I was ready to present my solution.
That said, in school there were in fact a few occasions when I had effectively an oral exam. There also were occasions when I needed to do some work on a chalkboard in front of several people (if not the entire class). There were some occasions when I even needed to deliver a 45 minute highly technical presentation to the class and that doubled as an exam.
> Other professions don't conduct interviews like this. Go talk to some mechanical engineers who've been working for 10 years and ask them if they interview like this.
Well, my roommate's a chemical engineer at a major oil company. For his current job, he had to give a presentation to the entire interviewing team about his technical work at previous internships. It's not an exactly isomorphic scenario, but I'm sure they paid a great deal of attention to every single thing he said.
Lawyers have to take the bar exam, which I imagine is easily just as hard as an interview at Google. It might trigger social anxiety less, but that won't last long -- by the nature of the profession, you'll be in front of the court eventually.
Doctors have to take similar exams, equal in difficulty (if not greater), plus they are observed extremely rigorously during labs and clinical work.
> If you're regularly giving me life or death tasks that I have 15 minutes to solve, I don't want to work there.
It's not that regular of an occurrence, but it would be a sort of big deal if you were totally unable to act in that sort of situation. There would be a limit in what sorts of projects you would be given.
"Life and death" is an exaggeration, though. It's not any more life and death than a 15 minute quiz.
> 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.
Are you suggesting that you can perform well when you have someone helping you, but you can't when you don't? Or is it just an issue of social anxiety?
I didn't say it did. But just because something happens in a university doesn't make it the optimal way to conduct an interview.
>I don't really advocate that.
That goes a long way towards alleviating the problems that most people have with this type of interview.
> For his current job, he had to give a presentation to the entire interviewing team about his technical work at previous internships.
Talking about past experiences is completely different from solving problems under pressure. Almost all professions require this, and I'm at a loss as to why it's not good enough for software.
>There were some occasions when I even needed to deliver a 45 minute highly technical presentation to the class and that doubled as an exam.
Again not really the same thing at all. Delivering a prepared presentation is an entirely different issue. And if public speaking like this is required for the job, I see no problem in including it in an interview.
> by the nature of the profession, you'll be in front of the court eventually.
Yes, you said it, that kind of thing is an essential part of the job for lawyers, not so much for software engineers.
>plus they are observed extremely rigorously during labs and clinical work.
Yes this is true, but this happens when they are just starting out. No one is going to take a surgeon with 10 years of experience and force him to do an operation for an interview.
>It's not that regular of an occurrence, but it would be a sort of big deal if you were totally unable to act in that sort of situation. There would be a limit in what sorts of projects you would be given.
Again, I have never once encountered a situation where I had 15 minutes to solve a complex problem that had never seen before.
>Are you suggesting that you can perform well when you have someone helping you, but you can't when you don't? Or is it just an issue of social anxiety?
I'm not suggesting that. I do fine in technical interviews the same as I did extremely well on exams in school. However, even though I often made the highest grade on an exam, I hated every minute of it, and I feel the same way about technical interviews.
Here's the bottom line. I do fine in technical interviews, but they cause me more stress than they're worth to me. You may be fine with this kind of interview, but from the comments on hacker news a very large percentage of software developers are not. Many people hate them, and their predictive value is dubious.
The interview format I outlined is objectively more similar to the day to day work of an average developer. Studies have show that work sample tests are the best way to judge a potential employee. Why not strive for a better interview process?
It really comes down to this. If you can eliminate a section of the interview that many people dislike, which isn't critical to the performance of the job, and it will increase the tests predictive value, why wouldn't you do it? Do you want to hire people who are good at interviews or do you want to hire people who are good employees? If company A depends on an interview process for which 50% of otherwise qualified interviews will perform well on, and company B has an interview process for which 60% of otherwise qualified candidates will perform well on, which company will perform better in the long run?
Current technical interviewing techniques are demonstrably terrible. Their predictive power is terrible. The only argument is whether there is a better way to do it. I think there is.
I honestly think you're sort of dodging the question here, maybe not intentionally.
> I'm at a loss as to why it's not good enough for software.
Probably because you can say anything you want to impress people, which means that as an interviewer you can't really trust anything they say and must probe them very deeply about any work they've claimed to have done. At that point it's already a sort of technical interview.
We actually use a mix of this. We don't require a formal presentation but one of the interviews involves having the candidate discuss past work in detail.
We definitely would not feel comfortable eliminating coding interviews on the basis of that one interview alone. In the past, we've hired some people on the basis of things like this, ignoring poor results on the technical screen, and those have been our worst hires.
> No one is going to take a surgeon with 10 years of experience and force him to do an operation for an interview.
Well, a surgeon's literal every move is being observed during every single operation. And to get to that point, the surgeon was basically subjected to excruciatingly rigorous daily oral examinations for 5-7 years during residency.
> they're predictive power is terrible.
Honestly, we haven't had many issues with it, so I don't know that I could agree it's terrible.
Actually, and I'm not exaggerating here, every single one of our worst hires has come from giving somebody the benefit of the doubt when they didn't do well in the technical interviews.
---
At the end of the day, I agree with you wholeheartedly that we need to find a way to improve the interview process. I just don't think the current process is that terrible, especially when you get away from large, lumbering places like Google and look at smaller, more forward-thinking companies. Google has absolutely zero ability to adjust to specific candidates.
I understand your frustration with being experienced and still being subjected to technical interviews on BFS or whatever. It's annoying and sometimes even insulting, and in the worst case it demands that you go spend an inordinate amount of free time brushing up on interview material that never actually shows up in the real world. So I'm very much with you on the inadequacies of the current procedure; I just don't think it needs a drastic alteration.
I think replacing whiteboards with actual computers, algorithmic brainteasers with real-world problems, and extreme timeboxes with more open-ended formats are the main changes that are needed. Just let someone sit at a computer and write a program to do something fairly common. And don't stare them down while they do it. I really, honestly do not think this is that unfair or crazy.
It seems a lot simpler than and just as effective as doing a pair programming event where you have to make sure that both people have not seen the particular task before, which basically means the interview will have to be completely customized for each candidate. And that's not necessarily a good thing -- it means it's pretty hard now to compare two different candidates.
If it works for you, then it works for you.
The one thing I know for sure is that peer reviewed studies over the last 50 years show that work sample tests are the absolute most predictive tests you can perform.
If what you're doing is as close to a real work sample as you can reasonably get, then you're probably doing better than 95% of companies. And from your description of your process it sounds like you are.
>It seems a lot simpler than and just as effective as doing a pair programming event where you have to make sure that both people have not seen the particular task before, which basically means the interview will have to be completely customized for each candidate.
The pair programming isn't necessarily essential in my opinion. The essential part is eliminating the artificial adversarial and timeboxed nature of the traditional whiteboard interview.
>it means it's pretty hard now to compare two different candidates.
That's actually a pretty key insight. The practice that many companies have of allowing interviewing engineers to use any problems they want is completely opposed to this.
>You took exams in school were the professor was looking at what you were writing the entire time? Your exams were in front of several people on a whiteboard?
Yes. Is this not common? I've had a number of teachers who, as a graded form of evaluation, would ask us to present a topic to the class, and/or ask questions about it. This was extremely common on high school, and happened once or twice in the more advanced courses in my college. I also had to defend my thesis to graduate, which was basically a more lengthy version of this.
I live in Argentina. Maybe it's a cultural thing.
> would ask us to present a topic to the class, and/or ask questions about it.
This is common in the US as well, but presenting on a prepared topic and solving novel problems are 2 completely different things.
That being said, a professor student relationship isn't analogous to an employer employee relationship. Hopefully an employer wants to make the interview process as enjoyable as possible to attract as many qualified applicants as possible.
If you aren't judging whether they get a correct working solution (i.e. passes some unit tests after running it through the compiler/interpreter), and actively engaging them on their thought process while they attempt to find a solution, it can be a useful tool (esp. in early filtering with really trivial problems). Interpreting the results, and picking the coding problem, are not easy tasks.
That said, I've certainly found myself in the position described by the story, and all I can say is that I'm glad I've never actually needed to find a job in my career (new opportunities have always come from people who already know me and my track record). You may (though I wouldn't bet on it) get fewer bad "hire" decisions by doing a code interview like the one in the article, but you also get bad "no-hire" decisions. I'd love to see some empirical data on the subject from someone who knows how to design an experiment.
But, an interview technique can be useful for a company or not. Asking candidates to write code on the spot isn't inherently useful or not useful. Assessing a candidates typos and compiler errors smugly is probably not very useful. But assessing their approach to understanding expectations, understanding problems, and solving problems is useful. If a candidate just assumes the expectations without asking in the interview, they are likely to do the same on the job.
We've found this works really well. There are unit tests, so its always a promising sign if they go for them first. Depending on what they pick up, change or ask questions about, lets us a lot about the candidate.
People have very different working styles. Since interview as a process can't be tailored to all of them, it is rationally refined to suit for the majorities. For the minorities left, I have to say one has to adjust, trying to go through the 5-hour drills.
I, unfortunately, is one of the minorities. Given a hard question, one has to think first. I am the opposite of thinking aloud. In real work, I either stare at walls, or look at the vast void far away, silently. I might have a piece of paper, drawing odd shapes and graphs, because I am primarily a visual thinker. In the interview, it would definitely look odd. It could be awkward as well if I completely fall into silence, ignoring the interviewers.
So I would face to the white board, wrote a few lines of pseudo-code, uttered some words, while trying to get my inner self into my real work routines. Sometimes it works relatively well, sometimes it failed completely, especially the interviewers kept talking that requires my interaction. In many cases, I understand the interviewers were trying to help, giving my hints, while the effect was the opposite of their intents.
However, if your approach is so radically different that I can't see how you got there, you may not be the ideal candidate.
Don't worry about being different in your approach. It is, however, very important that you are able to keep someone on the same page.
Edit: autocorrect
At my next interview, I'll bring a bed, ideas come when I lay in and stare at the ceiling.
Problem solving is similar in that your current environment constrains your thinking. Getting up and changing your environment changes the constraints on your thought processes. The bigger the change in environment, the more constraints removed and the greater the opportunity for creativity.
The resulting cognitive dissonance adds more pressure to the situation instead of relieving it.
That's hardly the case. Hiring for programming is different from hiring for a cashier. The programming world, at least, if you hiring for good programmers, would rarely have a queue of candidates lined-up. You get tons of resumes daily, sift through BS, find someone good, get to know him more and after some rounds, you hire him if he is worth his salt.
Rarely you would hear the phrase, "We hired the other candidate because he was skin-of-teeth better than you." Judging from the lack of engineers, a company would be very lucky to have more than one really good candidate for a position.
there was never anything close to anybody getting "cut" in favor of another interviewee that was fractionally better than they were. we fully intended to make offers to everyone that we thought was good.
Not at all.
I have one hour to decide if I want to work with a candidate.
How quickly someone works? Sure, that is important.
How good is their sense of humor? Can they joke around? Can they be involved in a technical deep dive on a problem? How about coming up with test cases?
I have 60 minutes and one programming problem. I've hired people who've taken from 5 minutes to 40.
I think you are being a bit negative. Why not believe the interviewer? It seems pointless to trick candidates by suggesting they are safe to look things up, then secretly judging them worse than other candidates. I would judge more harshly someone who didn't ask if they could look something up, or assumed they couldn't. Particularly so if they had been told they could but then proceeded to struggle and not look something up or ask the interviewer. I'd rather someone I may work with have a relaxed attitude and inherent curiosity rather than a paralyzing fear of failure.
Also viewing it as fundamentally a competition is focusing a lot on the negative perspective from your side. An interview is about finding a good match between a company and an employee. It can be just as much about you finding somewhere you want to work as it can about them comparing you to other candidates.
There may not even be other candidates, and they could be trying to make you comfortable and give you an idea of what it would be like to work together. Maybe suggesting that they do understand the cognitive dissonance and they do understand that interviews are stressful and hence no need to add additional pressure.
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 :)
- 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.
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.
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.
The only difficulty I can see with letting the candidate use any language they like is some languages are inherently easier and faster than other languages to solve certain problem classes. This may make it hard to compare candidates.
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.
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".
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-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.)
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...
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.
I frequently hear people say things like this. Now maybe you do think this way and I'm not saying you don't, but I think that makes you exceptional. In about 80% of interviews I've done where I successfully completed the problem, I got an offer; and in 100% of interviews where I did not complete the problem, I did not get an offer. That seems to indicate pretty strongly that solving the problem is by far the most important thing for most interviewers.
> 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.)
(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.)
This goes a long way when you're talking to clients or partners too. You often need to ask questions that will appear stupid to them, but that you don't know the answer to. They normally take it that you actually care about the job/problem, and often you'll gain some important insight that you otherwise wouldn't know.
If I did get a snide response to a clarifying question in an interview, it would be an almost certain signal that I should run away from this company. Their rudeness is actually a favor, potentially sparing me months or years of unpleasantness in their company.
In fact some interviews are intended to flush out behavior like this. Give a candidate an ambiguous problem statement, and see if they ask the necessary clarifying questions.
This meta-problem (ambiguous problems/unclear goals) happens all the time in the real world and bringing clarity to situations like this is a good skill to have.
I'm asked to code a simple matrix in java. I ask about the fill factor, and get told quite low. The constructor takes the dimension and it's assumed square. I ask the interviewer if a csc matrix is ok, and he kind of says he's not sure what a csc matrix is. I tell him it's column sparse, and proceed to quickly write out, on a whiteboard, a simple csc matrix -- basically, an array of dimension columns of ArrayList of tuple <index, value>. The constructor is pretty much
The interviewer then starts going at me because having, eg, a million columns requires an array with a million elements in it. I say yes, duh. He says it's quite inefficient -- what if I only use 10 columns out of the million? My response is, well, that's fine -- but what you're describing isn't a matrix. It turns out that what he really wanted was a HashMap from tuple: (x idx, y idx) to value, and that a typical load would be perhaps 1k elements in a space of 1 million by 1 million.We then go at it about whether I should have asked him to clarify, and I basically decide I don't have to play along with stupid gotcha questions so I told him words have meanings and a "matrix" with only 10 non-empty columns is not a matrix. And I don't have time for wankers.
At least I learned what they were like fast...
In my experience, "matrix" is a mathematical concept, and is independent of the implementation. As such, an extremely sparse matrix, such as your alleged interviewer described, is absolutely a matrix. And for such a matrix (density 10^-9), such a dictionary-style approach seems fairly reasonable.
Next, it seems to me that "CSC matrix" is a particular encoding that works well for sparse matrices, that is not related to the code that you wrote. It contains no index/value tuples, and it consists of three top-level arrays (that, in the general case, are of different lengths).
https://en.wikipedia.org/wiki/Sparse_matrix#Compressed_spars...
http://netlib.org/linalg/html_templates/node92.html#SECTION0...
http://docs.scipy.org/doc/scipy-0.15.1/reference/generated/s...
Actually, it's not obvious to me how to do arithmetic on it (without converting to a denser format), though the scipy docs say it's fairly efficient, so I'm having a little think about that. Interesting.
Anyway, sounds like you're glad you didn't get that job, and I'd imagine that they're glad they didn't get you, so everybody wins.
What makes me shake my head is you don't understand what csc matrices are but didn't let that stop you from telling me I don't understand them. HN in a nutshell.
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.
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.
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.
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.
"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.
(EDIT: this was actually a joke...)
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.
'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)
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.
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.