Coding Interview Cheatsheet • Hacker News Board

Re: Coding Interview Cheatsheet

#61

Post by user5994461 » Sat, Oct 14, 2017, 4:26 PM UTC

yangshun wrote: post #20

kevmo314 wrote: post #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.

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.

Re: Coding Interview Cheatsheet

#62

Post by [deleted] » Sat, Oct 14, 2017, 4:33 PM UTC

ekidd wrote: post #34

pavlov wrote: post #15

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 w…

[deleted]

Re: Coding Interview Cheatsheet

#63

Post by tzhenghao » Sat, Oct 14, 2017, 5:03 PM UTC

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.

Re: Coding Interview Cheatsheet

#64

Post by bostik » Sat, Oct 14, 2017, 5:04 PM UTC

abhishekpathak wrote: post #9

kevmo314 wrote: post #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.

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.

Re: Coding Interview Cheatsheet

#65

Post by nojvek » Sat, Oct 14, 2017, 5:27 PM UTC

nsxwolf wrote: post #57

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.

Re: Coding Interview Cheatsheet

#66

Post by raisyer » Sat, Oct 14, 2017, 6:09 PM UTC

"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...

Re: Coding Interview Cheatsheet

#67

Post by reddit_clone » Sat, Oct 14, 2017, 6:12 PM UTC

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 .. :-). )

Re: Coding Interview Cheatsheet

#68

Post by asdojasdosadsa » Sat, Oct 14, 2017, 6:27 PM UTC

reddit_clone wrote: post #67

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…

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

Re: Coding Interview Cheatsheet

#69

Post by [deleted] » Sat, Oct 14, 2017, 6:34 PM UTC

reddit_clone wrote: post #67

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…

[deleted]

Re: Coding Interview Cheatsheet

#70

Post by lithos » Sat, Oct 14, 2017, 6:37 PM UTC

reddit_clone wrote: post #67

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…

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.