Why we don't hire programmers based on puzzles and tricks

Post by sssilver » Fri, Feb 22, 2013, 6:38 PM UTC

jwwest wrote: post #150

The best interview I ever had, I was given a problem to solve with a system, a whiteboard and 20 minutes. I sketched out a quick ERD, and explained the high level architecture of the system. No code was written -- it was assumed that I could implement said system if I could design it. The worst job interview grilled me on low level algorithms (I'm not a CS grad) and wanted me to sketch out a quick sort. Of course, I…

Post by biscarch » Fri, Feb 22, 2013, 6:41 PM UTC

mamcx wrote: post #142

kamaal wrote: post #103

This is something to think about. The interview process is so badly gamed that these days its kind of a ceremony. In a recent interview, I gave a candidate a practical problem. He was allowed to use the sed man page, and then I gave him a file and search/replace problem. Nothing much! The candidate fails! Instead he asks me if there is going to be a algorithm/data structure interview. I told him, I don't know but as…

I do something like that. My first test is ask to reverse a string (not using the reverse function!) in any language and/or pseudocode. Is incredible how badly the test goes with the people! I interview for myself or others more than 100 people (of any background, including university, tech schols...) and I think only 10/12 people do it correctly - barely- To make it more fair, I always let them alone. And give inter…

Post by redditmigrant » Fri, Feb 22, 2013, 6:44 PM UTC

brown9-2 wrote: post #116

donw wrote: post #80

Earlier quoted context omitted.

I'm not sure if I'm that guy or not... but anyhow, here's the hiring process that's given me some good results. Note that this requires that your team does pairing. Interviewing answers three questions: Can they do the job? Do they get along with the team? And, can they adapt when the game changes? Before your phone interview, let them know that you want to do a short screen-sharing and pair-programming exercise via…

I'm curious if you wouldn't mind sharing a few more details of your experience pairing a candidate in the office with your senior engineers. - Are the candidates able to help make meaningful contributions to whatever the senior engineers are working on without having the background and domain knowledge? - Do the employees have to spend a significant amount of the 2-3 hours with the candidate bringing them up to speed…

Post by jasonlotito » Fri, Feb 22, 2013, 6:50 PM UTC

hexagonc wrote: post #231

pc86 wrote: post #114

Earlier quoted context omitted.

I don't know if this is a Silicon Valley thing or what, but the idea that someone would basically do a day's unpaid work on projects they know nothing about with three different people is just about the most foreign thing I can think of. That being said, I've never done any pairing so maybe it would work better in that type of environment.

I doubt that work important to the company is done this way. Otherwise, they'd expose proprietary information. Of course, I could be wrong.

Post by Zarel » Fri, Feb 22, 2013, 6:51 PM UTC

randomdata wrote: post #57

andrewvc wrote: post #37

Earlier quoted context omitted.

I generally agree, most logic questions are useless, but Big-O notation I use every day. Programmers who don't understand the performance difference between Array#include? and Set#include? in ruby are dangerous!

I'm curious to know where you use the notation in daily programming. In code comments? Discussions with other developers? Other documentation? I use the spirt of Big-O almost daily, but do the actual calculations rarely, and basically never use the notation. With some experience, you quickly get an intuitive feel for execution time, which is good enough in most cases.

  Zarel: and for insertions, aren't they O(nm) for n insertions into a list of size m either way?
  Cathy: inserting n elements into a list of size m when done with queueing requires at most m iterations
  Cathy: when not done using a queue, it requires at most n*m iterations
  Cathy: a factor of n is the difference
  Cathy: of course, n might be pretty small, depending on how many insertions happen in the debounce wnidow
  Cathy: n might be 10-15
  Zarel: how do you insert n elements into a list of size m in m iterations?
  Cathy: iterate over the list of m elements
  Cathy: well, i guess you'd need to sort the list of n elements first
  Zarel: oh, I see, I forgot about sorting the list
  Zarel: so it'd be O(n+m)
  Zarel: which is admittedly much faster for our purposes
  Zarel: well, considering n is likely to be approximately 5, "much" might be an exaggeration
  Cathy: in any case, i agree that inserting/deletion approach is the right way to do this
  Zarel: incidentally if we wanted we could apply certain optimizations to improve an insertion from O(n)
  Zarel: for instance, binary search
  Cathy: it's not immediately obvious whether that is faster than the sorted queued
  Zarel: actually, that's not a bad idea regardless
  Cathy: but it's certainly faster than the naive single insertion
  Zarel: I mean, O(n log m) is significantly faster than O(n+m)
  Zarel: when n is ~5 and m is ~1500
  Cathy: true, and it actually makes it clear that using a queue is unnecessary