Live data from Hacker News

My favourite interview question (2006)

weblog.raganwald.com

41–50 of 100 posts

Re: My favourite interview question (2006)

#41
post #23

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 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?

I think the first problem is that you're working more than 40 hours a week already... I'd ask how much of that is coding vs. meetings vs. other time.

I'm in the office 40-45 hours a week typically, I spend 20-30% of my time just thinking about the problems I am solving, or stuff like this, or following github projects, or other technology reading. I probably do about 4-5 hours of actual programming a day at work. My output during that time tends to match or exceed most of my peers in both quality and quantity.

The problem is getting people to understand more hours isn't the same as more productive output. Spending a couple hours thinking through a problem (or even prototyping) will usually save you more time down the road. This is true from simple data modeling to working through how to fit a system together.

As to the original question.. it is far from the only indicator of a person's own skill and drive, but it is an indicator. Especially in more junior level candidates. There's also the fact that the technology in use changes rapidly... and do you take the time to learn it... either out of your in-office day, or outside.

Re: My favourite interview question (2006)

#42
post #2

Am I the only one who thinks that this kind of design question is the new "how many gas stations are there in Manhattan?" In both cases, the point isn't to get the right answer, but (allegedly) to see how the person thinks. With the estimation question, the trick is to make up some plausible-ish numbers and then multiply and/or add them to get a plausible-ish result. If someone's seen one of those before, they'll nai…

The paradox is that the best programmers tend to be the worst at interviewing (because they usually get hired quickly) and the worst programmers gradually get better at interviewing (after doing lots of them).

Re: My favourite interview question (2006)

#43
I just spent a few months interviewing developers in all career stages. I ask a problem in a similar vein that's designed to get both of us up in front of the whiteboard working out the design of a problem together. In those 20+ interviews I've seen all kinds of answers to the problem, some bad, some ok, and some pretty good. I can learn a ton about you as a developer with this question. And almost without fail the candidate ends the interview with something along the lines of "that was a fun problem to work on".

I combine that problem with developng a simple end to end feature together and the combination of that with a high level design problem turns out to be a really good indicator of how someone actually performs on the job.

Re: My favourite interview question (2006)

#44

I once got a similar question, but with Battleship. I don't really enjoy these high-level design things, they seem silly and irrelevant to me, but I can see how someone with different interests would like it. (That particular place made me an offer, I'm not doing sour grapes.)

If you practice ALL of these questions for at least TWO passes: https://oj.leetcode.com/problems/ , you can get a software engineer role in at least one of the famous tech companies, e.g., facebook, linkedin, google, amazon, microsoft, ...

Nowadays, very very few companies innovate in recruiting.

I've interviewed with most "hot" companies, and I can find most interview questions (>90%) from https://oj.leetcode.com/problems/, exact same question.

Re: My favourite interview question (2006)

#45

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.

That's fine, but if you work that much are you interviewing at places as well?

I couldn't imagine working that often and not enjoying it.

Re: My favourite interview question (2006)

#46

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.

I'm sure there are many here who would agree with you, but let me offer an alternative viewpoint. You said:

  > Ask me that question and I'll probably
  > find a way to wind up politely and leave.
The implication is that rather than opening a dialog with someone to (a) find out why they think that question is relevant, and (b) offer reasons why you'd be a good fit despite not working with code outside your job, you'd simply leave?

For me, as a potential employer, that would be a good reason not to want to hire you. It makes you sound like you would not be an easy person to work with. It sounds like if someone came to you with an unreasonable software requirement you would simply shut them down without trying to find a way to deliver something that finds a good balance between what they've asked for, and what can be done.

But perhaps that's not the impression you intended. If not, could you expand further?

Re: My favourite interview question (2006)

#47
I would much rather hear about their past projects and have them clearly convey design decisions that they made before then have them work on a "on the fly" question. Everybody has off days, not many people have whole off years or careers. Just because I can't design Monopoly in one hour on a certain given day doesn't mean I do not have the relevant experience in my past, whether it be professional or as an undergrad.

Re: My favourite interview question (2006)

#48
post #35

Earlier quoted context omitted.

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.

I love this question and use it as part of my interview deck. It is only part of the deck, however. This question is a great positive indicator, but a terrible negative indicator. That is to say, a person who works on a lot of stuff in their spare time is very likely to be someone I'd like to hire. The reverse isn't true, which is why there are other questions in the deck. I realize that there are great developers wh…

What if you have side projects that make money, i.e. are "work"? Is that discounted by "non-work, non-school" or by non-work do you mean "not your day job"?

Re: My favourite interview question (2006)

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

> 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 projects as a proxy for asking "are you passionate about programming" and then to expect the candidate to guess your true intentions and answer accordingly.

Re: My favourite interview question (2006)

#50

I would much rather hear about their past projects and have them clearly convey design decisions that they made before then have them work on a "on the fly" question. Everybody has off days, not many people have whole off years or careers. Just because I can't design Monopoly in one hour on a certain given day doesn't mean I do not have the relevant experience in my past, whether it be professional or as an undergrad…

It's not as though this is the only question by which the interviewee will be appraised. This is one more tool in the kit alongside asking about previous projects, interesting classes, career goals, overcoming tough situations, etc.

Whether or not questions like these are effective, the point of them is to engage with someone in a way that illustrates how they tackle complex, loosely defined issues: the majority of engineering problems in a nutshell. In most modern tech companies, good communication and not being afraid to ask questions are absolutely essential. Someone who will take an incomplete list of requirements and draw up an entirely incomplete product without questions or discussion is as much a liability as someone who takes the requirements and does nothing, paralyzed by indecision and not knowing what to do. And oftentimes, candidates aren't perfect but you're going to hire them anyway. Going through this process can illustrate how you would expect to interact with the candidate and where the initial rough spots will be as the candidate begins working with the team.

From another point of view, candidates are usually more than prepared to talk about anything on their resume. In some cases, this is equivalent to listening to someone give a prepared speech. Asking them free-form questions like the above can be a good way to understand how the candidate reacts in situations where they aren't fully prepared. For some positions this is irrelevant, but for others it's incredibly important to have some measure of poise and thoughtfulness when engaging with someone who doesn't necessarily agree with everything you say and is questioning your thought process.

In short, these kinds of questions aren't primarily testing your design and programming abilities, but your ability to communicate and reason with another person in a technical context.

Post reply on HN