Hacker News new | past | comments | ask | show | jobs | submit login

Saying they "can't tell you anything" is one-bit thinking. Yes, there is a lot that interviews don't tell you, but they are still a useful signal.



Yeah that's fair. Im just frustrated with how low-bandwidth those things are. I definitely get a bit of a sense of how a person thinks by watching them do those CS 201-style problems, which isn't nothing.


If the CS 201-style problems annoy you, then... stop doing them?

I don't ask algorithm questions, and I wouldn't even dream of asking brain teasers. I ask questions like "Here's a pile of text that claims to be CSV, let's explore how you'd generate an HTML report out of it", and branch out from there depending on how the interview goes. I've got all sorts of directions I can go from there, from screwing up the input in various real-world ways, discussing HTML security and injection attacks, algorithmic complexity of the report, how to build a service out of this, how we're going to handle reporting errors, there's just an endless number of ways you can take the interview from there.

CS 201 doesn't usually come up.


This specific question is new to me but I like it a lot. I have found that the most useful interview questions are technical but more conversational than a white board, more about how to approach and solve a realistic problem. I think your method is a good high-signal approach.


A little late but I wanna be clear that I don't ask them! I ask questions similar to you. My comments here largely come from my experience doing the interview problems. But yeah, i've tried to "be the change," so to speak.


I find them useful if you use a real world problem from your product, and the whiteboard is just a tool to help you collaborate as they brainstorm and discuss possible solutions with you. That reduces the pressure and you also get a read on their collaboration skills.

The ideal would be pair programming for an afternoon.


When I interview candidates for the company I work for I describe a key part of our system in general terms (20 possible elements, at least one active but any combination, items are single/set/hierarchy) then ask them to talk me through issues they can see writing generic code to handle data management and computations given these conditions. They don't have to write code, but they do have to be able to think logically and express themselves clearly. Some describe pretty much what we do, some get creative, and some are completely at a loss. Some pseudocode to help describe what they're thinking, most don't.

Even if their "solution" is incomplete I look at if they get the gist right.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: