How to conduct a good programming interview • Hacker News Board

Re: How to conduct a good programming interview

#81

Post by fencepost » Sun, Sep 10, 2017, 8:02 PM UTC

thiscatis2 wrote: post #4

So reading over some of the questions posted on technical programming interviews I must say that I would definitely fail such an interview without studying for it for a month first. Having recently discussed job interviews of ex-colleagues that went to EBay, Facebook, Google, etc.. I wouldn't even pass the whiteboard test. However I'm shipping scaleable API's used by web and native apps, using Continuous Integration…

> No code was being shipped but hours of meetings and Slack conversations and discussions on PR's for no good reason about 0.01% improvement gains.

That may be where it makes sense to do a custom clock showing on the wall counting not minutes but the cumulative cost of the meeting. For simplicity assume everyone is making $1/minute, so a 5 person half hour meeting costs $150 just for the people in the meeting without even factoring in whether it's delaying the project.

Also, "perfection is the enemy of good" (or complete).

Re: How to conduct a good programming interview

#82

Post by jonathankoren » Sun, Sep 10, 2017, 8:06 PM UTC

HugoDaniel wrote: post #28

Here is how to do a good coding interview if you are a recruiter: 1. Do your homework: know what projects drive the interviewee (what kind of things she likes to code, what recent projects has she been involved in), make sure they are a match for your company projects and goals 2. Ask the interviewee for a git repository and take a careful holistic look at it (commit messages and code, timespan, branches, merges etc.…

Not everyone has a public git repository, let alone one that they commit to regularly. You're selecting for people that have tons of time outside of work and want to spend that time basically doing the same thing they get paid to do at work. Also, if they're writing for themselves, what makes you think that it would be production quality rather than just a collection of semiuseful hacks they want to be able to download occasionally?

Re: How to conduct a good programming interview

#83

Post by monkeywork » Sun, Sep 10, 2017, 8:07 PM UTC

diggernet wrote: post #37

EGreg wrote: post #20

Earlier quoted context omitted.

This may be like "approach anxiety" for when guys never strike up a conversation with a woman they are interested in because they think all women will reject them. Why not try and go on some interviews? How can you possibly know you will be rejected without even going on one interview? Do you think all companies are the same, and your competition is all prepared for whatever it is you imagine they are doing? You're s…

I believe your error here is "without even going on one interview". There are many developers who have proven their skills and abilities on the job, and also have a proven ability to repeatedly fail interviews. This is precisely why the developer interviewing process is such a hot topic here.

are you suggesting that if you have "proven yourself " you should be able to skip the interview process?

Re: How to conduct a good programming interview

#84

Post by jonathankoren » Sun, Sep 10, 2017, 8:10 PM UTC

HugoDaniel wrote: post #74

mwcampbell wrote: post #57

Earlier quoted context omitted.

I think you missed the part where the OP said not all candidates are willing or able to work on open source projects.

Well the .2 "Ask the interviewee for a git repository" can be a private repository. It is a very hard problem to solve if they have no visible code to show but it does happen in other areas. Imagine asking for a management candidate for the private e-mails he shared in certain tricky situations of previous jobs. Or even public e-mails. Or even to take 40 minutes to write in a whiteboard a team statement for a certain…

> Well the .2 "Ask the interviewee for a git repository" can be a private repository.

If someone shares a private git repo, they should not be hired, and in fact should be fired from their current job, and possibly sued. (Think Anthony Levandowski sharing Google lidar designs as an example of his work with Uber.)

This isn't promoting trust. This is a violation of trust.

Re: How to conduct a good programming interview

#85

Post by nolemurs » Sun, Sep 10, 2017, 8:15 PM UTC

Ezhik wrote: post #48

khc wrote: post #22

Earlier quoted context omitted.

As a counter example, I also have about 10 years of experience, but never studied for interviews. On average I pass about 50% of the interviews at companies big and small (ex: passed Google, failed Facebook). I think people often looked at questions and think "there's no way I can do them", but many times you can get some hints and use enough first principles to do well enough. Individual questions are often bad indi…

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 engineers. As a result, they end up with just the engineers who can't go elsewhere. Since these companies are filled with bad engineers, there's no culture of learning, and an engineer who isn't really motivated can go years learning basically nothing.

Experience is great, but it's totally possible to go a decade without learning much.

Re: How to conduct a good programming interview

#86

Post by throw2016 » Sun, Sep 10, 2017, 8:16 PM UTC

nolemurs wrote: post #53

thiscatis2 wrote: post #4

So reading over some of the questions posted on technical programming interviews I must say that I would definitely fail such an interview without studying for it for a month first. Having recently discussed job interviews of ex-colleagues that went to EBay, Facebook, Google, etc.. I wouldn't even pass the whiteboard test. However I'm shipping scaleable API's used by web and native apps, using Continuous Integration…

> I completely understand the need for these technical interviews and weed out obvious bad programmers and get experts on board but sometimes from a business point of view it just doesn't make sense. The thing is that the main goal of the technical interview is not to hire all good candidates. The main goal is to avoid hiring bad candidates. A large high paying company like Facebook has plenty of candidates to choose…

The desire for a 'good candidate' and the paranoia about making a mistake is sounding increasingly utopian. There is a certain nervousness and even a hint of hysteria about it.

A bad hire is not the end of the world, and is easily corrected and one can't help feeling there is some magnification going on somewhere about hiring mistakes. There is near constant evaluation and feedback loops in most organizations. A 'bad hire' simply won't survive this.

No ones hires a person not suited to the job in terms of technical requirements, that's a given, but there are other things at play to make the final decision, that are less easily obvious in the interview process so mistakes will be made. Better to make them and move on rather than manufacture this increasing hysterical narrative about the 'perfect hire'.

Re: How to conduct a good programming interview

#87

Post by jonathankoren » Sun, Sep 10, 2017, 8:18 PM UTC

I have to disagree with this trend of having people write code on a computer instead of a whiteboard. Sure, it mimics the real world, but in practice you spend a bunch of time dealing with crap about syntax errors, and argument order mismatch instead of dealing with the actual underlying algorithm. Even worse, you may end up with a candidate that realizes that there's probably a library that would be really useful for this, but then has to spend time googling for the name of the library, then installing it, and then desperately skimming for a quick start in documentation because the question isn't, "Can you work google and run pip install?", but rather some other task. So now you've probably lost 15 minutes just dealing with that shit.

If you're going to do this, it simply doesn't work in a 40 minute setup without some sort of provided scaffolding and test cases.

Re: How to conduct a good programming interview

#88

Post by tvelichkov » Sun, Sep 10, 2017, 8:22 PM UTC

nolemurs wrote: post #68

tvelichkov wrote: post #62

Earlier quoted context omitted.

>> The cost of failing to hire a good engineer is small I'm not so sure about that. https://en.wikipedia.org/wiki/Jan_Koum "In September 2007 Koum and Acton left Yahoo and took a year off, traveling around South America and playing ultimate frisbee. Both applied, and failed, to work at Facebook." "On February 9, 2014 Zuckerberg asked Koum to have dinner at his home, and formally proposed Koum a deal to join the Faceb…

It seems unlikely to me that as a full time Facebook engineer Koum would have still had time to create a multi-billion dollar startup. It also seems unlikely to me that he would have been motivated to put in that work for an employer, or that Facebook would have given him the time or freedom necessary to do it. If he had been hired, he'd have probably been a fine engineer, but there's really no reason to think he'd h…

Are you saying that Facebook employees are not motivated to work? Or that now after he has been hired, he is not adding any value anymore?

Facebook is a multi-billion dollar startup and its created by the people working there. So it may not be my favorite company, but I give respect to that, and the people working there.

I can't say what's the skillset to be an effective engineer at a large company, but I do believe that it must be a SUBSET of the skillset required to create a successful startup.

Re: How to conduct a good programming interview

#89

Post by caconym_ » Sun, Sep 10, 2017, 8:30 PM UTC

thiscatis2 wrote: post #4

So reading over some of the questions posted on technical programming interviews I must say that I would definitely fail such an interview without studying for it for a month first. Having recently discussed job interviews of ex-colleagues that went to EBay, Facebook, Google, etc.. I wouldn't even pass the whiteboard test. However I'm shipping scaleable API's used by web and native apps, using Continuous Integration…

Depending on the domain, a lack of ability on either side of the soft/hard skills line can lead to missed opportunities to deliver a great product. If you don't have at least one or two skilled implementors on your team (or if those people are marginalized by a culture that isn't able to recognize good technical decisions), you'll be severely limited in what you're able to build, and what you can build will probably suffer in quality.

There's a difference between practical technical excellence and over-the-top bikeshedding/obsession with needless optimizations.

Re: How to conduct a good programming interview

#90

Post by Goopplesoft » Sun, Sep 10, 2017, 8:31 PM UTC

majormajor wrote: post #55

Goopplesoft wrote: post #29

> 5 minutes of resume discussion > 45 minutes of coding As anyone else found that a good resume discussion is often much better than the coding component? I've concluded that implementation difficulties, decisions made (tradeoffs, technologies, etc.) and the collaborative environment around projects, are much better signals than the code part of my interviews. If you've dealt with a broad range of tech and can ask th…

Yeah. If they can't tell me about what they've built before, and aren't a less-than-one-year-away-from-school new grad, I'm going to be wondering how they deal with real problems regardless of whatever they can do algorithm-wise. If someone can talk about what approach they took, what other approaches they considered, what made it hard, what made it easy, how often the requirements changed, etc, then I'd rather ask t…

> Just do some small spot checks to make sure they aren't taking credit for the work of others.

Agreed, asking tough technical questions on this front gives a really solid indicator of a 'bullshitter'. For example, I often ask people to diagram a prior project architecture they worked on, and then ask them very fine details of how things work and try to challenge them with alternative approaches to see how they react. I get to experience working with them during the interview through which I learn if they're smart and capable.