3 ms·

I'm not a pro at hiring, but I have a very different approach based on what ultimately ends up being useful in an employee over the longer term for us. If you'

by rapind 12y ago

I'm not a pro at hiring, but I have a very different approach based on what ultimately ends up being useful in an employee over the longer term for us. If you're building a garbage collector, or a high performance graph database, then by all means, ask your candidates to whiteboard algorithms for you. Fizz buzz the crap out of them. In fact hiring for that type of position must be ridiculously hard and I'm not qualified to address it. If however you're building CRUD apps in Rails or SPAs in React, you may want to take a different approach. One that prefers maturity, discipline, and self-motivation over pure intelligence or proficiency with Haskell. This comes from personal experience hiring very smart people who lack some of these other values. It's never worked out well in the long haul. I also think that there are a lot of really smart people who will just suck at those algo type interview questions because it can be a bit nerveracking and as you can already see from some replies to this thread, it can be taken as offensive (even if you don't think it is). Making your candidate (more) nervous and / or defensive and you're limiting your ability to find out about their other virtues.

thomaskcr 12y ago
I agree but usually the type of questions I asked are geared towards what I'm interviewing for. Whiteboard problems are just jumping off points, from there the problem can go so many directions based off of that person, their experience, what's important to them, etc. For a CRUD full stack app, you're right I really don't care about your ability to write a search function since SQL will do that for you just fine - in fact, for the most part algorithms are probably not even part of the interview. I may ask them to still start solving a really simple problem -- it may or may not make it all the way to code. If someone starts writing/mapping out their database first that tells me something, I can ask why they are breaking their objects where they are, etc. I like to ask "what's important" in the context of components - I use the example of a bunch of HTML documents to frame the context. If I'm looking at 10 similar HTML documents, what can I do to find important information? (Strip out things that are the same). So if I'm doing 10 interviews, what do you think is going to be the same (user/session management if there are accounts would be an example) and what do you think will allow you to differentiate yourself? For some people, they'll think about what they're strong in and how it applies to the problem, for others they'll focus on the problem space. At this point you've spent 15-25 minutes talking if they're a good candidate and written no code by starting with the "write code" question -- I think you could get a great 60m interview without writing any code even though you started with a "write code" problem. My opinion on interview questions is they're just conversation starters -- if you just go down a list of questions I just don't think its a successful interview. I really like VERY open ended questions where the candidate can have a chance to tell me why they're great. I really try to only have 3 or 4 questions for the interview and hope to only get to 1 or 2.
- rapind 12y ago
  This is sensible. I tend to do a similar approach based on going over some code they have written and their decisions with them.

by rapind 12y ago

thomaskcr 12y ago

I agree but usually the type of questions I asked are geared towards what I'm interviewing for. Whiteboard problems are just jumping off points, from there the problem can go so many directions based off of that person, their experience, what's important to them, etc. For a CRUD full stack app, you're right I really don't care about your ability to write a search function since SQL will do that for you just fine - in fact, for the most part algorithms are probably not even part of the interview. I may ask them to still start solving a really simple problem -- it may or may not make it all the way to code. If someone starts writing/mapping out their database first that tells me something, I can ask why they are breaking their objects where they are, etc. I like to ask "what's important" in the context of components - I use the example of a bunch of HTML documents to frame the context. If I'm looking at 10 similar HTML documents, what can I do to find important information? (Strip out things that are the same). So if I'm doing 10 interviews, what do you think is going to be the same (user/session management if there are accounts would be an example) and what do you think will allow you to differentiate yourself? For some people, they'll think about what they're strong in and how it applies to the problem, for others they'll focus on the problem space. At this point you've spent 15-25 minutes talking if they're a good candidate and written no code by starting with the "write code" question -- I think you could get a great 60m interview without writing any code even though you started with a "write code" problem. My opinion on interview questions is they're just conversation starters -- if you just go down a list of questions I just don't think its a successful interview. I really like VERY open ended questions where the candidate can have a chance to tell me why they're great. I really try to only have 3 or 4 questions for the interview and hope to only get to 1 or 2.

rapind 12y ago
This is sensible. I tend to do a similar approach based on going over some code they have written and their decisions with them.