How to conduct a good programming interview • Hacker News Board

Re: How to conduct a good programming interview

#161

Post by remline » Mon, Sep 11, 2017, 10:12 AM UTC

bryanrasmussen wrote: post #160

nolemurs wrote: post #150

Earlier quoted context omitted.

Firing is never fast or easy. It usually takes months to realize your mistake since it takes that long to get up to speed on a new job, And then you have to hire someone else, and get them up to speed. As a result, you're delayed by months, and out months of salary. Also, firing is terrible for morale. You really can't do it that often. Failing to hire a good engineer is only a big cost if you can't find a decent alt…

maybe, but if you trust your friend and he says the recruitment process sucked are you really going to want to go through it?

It's really about blasting advertising and hiring good enough cheap. The engineers with a network will know not to go through your process and would expect a salary appropriate to the job, the ones that developed a lot of skills on their own with no network (or afraid of honest discussions with peers where they might not be the best) will settle for what they are offered.

When I look at who from my network (or really missing from my network) is at the places with these tactics.. Losing time and failing to get the job is not the worst outcome.

Re: How to conduct a good programming interview

#162

Post by ubernostrum » Mon, Sep 11, 2017, 10:40 AM UTC

nolemurs wrote: post #113

sidlls wrote: post #72

Earlier quoted context omitted.

> Someone who is capable of learning what's needed to do well on a technical interview has demonstrated a fairly high level of competence, and is (relatively) unlikely to be a really bad hire. Sure, as long as their only role is repetitive coding tasks that require limited amounts of broadening their experience beyond the DS&A trivia places like Facebook require. However then Facebook ends up with stuff like their iO…

> The filter limits the applicant pool to that set of people uninterested in solving problems outside the scope of a CS textbook. The only way this would be true is if being good at textbook CS makes you bad at solving other problems. I'm assuming you don't actually think that, 'cause it's kind of crazy. Even giving the benefit of the doubt and assuming you mean that the filter makes the pool less likely to contain g…

The only way this would be true is if being good at textbook CS makes you bad at solving other problems.

The way the typical interview process works, basically, is "we have a list of 6-12 algorithms we will ask about; if you have memorized implementations of them, and certain key phrases to identify which one to regurgitate on command, you pass the interview".

This is then touted as a test of "CS knowledge" and "problem-solving ability".

Tech interviewing is Goodhart's law in action.

Re: How to conduct a good programming interview

#163

Post by ubernostrum » Mon, Sep 11, 2017, 10:44 AM UTC

nolemurs wrote: post #85

Ezhik wrote: post #48

Earlier quoted context omitted.

I think that if somebody with 10 years of actual and relevant experience fails the interview process, the interview process has a problem.

All that's required to get 10 years of experience is the ability to get your foot in the door and not do so badly that they actually fire you. It is absolutely not a guarantee of any real competence. At my last job I did a bunch of interviewing, and the very worst candidates we had were engineers with years of experience working at badly run companies. If management is bad enough, a company can't hold on to good engi…

I really really really want everyone who conducts interviews to read this:

http://blog.interviewing.io/you-cant-fix-diversity-in-tech-w...

It's based on a decent sample size, and challenges a lot of assumptions about the consistency and quality of tech interviewing practices. In particular, the person you're talking about, who says they pass only about "50%" of interviews, is telling. Quote from article:

As you can see, roughly 25% of interviewees are consistent in their performance, but the rest are all over the place. And over a third of people with a high mean (>=3) technical performance bombed at least one interview.

This is not a problem of terrible horrible no-good very-bad "fake programmer" candidates who somehow held onto jobs for years. This is a problem of interviewers who are fundamentally incompetent to conduct interviews and evaluate candidates.

Re: How to conduct a good programming interview

#164

Post by vt100 » Mon, Sep 11, 2017, 10:57 AM UTC

Apocryphon wrote: post #151

nolemurs wrote: post #131

Earlier quoted context omitted.

> The desire for a 'good candidate' and the paranoia about making a mistake is sounding increasingly utopian. I don't know where you're getting your 'perfect hire narrative' idea from; this is simple cost/benefit analysis. If making a bad hire is a lot more expensive than failing to make a good hire (and I'm pretty sure it is by a factor of at least several times - failing to make a good hire is really cheap), then y…

What makes a bad hire? Couldn't a 60-70% hire be trained up, rather than expecting all of the candidates to be 90%?

If you aim for 90%, and a few 60-70%s slip through, you can maybe train them up or fire them. If you aim for 60%-70% and end up with a 20-30%, then you have to fire them.

Re: How to conduct a good programming interview

#165

Post by edem » Mon, Sep 11, 2017, 12:38 PM UTC

nsxwolf wrote: post #43

edem wrote: post #23

Earlier quoted context omitted.

While you can get away with only basic algorithmic skills and I also agree with your points about being able to ship/talk to users/etc I think that having decent algorithms & data structures skills is essential for a developer. For example I have worked on projects where people were not able to ship a product for a year with 10 people and our new 3-man team shipped within 6 months just because we figured out that an…

You can have decent algorithm skills and not be able to demonstrate that in an interview environment. You get more than 20 minutes in the real world and you're allowed to do research. Most algorithms that developers will commonly need to use already exist and the skill is not developing algorithms but recognizing which to use and when. Understanding it enough to adapt it to specific needs. That's not the skills inter…

I did not say that you have to implement it. You just have to know which tool to use. And in most cases you only need a `Map` or a `TreeMap` or stuff like that.

Re: How to conduct a good programming interview

#166

Post by edem » Mon, Sep 11, 2017, 12:42 PM UTC

sidlls wrote: post #78

edem wrote: post #23

Earlier quoted context omitted.

While you can get away with only basic algorithmic skills and I also agree with your points about being able to ship/talk to users/etc I think that having decent algorithms & data structures skills is essential for a developer. For example I have worked on projects where people were not able to ship a product for a year with 10 people and our new 3-man team shipped within 6 months just because we figured out that an…

Counter-point: I am the technical lead on a team of 8. We ship a new data science product (or major enhancement to an existing product) about every 9 months, from inception through putting it in maintenance mode. Our products generate double-digit multiples of my team's costs in revenue and have a reputation for being the easiest to implement and most stable for our customers. We have one CS guy, who is a junior engi…

This is not a counter-point. This is what I have said:

> You just can't do well in some contexts

This means that your project is either simple enough that you don't need to know advanced CS or someone on your project actually has that knowledge.

I've also said:

> I think it all boils down to having at least a decent ability in all areas involved in order to be able to be productive in all environments.

So it seems that you are barking up the wrong tree. My point is that you need to have decent knowledge of all related areas to your project in order to be able to meaningfully contribute and this statement still stands. If you write an useful CRUD application you don't have to know how a hashtable works.

Re: How to conduct a good programming interview

#167

Post by SmirkingRevenge » Mon, Sep 11, 2017, 1:18 PM UTC

spraak wrote: post #58

What are some good resources for developing good algorithm skills for a non CS grad? Examples in JS, Python or Go preferred.

There's lots of stuff online.

Check out hackerrank.com for example. There are other sites like that out there.

Its becoming a real cottage industry, this whole IT interview prep thing.

Re: How to conduct a good programming interview

#168

Post by tptacek » Mon, Sep 11, 2017, 2:34 PM UTC

balls187 wrote: post #143

tptacek wrote: post #67

It's good to think carefully about how you interview candidates. Most of the ideas in this post are good. You should definitely let candidates type answers on computers. You should definitely work to put them at ease, in an environment that approximates their actual working environment. But really, this is window dressing. The problem is that technical interviews just don't work reliably. We have better ways to quali…

Other than the pain of being rejected (or rather the lack of validation), where does this reliability problem manifest? Elite tech companies have no problem with the current implementation of technical interviews. Engineers whos skills range from Great to Mediocre don't have a problem finding a job. Software quality has generally improved or stayed the same.

This is demonstrably false. Lots of great engineers are terrible at interviewing. If you ask around, you can get even some very high-profile devs to tell you stories about why they're not working at Google or Facebook or Amazon because of how badly their interviews went. Equally importantly: lots of terrible engineers are great at interviewing, and most people in the industry have had the experience of working alongside someone who is failing up, 2-year-stints at a time.

What's true is that Google and Facebook have such enormous budgets and such huge positive profiles in the talent market that they don't need to work hard to put together functioning teams. They're paying more than they need to and having to deal with more bad hires than they should, but it's for them a marginal problem.

Re: How to conduct a good programming interview

#169

Post by sidlls » Mon, Sep 11, 2017, 3:47 PM UTC

nolemurs wrote: post #113

sidlls wrote: post #72

Earlier quoted context omitted.

> Someone who is capable of learning what's needed to do well on a technical interview has demonstrated a fairly high level of competence, and is (relatively) unlikely to be a really bad hire. Sure, as long as their only role is repetitive coding tasks that require limited amounts of broadening their experience beyond the DS&A trivia places like Facebook require. However then Facebook ends up with stuff like their iO…

> The filter limits the applicant pool to that set of people uninterested in solving problems outside the scope of a CS textbook. The only way this would be true is if being good at textbook CS makes you bad at solving other problems. I'm assuming you don't actually think that, 'cause it's kind of crazy. Even giving the benefit of the doubt and assuming you mean that the filter makes the pool less likely to contain g…

Note I wrote "uninterested" not "incapable." There's a clear anti-engineering bias in software development, and one way that bias is exhibited is by a narrow hyper-focus on the minutiae of DS&A trivia.

Re: How to conduct a good programming interview

#170

Post by balls187 » Mon, Sep 11, 2017, 4:28 PM UTC

rimliu wrote: post #156

balls187 wrote: post #144

Being a better interviewer is important. As stated, some types of questions aren't good judge of skills, like implement mergesort. If you can implement mergesort, you probably studied up for your interview. You're not testing anything, other than did the candidate care enough to study. Interviewing should test the candidates ability to write code that is: 1. Correct (solves the problem) 2. Efficient (solves the probl…

So do you want someone who is good at explaining how they are looking for the solutions, or someone who is good at finding the solution? For me personally approaching a problem never involves a whiteboard.

I don't think I've ever been at an engineering company that didn't have whiteboards, at the very least in conference rooms--I infer from that that some portion of employees find them valuable.

Clearly someone who is good at solving problems is preferred. However, between someone who is good at solving problems, and someone who is good and can explain/demonstrate their process is more desirable.