Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My favourite interview question (2006)

weblog.raganwald.com

Post reply on HN
Print view View original

81–90 of 100 posts

Re: My favourite interview question (2006)

#81

Post by _halgari »

supsep wrote: post #18

I beg to differ, Monopoly can be done using 'simplistic' object design. An array is the monopoly map, a user is an object and the bank is a singleton. Done.

I'm not sure why this got down-voted, but I thought the same thing while reading the article. If you store the game state as a giant hash-map (as I would in Clojure), then problems of "is-a" and "has-a" don't really exist. Especially considering that almost all squares are singletons anyway. So the game state can look as simple as:

{:unowned-properties #{:baltic} :players [{:owns #{:atlantic}}] :property-states {:atlantic {:hotels 0 :houses 2}}}

Etc....data driven design...wins every time.

Re: My favourite interview question (2006)

#82

Post by Stratoscope »

hagmonk wrote: post #56

So I tried a new approach inspired by this kind of interview question. In a nutshell: it aims to simulate the interactions you'll have with the candidate when they receive their first project, without the time burn of a full pair programming day. 1) determine the system the candidate will design. It should be an internal system or an internal oriented problem, not an external thing like Monopoly or URL shortening ser…

Thank you, that sounds like a brilliant technique!

One question: Do you let candidates know ahead of time what the interview process will consist of? That sounds like an important step that many companies leave out - whatever interview process they use.

I think if I knew before arriving that this how it would work, I'd be a lot more excited about the interview and better prepared too.

Re: My favourite interview question (2006)

#83

Post by bahmutov »

I ask a JavaScript developer to debug a small problem and then come up with functional approach to solve it. Makes for good step by step exploration. Each step can be expressed in single English sentence and then coded directly into JavaScript. Much more precise than designing OO hierarchy.

http://bahmutov.calepin.co/functional-javascript-interview-q...

Re: My favourite interview question (2006)

#84

Post by napoleond »

overgard wrote: post #71
napoleond wrote: post #26

Earlier quoted context omitted.

Your friend is an exception. I've met a few, too, but the majority of top-tier programmers I know program outside of work. I'm not talking about "hackathons" and shit like that, or github profiles--usually just personal projects for practical or amusement (often both) purposes. Heuristics are, unfortunately, quite valuable in hiring scenarios, especially for start-ups. It's also just much more fun to work with people…

>It's also just much more fun to work with people who love programming, and an easy way to tell (even if it's susceptible to a few false negatives like your friend) is to find out if they program in their own time. The thing is though, you can love programming and find that 40 hours a week of it is more than enough. I think what you'd find with this heuristic is that it tends to favor young people. It's a lot easier…

Agree completely. The heuristic should be used in the fashion of "yes is good, but no is not necessarily bad".

Re: My favourite interview question (2006)

#85

Post by napoleond »

acheron wrote: post #57
napoleond wrote: post #27

Earlier quoted context omitted.

The question is a litmus test for whether or not you're passionate about programming. That may sound unfair ("Why do I need to be passionate about this? It's just a job...") but the field we work in is constantly changing and the only way anyone has a hope in hell of staying abreast is if they really love it. So if you manage to keep tabs on the industry through your colleagues and you're excited about what you're wo…

Uh huh. "We want passionate people!" is usually code for "we're going to pay you less".

No. I mean, if that's the case then obviously just walk away but when I say I want passionate people I mean I want people who view programming as a super-power and are still excited by that idea.

Re: My favourite interview question (2006)

#86

Post by Tactic »

protomyth wrote: post #16

I generally went with a question my friend told me, "what was the last non-work, non-school program you wrote?". The theory being that a person who has used programming for something personal was probably a better candidate since they saw personal value in their profession.

In my personal experience I have found that the people that put stock in this sort of question believe in the "coder" mystique and that someone eating and breathing coding is somehow more competent than someone that treats computer programming as a professional career.

It is not uncommon for people to feel this about a number of professions such as chefs, bakers, graphic artists, etc.

However, in my experience I prefer to judge an applicant on professional credentials rather than their free time because while it may tell me quite a bit about them it tells me little about their capabilities that I couldn't find out in better ways.

Re: My favourite interview question (2006)

#87

Post by napoleond »

wvenable wrote: post #65
sray wrote: post #49

Earlier quoted context omitted.

> So if you manage to keep tabs on the industry through your colleagues and you're excited about what you're working on at work, then the personal projects are much less important, but you need to demonstrate that. I disagree. If passion is an important quality to you, then, as the interviewer, you need to ask questions that reveal whether or not the candidate has that quality. It's absurd to ask about personal proje…

I think you hit on a much better question! Just ask "are you passionate about programming?" and then ask them to defend their answer. If they code arduino robots in their spare time or simply love solving people's problems at work they have to convince you either way. That's so much better than trying to gauge their passion with a presumptive question.

The problem with phrasing the question that way is that it's way too open-ended (and likely to make the candidate regurgitate the same BS from their cover letter, which is not the point). An interviewer's job is to make it as easy as possible for the candidate to prove themselves. If they don't have side projects, that's fine--there are other questions that will hopefully provide similar information (ie. "What project have you worked on that was the most satisfying for you personally?"). But the side project question has a high signal/noise ratio.

Re: My favourite interview question (2006)

#88

Post by hagmonk »

Stratoscope wrote: post #82
hagmonk wrote: post #56

So I tried a new approach inspired by this kind of interview question. In a nutshell: it aims to simulate the interactions you'll have with the candidate when they receive their first project, without the time burn of a full pair programming day. 1) determine the system the candidate will design. It should be an internal system or an internal oriented problem, not an external thing like Monopoly or URL shortening ser…

Thank you, that sounds like a brilliant technique! One question: Do you let candidates know ahead of time what the interview process will consist of? That sounds like an important step that many companies leave out - whatever interview process they use. I think if I knew before arriving that this how it would work, I'd be a lot more excited about the interview and better prepared too.

Yes, the candidate should know in advance if there is a particularly structured interview technique being used, for sure.

Because it also requires a lot of mental commitment from the interview team as we'll as the candidate, I'd recommend using this technique as the final hurdle. I don't think you want to phone screen someone, then just toss them into this process. You need to have them cross some basic technical gate (like FizzBuzz, a take-home coding project, whatever), and have them meet a handful of people first, just to make sure they pass those early smoke tests.

In fact I think this technique works best when you want to seal the deal with a very strong candidate who is entertaining several options. Interviews should always be a two-way process, and if a candidate walks away from your interviews thinking "I had real trouble getting my point across to those people, I would never work there" then that represents success for the interview process.

The strongest candidates tend to be the ones least influenced by money and more interested in the problems, the people they will be working with, the culture and the environment of the organization. So having your interview process structured around revealing that gives you the best possible chance of matching your team with people excited to be there.

Conversely if you're a candidate, even if the company you're applying with doesn't seem to have thought too deeply about this stuff, don't despair. Hiring is one of the hardest things to do and also tends to be done by the seat of the pants (Amazon seems like a notable exception) You can impose your own structure by asking the right questions and making special requests of the recruiter. Tell them you want a chance to write code with someone! Or that you want to mock up a UI that solves a problem they have. Or you want to see what their strongest engineer thinks of your design for this service you've put together.

It doesn't matter if you're desperate for the job, or whether you wish they'd stop calling you ... this kind of stuff makes you stand out in the crowd as proactive and motivated by the right reasons.

Re: My favourite interview question (2006)

#89

Post by illicium »

bahmutov wrote: post #83

I ask a JavaScript developer to debug a small problem and then come up with functional approach to solve it. Makes for good step by step exploration. Each step can be expressed in single English sentence and then coded directly into JavaScript. Much more precise than designing OO hierarchy. http://bahmutov.calepin.co/functional-javascript-interview-q...

Designing a system architecture (Monopoly question) and solving a practical coding problem are different skillsets, so ideally you would ask the interviewee both types of questions.

Re: My favourite interview question (2006)

#90

Post by discardorama »

hagmonk wrote: post #56

So I tried a new approach inspired by this kind of interview question. In a nutshell: it aims to simulate the interactions you'll have with the candidate when they receive their first project, without the time burn of a full pair programming day. 1) determine the system the candidate will design. It should be an internal system or an internal oriented problem, not an external thing like Monopoly or URL shortening ser…

This is probably doable if you're interviewing 1 candidate a week (or one in 2 weeks). Most tech companies run through several candidates a week; and finding engineers/designers/managers who will play along with your question will be very difficult. I've been to interviews where they didn't know I was coming that day; where interviewers failed to turn up; where wrong interviewers showed up; etc. etc.

Basically, interviewing is a clusterfuck. :-)

Post reply on HN