Hacker News Reader

Comment by macca321 | Hacker News Reader

The problem with interviews is that there is no time for false starts. When approaching a coding problem in real life, I pick a solution that seems to be right.

Half the time I pick a good solution and half the time I've rushed in and picked the wrong one.

If I have picked the wrong one, I know within 30 mins that it is a flawed approach, but have usually explored the problem sufficiently to pick a good solution. The interview unfortunately ends after 30 mins.

I should also add that I'm not much better at this after 13 years of professional development than I was when I left uni, when it comes to manipulating linked lists and arrays. My systems design is a lot better though.

View on HN

But if you can't do the calendar question and realize within (lets be generous) 3 minutes that double nested loops are the wrong approach... I think it'd be fair to question your abilities.

Having had the chance to do some interviewing over the last few years I think the most important thing on my side is to know what I'm trying to test for with any particular line of questioning. I don't always see that level of self-awareness in fellow interviewers. (The worst is the sort who say "if they don't do X when I'm asking for Y, I'm going to score them down." Do they really care about Y then?) What exactly is gained by letting the candidate go off into the deep end for several minutes before they realize on their own, if they ever realize at all, that their initial approach was bad when it should be a simple question? If the purpose of a calendar question or fizzbuzz question (or my own initial coding question, "implement is_even") is to answer "can you code?" why does it matter if the solution isn't that great? If you have an answer to the question you can follow up with things like "can you code a better solution?" to distinguish passes, but interviewers should keep everything time boxed, there's other stuff to cover with such short time slots as 30-60 minutes. I like to test some sort of presence for knowledge about regexes and recognizing an application, so I borrowed Yegge's phone number regex question from his phone screen tips, and I'm happy enough if the person realizes that "there's some sort of pattern thing to do this" because that's a google away, happier if they can write a script that uses regexes correctly, happiest if they know or get close to the grep incantation, but if they start trying to write their own parser I'm going to stop them because that's going to take a lot longer than 10 minutes, especially if I say "oh yeah there's another number format we need to extract". But that person still might be a good hire, just not knowing about regexes at all. By keeping things time boxed I can make sure all the other areas I care about are covered and can judge if certain strengths can compensate for certain weaknesses.

Yeah, instead it's like: "Here's an interesting question that I like because I feel I already understand it well. Let's see what they do with it, and then I'll go with whatever gut feeling I end up with. This is easy, I'm a good interviewer."

Here's a tip: most live programming interview questions should be answerable within a few minutes. Any approach that you think will take a half hour is the wrong approach.

"Any approach that you think will take a half hour is the wrong approach."

Unless the interviewers haven't given much thought themselves. "Hey Joe, we have to interview a guy in 20 min. and I can't remember where are those damn interview questions. Gather up a few for me, will ya?"

Reply on news.ycombinator.com