Coding Interview Cheatsheet
github.com
github.com
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.
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.
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.
In reality it might be risky to do this, but I’d like to see that change.
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.
Unless one is already intimately familiar with interviewing, it's hard to distinguish the do and don't.
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.
Does it? Why?
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
I am the same way. But some ppl seem to care about that stuff. Perhaps, asking in advance may help. not sure.
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 .. :-). )
My anxiety issue has nothing to do with how good I am with coding, it's just about confronting people and socializing with them
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.
- 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.
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.
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.
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.
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.
Not least because the individuals concerned can't goof off doing something else at the same time.
No emotionally mature adult would conduct an interview like that, unless forced to. It would be completely unacceptable in any other professional field.
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.
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.
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.
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.
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.
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.
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.”
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.
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.
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'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.
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."
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.
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.
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.
It seems to select for poor candidates.
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...
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.
Yes, this seems to be a generalized problem
Why?