Live data from Hacker News

How to conduct a good programming interview

lihaoyi.com

101–110 of 188 posts

Re: How to conduct a good programming interview

#101
post #31

Those white board stuff reminds me when I was a CS student in the beginning of the 90's in France. We had our exams on paper. And believe me, writing LISP on paper, knowing if you forgot one parenthesis you got 0 point ("if I type it on a computer, it fails !"), was pretty and unnecessary stressful. So I relate with candidate facing that. Dude, on your day to day work, you WILL have a computer to check those ! How ca…

If you think writing lisp by hand is bad, try implementing a linked list interface in java on paper... shudder. (in fairness, we were sanely graded, minor syntax errors didn't subtract terribly from the grade...).

Re: How to conduct a good programming interview

#102

Earlier quoted context omitted.

Yeah, I'm a big fan of your approach. Unfortunately it seems quite difficult to get anyone to do it. Most companies have interview pipelines that are well-established and immutable, so only new companies are inclined to try it. And even Triplebyte unfortunately fell back on a combination of abstract coding tests and amorphous "cultural fit" criteria. It was a neat hack as a candidate to propose to the interviewing co…

Triplebyte's flaw is like that of many other take-home tests: they favor people who lied about how long it took. When I did it, I had to implement a regex parser. I knew intuitively that the state machine approach was best, but if I read up on state machines and coding them, I would bust the 3 hour limit, so I did the best I could to deliver something working within the three hours. Feedback: "Obviously the state mac…

Time limits on these kinds of things don't make much sense to me.

Re: How to conduct a good programming interview

#103

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…

There's bad developers who know algorithms and there's bad developers who don't. But I'd say that there's more of one than the other. So companies who haven't figured out a better way to weed out candidates still insist on knowing them to write on their pretty whiteboards.

I myself have already come to accept that we're all idiots and one mere human can only master a very small set of skills before already moving into retirement.

Re: How to conduct a good programming interview

#104
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…

This is my approach for evaluating new candidates as a first step. For front-end, for instance, I start with a codepen that has the basic skeleton that includes the libraries we use internally, has a few html elements styled and placed, and the required javascript boilerplate.

Then I provide 10 tasks that are written much in the way the company would put tasks in asana or git or jira. Each task builds on the previous and gets more complex. In the boilerplate they start with, there is one obvious error and one subtle one. Each step, I encourage them to write notes on how they solved it, and any questions or concerns they might have. I make myself available via chat or email if they have any clarifying questions.

They then can do it in their own time, at home. They can google, hit up documentation, stackoverflow, etc., because that's exactly how developers work. Nobody's over their shoulder, there's no arbitrary limitations, just build us some good UI code.

It's true that I've been amazed at how many candidates were stopped in their tracks at the simplest things that are well within the domain of their resume. But when I get a candidate that gets through them, hits the requirements and has clean code as a result, I've hardly ever seen them fail at a later step where we might evaluate more complex problems like working around GC slowdowns, obscure browser compatibility, first meaningful paint performance, etc.

And most of all, I feel confident that I haven't tried to "trick" anyone by having them do long-solved algorithms offline on a white board.

Re: How to conduct a good programming interview

#106
post #54

Earlier quoted context omitted.

This is an interesting candidate-first approach, but I have some concerns: This requires that candidates are experienced at the language or framework you use. Are you not prepared to take someone with different experience? What about graduates? What if their ability with one framework does not transfer to another that you end up assigning them to? Not all bugfixes are equal. If you haven't solved it yourself before,…

After I proposed the idea, they said they liked it and were willing to give it a try. They offered 1.) slight changes to the UX, 2.) add a payments feature, or 3.) some back-end bugs that need to be resolved. They asked which of them sounds most appealing as a test. This was perfect from my perspective, and after I signed the NDA I told them all of those sounded fine. I mentioned that fixing a bug is one of the best…

> One of my recent rejections came after being asked "A hammer and a nail cost $1.10, and the hammer costs a dollar more than the nail. How much does the nail cost?"

this just got me to see if i can still work through a basic high school algebra problem (yes, slowly, guess and check would've been quicker but less fun).

Re: How to conduct a good programming interview

#107
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…

This is my approach for evaluating new candidates as a first step. For front-end, for instance, I start with a codepen that has the basic skeleton that includes the libraries we use internally, has a few html elements styled and placed, and the required javascript boilerplate. Then I provide 10 tasks that are written much in the way the company would put tasks in asana or git or jira. Each task builds on the previous…

A huge advantage of this approach is how much more confident you can be that you've qualified candidates technically. You can --- and should --- exploit that confidence commercially. Change the posture of your outreach to reassure people that you're interested in applicants regardless of their background or resume. Change where you run job ads and how you word them. If you have a strong qualification process, your job ads no longer need to do any heavy lifting to get candidates to screen themselves; after all: your screening process is going to reliably distill your candidate stream down to a technically qualified subset.

At Matasano, we went from hiring almost exclusively people with a background in our field to virtually never hiring people with a background in our field in a matter of about a year --- and the quality of our new hires went way up.

Re: How to conduct a good programming interview

#108

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've been a developer for quite a while now, worked on all sorts of projects, including quite a few with odd / bespoke requirements.

And I am terrible at technical tests in interviews.

I can do the job, but unless I was to prepare for about a month I would fail, and there is no point since I can use my time for myself and still get a job somewhere else.

Re: How to conduct a good programming interview

#109
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…

>>Rather than trying to read subjective, noisy signals from in-person interviews, give candidates a small battery of work-sample tests.

I tell people the same thing, but the typical response is "that just discriminates against people who have families and other obligations and can't set aside 10-20 hours on evenings and weekends".

Re: How to conduct a good programming interview

#110
post #31

Those white board stuff reminds me when I was a CS student in the beginning of the 90's in France. We had our exams on paper. And believe me, writing LISP on paper, knowing if you forgot one parenthesis you got 0 point ("if I type it on a computer, it fails !"), was pretty and unnecessary stressful. So I relate with candidate facing that. Dude, on your day to day work, you WILL have a computer to check those ! How ca…

Writing code for tests, on paper, has been a thing in CS for quite awhile. While writing lisp for tests, I used to sometimes write the code with no parens (using indentation to denote nesting). Then I'd go back and add parens where appropriate.

    defun add-pos-only v1 v2
        let sum 0
            if and > v1 0
                   > v2 0
                + v1 v2
                nil
Post reply on HN