Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Coding Interview Cheatsheet

github.com

Post reply on HN
Print view View original

51–60 of 88 posts

Re: Coding Interview Cheatsheet

#51

Post by FLUX-YOU »

seanmcdirmid wrote: post #49
FLUX-YOU wrote: post #48

Earlier quoted context omitted.

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

Re: Coding Interview Cheatsheet

#52

Post by seanmcdirmid »

FLUX-YOU wrote: post #51
seanmcdirmid wrote: post #49

Earlier quoted context omitted.

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

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.

Re: Coding Interview Cheatsheet

#53

Post by psergeant » 

    > Prepare answers to the
    > frequently-asked questions
    > in an interview.
One thing I've found works really well is literally to brain-dump any question at all I think I might get asked before the interview -- other than specific algorithmic.

I'll spend time writing that out before the interview in prose form, and make sure I've literally said the words out loud at least once before the interview.

If it's a phone interview, I can literally read out any good answers -- I'm yet to be told I sound scripted. If it's not, and I can't refer to my notes, I still find that having collated my thoughts on a subject first is pretty useful, and helps me segue into things I want to talk about.

Re: Coding Interview Cheatsheet

#54

Post by psergeant »

sethammons wrote: post #46

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

Developers seem to assume their interviewer is psychic in an interview, rather than showing their working and having an ongoing conversation

Re: Coding Interview Cheatsheet

#56

Post by gazarullz »

sethammons wrote: post #46

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

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.

Re: Coding Interview Cheatsheet

#58

Post by sidlls »

kod wrote: post #47
lr4444lr wrote: post #41

Earlier quoted context omitted.

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.

Re: Coding Interview Cheatsheet

#59

Post by dominotw »

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.

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

Re: Coding Interview Cheatsheet

#60

Post by UncleMeat »

mrfusion wrote: post #40
ekidd wrote: post #34

Earlier quoted context omitted.

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…

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.
Post reply on HN