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

71–80 of 88 posts

Re: Coding Interview Cheatsheet

#71

Post by gervase »

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

Really puts the "free" in freelancer, too.

Re: Coding Interview Cheatsheet

#72

Post by izacus »

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…

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

Re: Coding Interview Cheatsheet

#73

Post by alasdair_ »

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…

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.

Re: Coding Interview Cheatsheet

#74

Post by mrfusion »

UncleMeat wrote: post #60
mrfusion wrote: post #40

Earlier quoted context omitted.

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.

Re: Coding Interview Cheatsheet

#75

Post by barrkel »

pavlov wrote: post #33
barrkel wrote: post #22

Earlier quoted context omitted.

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

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

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.

Re: Coding Interview Cheatsheet

#76

Post by theophrastus »

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…

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.

Re: Coding Interview Cheatsheet

#77

Post by darth_mastah »

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

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.

Re: Coding Interview Cheatsheet

#78

Post by ModernMech »

sidlls wrote: post #58
kod wrote: post #47

Earlier quoted context omitted.

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