Coding Interview Cheatsheet
github.com
Coding Interview Cheatsheet
1–10 of 88 posts
Re: Coding Interview Cheatsheet
#2Probabaly the most concise list of useful tips I've seen since I started interviewing at the big four. Yes to all.
Re: Coding Interview Cheatsheet
#3Probabaly the most concise list of useful tips I've seen since I started interviewing at the big four. Yes to all.
You must be a super genius good boy
Re: Coding Interview Cheatsheet
#4I wrote two articles about general tactics for coding interviews.
The first is the importance of giving interesting answers, rather than those that are strictly correct: https://codeformore.com/technical-interviews-interesting-is-...
The second is about showing your working -- showing the process that you use to approach a technical problem and reason through it: https://codeformore.com/technical-interviews-show-working/
Re: Coding Interview Cheatsheet
#5> 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.
Re: Coding Interview Cheatsheet
#6>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.
Re: Coding Interview Cheatsheet
#7> 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_.
Re: Coding Interview Cheatsheet
#8One 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.
Re: Coding Interview Cheatsheet
#9> 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.
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.
Re: Coding Interview Cheatsheet
#10> 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.