Hacker News new | past | comments | ask | show | jobs | submit login
Coding Interview Cheatsheet (github.com)
294 points by yangshun on Oct 14, 2017 | hide | past | web | favorite | 78 comments



As far as a general behavior checklist, this one is fairly accurate in my interviewer experience. It is surprising how often candidates do many of the "Don'ts" in the list.

In the end, I'm looking for candidates I can see myself working with. If we were to pair up on a task or project, I want to be reasonably sure I'm not going to dread the event; I should look forward to it.

One example was a candidate from one of the Big 4. He was having trouble in Java (his preferred language) handling 400 and 500 level errors in an HTTP request that was part of the interview problem. I told him at the beginning that he can use whatever resources he wants, etc. I also told him that I am not a Java person but would help him where I could (we are not a Java shop). While he was reading documentation, I googled how to handle the errors, and said something along the lines of, "it looks like you should be able to do such-n-such with whatever class's method." He just said, "no." A few minutes later, still stuck, I suggested that he give it a try. "That's not how that works." We had to eventually skip the error handling to get back on track.

What I got out of that part of our interaction was that he wouldn't likely be pleasant to work with. He could have said why my proposal would not work or anything beyond simply dismissing my attempt to help. I got the distinct feeling of, "this guy is kind of a jerk." He was applying for a senior developer position. Part of that role would be mentorship and leveling up your team (this was explained early on in the process, before the on site). With our limited time together, he did not convey anything of the sort.

Post interview, he mentioned to our interview organizer / in-house recruiter that it was apparent I did not understand Java development. Post interview, I also took his submitted code and implemented my suggestion and it worked.

In short, I think much of the post's checklist is accurate. Behavior during an interview counts. It is not just technical aptitude.


I wonder if that's the reason why he wasn't at one of the big 4 anymore :)


But he did end up there somehow in there first place. What was his interview them like, I wonder?


Omg, I had someone in my team that was hired the same day as me and we would both be a no-match work-wise.

All my suggestions and ideas would just be dismissed as wrong and everything that person was doing would be right without explaining the why I was on the point of depression and got me thinking more than once about quitting my job but I liked the company too much.

It ended up with that person leaving. win-win.


> Defensive coding. Check for nulls, empty collections, etc.

While this is important to avoid bugs in your algorithm, I've had candidates who spent way too long on this and it comes across as inexperienced. I don't really care that you know how to check null-ness, if you just mention "assume the parameter is not null", it's more than sufficient to me.


Which is why the best thing is to ask. I always tell my candidates that the most important thing is how they approach the problem and not how careful they are with their coding. However, if the interviewer doesn't explain that, the best thing is not to do "Defensive Coding" as per the linked article, but instead to _ask_.


I think it’s be better if interviewers and interviewees wrote code like they would in the job - no excessive commenting/checking ... just write effective, clean concise code and minimize time wasted

In reality it might be risky to do this, but I’d like to see that change.


I generally don't know where in the code to "defend" until I've actually written the algorithm -- I don't start writing during whiteboard coding or coding sessions with a solution in mind, I start with the first (okayish) thing to come to mind and iterate from there as I run into problems or edge cases. (Example: do I need to guard empty lists or not? Well, it depends on if I for-all over the list or try to index explicitly.)

So in terms of writing flow, it usually goes something like core work function/code, often as helper functions -> control flow structure -> guarding, edge cases, etc.

This also works well for a conversation: how do we model/solve the core problem? how do we want this to actually execute? what are our constraints, special cases, etc? You're moving from the general (abstract problem) to the specific (guarding bugs in my code).

This has worked out reasonably for me.


> Example: do I need to guard empty lists or not? Well, it depends on if I for-all over the list or try to index explicitly

Does it? Why?


An actual example of this concept coming up:

I had a question about something with a distance formula, and the choice to either explicitly check the length of the points coming in, which were a list of coordinates, (either to ensure a particular dimension or a matching dimension) or another option to iterate over the components, which has a sane "dimension extension" behavior.

It wasn't until I looked up the available floating point math functions that I knew their limits and could decide on how to implement the dimensionality handling.

So in that case, my thought process went:

Figure out the math -> Figure out how to apply it, eg map to a list of pairs of points (which also constrains math implementation) -> implement guarding on input to match contract


Defensive coding always breaks my flow during problem-solving. However, thinking of edge cases reflects a programmer's maturity. I usually trade off by writing a short comment (# check for null) during the flow and then revisiting that part later.


I'm somewhat of two minds here, to be honest.

First, depending on the situation I can find myself practicing "Paranoid Programming". It's an approach I picked up in my C days when I had to deal with network protocol code. Essentially: switch-case with every conceivable error condition handled and then the happy path as the final, unlikely edge case (Also: "default" case always triggered an error.)

On the other hand it's a really depressing way to write code. When 80% or more of your dispatcher logic is dedicated to error handling, following the actual logic can be really cumbersome. On the positive side, once you are in the proper code, you have far less edge cases to worry about.


>if you just mention "assume the parameter is not null", it's more than sufficient to me.

I am the same way. But some ppl seem to care about that stuff. Perhaps, asking in advance may help. not sure.


I usually am explicit in saying something along the lines of "Can it be assumed that I know how to do argument null checking, if possible, and not pollute the whiteboard?" and I've gotten a "Yes" and then after writing the function on the whiteboard: "Well what about <something relating to argument nullability>?"...so you should ask but YMMV


Thank you for the feedback, I have tweaked the wording accordingly (:


Just my 2 cents: It would be nice to start all the don't sentences with "Don't ..."

Unless one is already intimately familiar with interviewing, it's hard to distinguish the do and don't.


I would rather coding interviews went like this.

Give the candidates a non-trivial problem, which might take a few days to complete. Everything documented and checked into github. Call them for interviews and review design/code with them. Make sure it was not all copy-pasta and someone else didn't write it for them.

To make sure of that, introduce a slight variation in spec and ask them to do it on the spot.

This way, you get to review their entire development process, How they approach problems, code quality, unit tests, code performance , usage of source control system, CI/CD usage etc. At this point you will know for sure if you want them or not (They might also know they want to work for you or not .. :-). )


Sounds like a great way to filter people who have other responsibilities, or are an attractive enough candidate to be busy interviewing for other firms.


Absolutely. I second that. I would be willing to spend a couple of hours on an interview task, which could give the interviewer an idea about my skills, but more than that I would see as an overkill. Besides, in my view, showing some OS repos on GitHub can be a good alternative.


Really puts the "free" in freelancer, too.


This works if you're willing to pay someone a few thousand dollars to do this. If not, the only people that are likely willing to go to this much trouble are new grads and the desperate.

For more experiences/senior developers who already like where they work, it's already pretty difficult for a recruiter to convince them to come in for a full days worth of interviews.


A large employer in my past used to apparently conduct just this sort of "interview". I learned to my disgust a few years later that the division conducting those "interviews" were doing what they called a "brain suck". That is, they never intended to hire anyone, they were just using the unlucky "interviewees" to help them solve a software engineering problem for free.


I second this. I have some anxiety issues and someone looking at me while coding _the whole "answer"_ would be a really horrifying experience.

My anxiety issue has nothing to do with how good I am with coding, it's just about confronting people and socializing with them


A couple small touches that have helped me power through these interviews:

- Food intake prior to the interview. If I get phone interviews later in the day, especially after lunch, I avoid eating heavy and greasy food that can put me in a food coma. It has negatively impacted my performance in a couple of interviews back during my college days. Controlling my caffeine consumption before an interview helps too. I had a pretty bad "crash" in one of my onsites.

- If I'm expected to do puzzle questions, it's best for me to warm up 45 mins before the interview just to get my mind in a problem solving state.


>Stay calm and composed.

Ironically, reading this makes me hyperaware.

>Sound enthusiastic! Speak with a smile and you will naturally sound more engaging.

In my experience, some people force this and it comes off a bit creepy. I've had better luck not thinking about this.

IMHO don't treat the social side the same way you treat the technical side (i.e. preparation similar to homework). The social side should not be overly deliberate. Don't overthink it, just be polite.


You're right, I feel like a lot of stuff on this list will just cause overthinking. Just be yourself, don't be weird.


You’re going to have a real working relationship with these people. I don’t think it makes sense to have a working relationship where you’re concerned so much about appearances. Don’t need to treat interviewers like they’re hypersensitive to your social behavior.


Isn't all this just common sense? It basically says "be a nice person to communicate with". But split up into a huge table of checks and crosses.


Yes, but you’d be surprised how many candidates either get too nervous or are too shy to do most of these.

Phone interviews are hard to begin with but you also have a lot of flexibility so it’s less stressful, but in-person interviews with real programming on a computer can put many into a really stressed state.


Should add: spend effort making lots of industry friends and contacts. Tell them you’re looking for a job. Skip coding interview.


Coding interview is a very elemental part. You can deffo skip phone interview.


This document is new but here’s a discussion of the repo from a couple weeks ago:

https://news.ycombinator.com/item?id=15341566


We do a lot of technical interviews and have seen enough candidates skip on many of these, so in that respect I like that there is a list they can reference. However, doing for the sake of following a list can come off as inexperienced/dishonest (or creepy, like one of the comments suggested).

Having seen those first hand as well I can tell you I really dislike such interviews and that they always make me and whoever else is interviewing with me uncomfortable.

My advice is to go through this list and reflect on your last interview. What did you do, what didn’t you do, why? And try to practice some of the things you didn’t.

Also, keep in mind some of these are double edged swords. Example, speaking with enthusiasm. Don’t do it at all and you’ll be boring everyone, but do it too much and you’ll look like you can’t concentrate.

Practice makes perfect, so work on it.


One thing that's missing here is video camera feed. As an interviewer, I don't turn on my webcam and I don't expect the candidate to do it (although they can if they want to). However, I've heard different people have different opinions on this. It's definitely something that could go on this list for phone interviews.

Of course, intra-US interviews are usually done over the phone but when the interviews are across countries, tools such as Google Hangouts are normally used.


I'd like to know beforehand when people call me if video is expected or not. A friend of mine ended up answering with video, but the interviewer only used voice. Then felt it was too late to turn the webcam of, and ended up in a weird one-way session making the experience even more stressful.


This seems quite odd to me. I work with people remotely and on site, and it's amazing how much better communication is when both parties turn their webcam on. Body language conveys things that tone, and words don't


> communication is when both parties turn their webcam on

Not least because the individuals concerned can't goof off doing something else at the same time.


Indeed this is something that deserves a mention in the list. Have added it!


Personally would not even look at the webcam, so it’s less awkward when I’m not expected to.


Probabaly the most concise list of useful tips I've seen since I started interviewing at the big four. Yes to all.


I can’t think of any other field where highly paid adult professionals willingly submit to interviews that treat them like autistic 15-year-olds. Makes sense for the companies, of course.


I've interviewed a fair number of programmers over the years. There's a surprising number of people who interview well and who have good resumes, but who can't actually code. (By "can't code", I mean, "Can't sum an array of numbers in their favorite programming language.") And checking references is hit-or-miss in the US, where many employers will only confirm title and dates of employment.

I know of three possible ways to evaluate coding ability:

1. Ask coding questions in interviews. This is biased against people with performance anxiety.

2. Give people take-home "work samples". This uses up more of a candidate's time, and it may filter out high performers with multiple offers. Plus, if you give anything that takes more than a few hours, it really ought to be paid.

3. Ask for a GitHub profile with open source contributions. This is biased against people who leave work at work, or whose previous employers don't contribute to open source projects.

It's been a few years since I last interviewed candidates, but if I were designing the interview process, I'd probably want at least one of the above before hiring a candidate. Maybe the candidate could choose? "If you have public open source contributions, please submit a link and a description. If you don't, no worries! We'll can do a coding test instead."


After an initial phone screen, we give candidates a short programming exercise that they can complete on their own time. We feel that engineers work best when they have time to think about a problem and work on it at their own pace with their own tools.

If the solution passes some objective criteria that we have, it then forms a significant component of the on site interview where we discuss their solution in depth and have them talk about the decisions they made and opportunities for improvement. Not only does this allow us to ensure that they actually wrote the submitted solution but it gives the candidate the chance to speak from a position of authority on their own code.


3. Or who worked a lot for previous employers or took school seriously. GitHub full of contributions is hard if you work 40 hours a week without slacking at work, basically impossible for those who do a lot of overtime. People who spend their out of work time learning (e.g. reading books or other theoretical stuff) are out too.

But really most importantly, it is important for reviewer to be prepared for things like performance anxiety, like shy people who are not good at looking confident, to people cant think out loud (don't hold it against them if they are silent for few minutes for christ sake) and so on and so forth.

But people here throw temper tamtrum over really simple well known questions.

Maybe the companies would to the best if they made their expectations clear and realistic in ad itself. Let people know how interview looks like before hand, let them know what exactly it is you expect and then stick to it.


As someone with performance anxiety take-home programming "challenges" have been my bread and butter.

I have no problem working 2-3 hours on an assignment to demonstrate my knowledge. Those at least seem more realistic than some of the interview questions about the most nuanced aspects of programming.


Why not let candidates choose between 1,2 and 3?


Because then it is hard to have a consistent and fair method of judging candidates.


Seems like you can’t compare even if you stick to one method. Some people have performance anxiety or social anxiety and can’t do 1. Others thrive on 1.


You might want to filter out those people.


Is that very important? As long as you get a good candidate..


Is there any other field where the interview has become a field unto itself? A field where a person can walk in with over a decade of experience and then not get past the first interview because he doesn't know topics he hasn't used since college? A field in which because you don't commit yourself to 40 hours of work at work and then an additional 40 hours of work outside, companies won't look at you? Joy of coding!


Is there any other field that is so technical and yet refuses to widely recognize an accreditation body that could establish this in an industry-wide way?


Speaking as a programmer who is also a licensed attorney, accreditation is not a solution.


Speaking as a person who could have gone down the path of becoming an accredited engineer but chose physics, and who has a number of friends who chose the accreditation path, I disagree.


Could either of you expand on your stances?


Accreditation in engineering is about certifying some level of competence according to the industry standards and practices. To the extent the accreditation is trusted, it means a person so accredited has already been vetted for some level of proficiency in the field.

There are plenty of CS degrees with ABET accreditation, for example. There are comparatively few for Software Engineering. The two are different disciplines. The friction in this context is that many companies wanting software engineers of varying levels of experience structure their interviews to test CS degree trivia. For whatever reason the basic competence of an accredited degree is simply ignored in the interview process.

My friends who graduated from accredited engineering programs and became Professional Engineers after don't have to prove to the satisfaction of some individual contributor that they did so by white boarding crap from their undergrad days: the certificate and accreditation is their proof.

As they gain experience, if they look for other jobs (which happens infrequently, actually: the culture of real engineer disciplines is different from computer based ones), that experience is trusted. They don't have to re-live it, so to speak, five times to five different people looking for anything to nitpick.

It's not perfect. But it makes me wonder why the CS and SE accreditations seem to have so little weight in this industry.


> It's not perfect. But it makes me wonder why the CS and SE accreditations seem to have so little weight in this industry.

That's easy, you can thank people like ESR and the hacker mentality and meritocracy myths for this. I appreciate the underlying idea, which is the same in every skilled based profession, which is that self learning and good skills are more important than formal education and accreditation. However, the two are not mutually exclusive.


I learned to program at 8. My last 15 years of professional work have been in software development. I've led teams, spoken at major conferences, made significant contributions to open source software. I have never taken a CS course for college credit.

I've been a licensed attorney for most of that time. All it required was me being willing to spend 3 years in school, then sitting in a room and writing for 3 days to pass the bar. Since then I spend one weekend a year listening to audio books for continuing legal education, and don't otherwise practice aside from minor advice at work.

Which job would you be more likely to hire me for today? It'd be borderline irresponsible to hire me as an attorney, but I've proven myself time and again as a competent programmer.

By contrast, I've interviewed people with master's degrees from reputable CS programs that couldn't explain what the Big O complexity of an array index operation was. I've known attorneys who fundamentally did not understand the purpose of their work.

Accreditation is just a measure of someone's ability to pass accreditation, not their ability to do the job.


Can you elaborate on the interview practices for attorneys which you think are just as bad?


The primary task of a developer in a modern "agile" team is to take a small bite-sized piece of functionality and alter or add code to implement it.

A very large number of job candidates aren't very good at this. So something like it needs to be tested for.

Personally, I love code. For me, an exercise like this is like whittling or molding clay, tactile and creative. I wouldn't want to work for a company that isn't interested in my craftsmanship, independent of everything else at higher levels of abstraction or closer to the business. Why? Because it will hire other people who don't care, and the code will be ugly, and it will be an eternal uphill battle to stay sane.


You make the job sound rather dire. Whittling on an assembly line; the meticulous craftsman who polishes corners of industrial furniture. I’m not convinced there is much future for the kind of programming that pretends to be a guild of humble craftsmen inside industrially directed corporations.

Regardless, the coding interview process doesn’t seem to measure creativity or craftmanship. Consider industrial designers, people who actually sometimes do mold clay as part of their job. If a company is serious about hiring an industrial designer, would they administer a test like this: “You now have 45 minutes to whittle a miniature bust of Mozart out of this piece of driftwood. Make sure to talk while you’re working so I can understand your thinking.”


Whittling on an assembly line

That's what modern programming is, as I see it. I mean, as you get more senior, you get more control further up the assembly line, but it's still shaped like an assembly line and ideally the programmers are replaceable, because otherwise they become a business risk.

I'm not necessarily a fan, of course. I invest myself in my work; that means I like a sense of ownership, where code is almost like a garden that grows over time. But the business will be concerned that if code is owned by people, resourcing is less flexible and, in the worst cases, individuals can become bottlenecks.

BTW, if you've seen a skilled sculptor at work, you might not be so glib about your 45 minute bust. But of course programmers are not like industrial designers; they're like the mostly unacknowledged craftsmen. Coding is closer to carpentry than architecture.


Trouble is, this ability is very hard to test for. A test is always an isolated, well defined problem, where the solution is written in a vacuum.

But this is completely unrepresentative of the actual kind of programming tasks at work (in my experience).

Modifying the behaviour of existing code, that you didn't write, in a way that minimises technical debt, is a completely different challenge.


your argument begs the question of whether or not we can successfully test for this trait to begin with.

i don't think we can. the outsized productivity impact a good person can have far outweighs the statistical probability of getting one if you simply accept all competent interviewers, i.e. the expected value is so high that you can blindly hire until you find one, given sufficient financial resources. without the financial resources, you only hire people you already know are good, which is the general pattern i've seen over 20 years working in this industry.


I suspect part of the cause is the prevalence of asperger-like personalities in the IT-field.

No emotionally mature adult would conduct an interview like that, unless forced to. It would be completely unacceptable in any other professional field.


I have to conduct these interviews and it kills me inside every time.

I hated it as a candidate, but a year or two ago when I interviewed the questions were a bit easier and expectations were slightly lower.

Now with the rise of Top Coder, Leetcode, etc. many candidates have practiced problems to death and can recite almost entirely from memory complex problems.

The bar is raising all the time as a result. It's not enough to convey the idea on a whiteboard with reasonable code, maybe a semicolon missing.

Now we're more or less expecting 100% compilable code, passing suites of test cases, and sometimes even multiple problems solved in 45 minutes.

It's tailor made for coding competition contestants and crammers. And then they get on interview loops and hiring committees

I'm dreading my next job search.


>The bar is raising all the time as a result.

I don't get why it would be that way. Your work's complexity isn't moving as fast as Top Coder, Leetcode, etc., so why is the interview's difficulty pinned to the difficulty on those websites?

If you guys are taking on new practices and doing more difficult things, then that makes more sense.


The problem is simply filtering, it sounds like. It's like grade inflation: the better grades all around don't necessarily indicate smarter students overall, but now you have to select them at a higher bar.


>now you have to select them at a higher bar.

I don't follow.

If you have an interview that reflects the daily work and challenges of your business, having a large pool of candidates able to do that work is a good thing. The only reason to peg your difficulty to some independent institution is to offload the trouble of making that technical interview. Your business isn't weird or failing if it doesn't have some percentage of candidates failing the interview.


You assume that the test is directly correlated with aptitude and it simply isn't true. Finding the best candidate for the job is really just a matter of filtering out the best you can hire, all the activities in the interview are designed to filter. If people start gaming the system (e.g. By practicing interview questions) that doesn't make them more apt, it simply makes interviewing (and hence filtering) much harder.


> Makes sense for the companies, of course.

It seems to select for poor candidates.


I agree with you but I’m sure this will be flagged unless you tone it down


"Ask about your interview performance. It can get awkward." Maybe it's just me, but I always find that to ask for/give feedback is better(if asked), as recruiters almost never respond if you have not cleared the round and if there is opportunity to give feedback so that candidate has an idea on what to work on.

Also I have found that when asking for feedback, it can lead to interesting discussions which might make the interviewer change his/her mind.

This of course is personal preference...


One of the problems is you are not likely to get truly honest feedback. That opens things up to dispute, and that puts the interviewer in an awkward position: if they cannot articulate a point properly, even if valid, the interviewee is left feeling they should have "passed". In the worst case, they could claim the interviewer was prejudiced against them and file a labor dispute or lawsuit.

It's also often highly subjective, for example:

"I don't think you demonstrated the depth of knowledge in (technology x) we're looking for in this position"

"Well I've developed several applications that work, so clearly I do know it"

What you can do along the way is ask questions like "Would you like me to elaborate on that?" or "did I answer your question adequately?" if you get the sense you may not have. For code, the list on the page is actually decent - ask up front about the assumptions, how much you should focus on defensive coding, etc.


> There were times I had to restart Chrome to get Hangouts to work again.

Yes, this seems to be a generalized problem


This fixes the wrong problem. Has anyone seen a whiteboard managing interview for IT managers?


> Immediately announce that you are done coding.

Why?


Because if you immediately announce that you are done coding, you cannot do any of the other things on the list, which are all good ideas. After you've done them all, you should announce you are ready. It's probably a good idea to tell the interviewer what you are doing, don't just stand there looking at your code in silence if you can avoid it.




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: