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…
How to conduct a good programming interview
101–110 of 188 posts
Re: How to conduct a good programming interview
#102Earlier 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…
Re: How to conduct a good programming interview
#103So 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 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
#104It'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…
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
#105All his example interview questions are stuff that were actually used at Dropbox!
Re: How to conduct a good programming interview
#106Earlier 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…
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
#107It'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…
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
#108So 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…
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
#109It'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…
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
#110Those 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…
defun add-pos-only v1 v2
let sum 0
if and > v1 0
> v2 0
+ v1 v2
nil