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

51–60 of 100 posts

Re: My favourite interview question (2006)

#51

Post by ignoramous »

danso wrote: post #3

Probably should have checked before posting...this was discussed 4 years ago: https://news.ycombinator.com/item?id=2062889 (so I guess it's eligible for re-discussion) I stumbled across it doing a Google search for "interview question elevator design"...I haven't been asked in a technical interview about how I would implement the logic for an elevator controller, but I heard about the question second-hand at a colleg…

I've come across the elevator design question in one of my graduate courses. I remember that one way to solve the elevator problem is to use Petri Nets (from the exotic world of graphs, math-modelling, and reliability engineering).

http://en.wikipedia.org/wiki/Petri_net Simulation: https://www.youtube.com/watch?v=59jW9dngt_c

Re: My favourite interview question (2006)

#53

Post by rhc2104 »

pearjuice wrote: post #30

I don't have been to coding interviews recently but is this what it is like these days? How long do these questions generally take to complete? When I hear white boards, UML diagrams and OO-design I am thinking about investing at least a few hours. Back in my day there were no interviews like these. You just dropped your CV, had a chat with the guy and if it clicked you got a contract with a month on (paid) trial. Wh…

Paid trials also work (for example, I was a contract-to-hire at my current job).

But many people don't want to leave the security of their current job for a temporary contract, so you would need to spend more time vetting those candidates.

Re: My favourite interview question (2006)

#54

Post by greenleafjacob »

danso wrote: post #3

Probably should have checked before posting...this was discussed 4 years ago: https://news.ycombinator.com/item?id=2062889 (so I guess it's eligible for re-discussion) I stumbled across it doing a Google search for "interview question elevator design"...I haven't been asked in a technical interview about how I would implement the logic for an elevator controller, but I heard about the question second-hand at a colleg…

> What's the cutoff in last-second button pushes to prevent the elevator from too abruptly stopping?

A good starting point might be to have a stopping distance table for whatver the definition of "graceful stopping" is. Then, the elevator stops iff at the time the button is pressed, the stopping distance is less than the distance from the top of the elevator to the top of the floor, i.e. it doesn't need to backtrack.

Re: My favourite interview question (2006)

#55

Post by Bahamut »

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.

I have worked with many excellent developers who don't program in their spare time - you cannot rely terribly highly on the answer to this question.

Re: My favourite interview question (2006)

#56

Post by hagmonk »

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 services.

2) stack your interview team with a mixture of people who can contribute different thoughts to this problem. Engineering, UI, marketing, management, etc.

3) first interviewer of the day introduces the topic and helps the candidate understand some of the internal lingo and bootstrapping questions they'll have right off the bat. The first interviewer is pretty crucial because the candidate has to be prepared to write things down and carry information across each interview.

4) all subsequent interviewers come in and ask two questions:

* What problem were you given to solve?

* I'm an expert in technology / business area X. How can I help?

By the end of the day when they're having their likely optional interviews with more senior people, they should look disheveled but pretty happy, because now they're pitching to senior management an idea they collaborated on with a wide variety of team members.

They should have a whiteboard full of stuff, stacks of paper, whatever. You should get a good idea of how they organize themselves under pressure.

The interview team should have a good feel for how the candidate leveraged them for answers. The interviewers should have done a lot of talking! There should also be clear evidence of the candidate getting better towards the end.

At the conclusion they're tasked with taking a step back to the higher level to explain the idea to management - regardless as to whether management is technical or not, they should be expected to walk away understanding the big picture. Having non-technical "business" people contribute to the interview is critical, since they help the candidate understand some of the human requirements.

I could go on and on, I'm pretty excited about how this technique has worked so far. The key element is deliberately having the candidate carry knowledge between interview teams. I'm sure I'm not the first person to think of this :)

EDIT: styling

Re: My favourite interview question (2006)

#57

Post by acheron »

napoleond wrote: post #27
rogy wrote: post #23

Earlier quoted context omitted.

i HATE this question but its becoming more and more commonplace. I work hard, programming 40-70 hours a week, I solve all sorts of in work problems with ideas that I've come up with to make my daily work life easier. I barely touch a computer outside of the office. Does that make me a bad candidate for all programming jobs now?

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".

Re: My favourite interview question (2006)

#58

Post by [deleted] »

whyaduck wrote: post #17
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 a good week I work 50 hours. In a bad week, 80 or 90 (or more). In my spare time I have family commitments, play guitar, draw, paint, hike, ride my mountain bike, and travel. Ask me that question and I'll probably find a way to wind up politely and leave.

[deleted]

Re: My favourite interview question (2006)

#59

Post by Symmetry »

danso wrote: post #3

Probably should have checked before posting...this was discussed 4 years ago: https://news.ycombinator.com/item?id=2062889 (so I guess it's eligible for re-discussion) I stumbled across it doing a Google search for "interview question elevator design"...I haven't been asked in a technical interview about how I would implement the logic for an elevator controller, but I heard about the question second-hand at a colleg…

Oh, God, elevators. One of the hats I wear is "Facility Integration Technical Lead" and integrating our robot with the various elevator systems of buildings is one of the most painful things about deployment.

Re: My favourite interview question (2006)

#60

Post by Xyik »

Love how every time a post concerning interviews pops-up on hackernews everyone gets defensive. Like all things I think the nature of the interview should reflect the role the developer will have when hired. If the developer won't be in charge of developing an entirely new system or project on his own it seems overarching to ask this type of question. At the end of the day the core attributes that matter are intelligence, ability to learn, experience and motivation. In this case, this question really only tests experience.
Post reply on HN