4 ms·

Interview questions you don't like/fail shouldn't be viewed as reflective of you, but reflective of your fit at that company. They asked a puzzle-y question yo

Interview questions you don't like/fail shouldn't be viewed as reflective of you, but reflective of your fit at that company. They asked a puzzle-y question you couldn't solve? Either their problems are puzzle-y, or they have terrible criteria for evaluating people; either way, do you really want to work there? They asked a hard algorithmic problem, the kind that was someone's PhD thesis 30 years ago, and which you'd only get the optimal result to if you'd seen it before? Either they really do expect you to know stuff like that off the top of your head, or they expect you to behave a certain way when confronted with stuff you don't know; either way, do you really want to work in an environment with those kinds of expectations? They asked you to code something hard withing a short time limit, and while you can code it, you failed the time limit; do you really want to work somewhere where speed is -the- criteria to optimize, rather than quality/maintainability/whatever (or at least where they're selecting for that rather than those other attributes)? Etc. In general, as others have said, if you program, you're a programmer. What specific roles you're a fit for is largely orthogonal to that. If you don't pass a company's test, view it as having dodged a bullet, not having 'failed'; either they expect you to have something from day one that you don't have, or they are terrible at testing for what they really want, and so their culture, codebase, etc, is likely miserable. In neither case do you want to work for them. You want to work for a place whose expectations for what you have on day one fits what you actually have (whatever they may be), -and- whose interview process tests for that (even if it's a little flaky), so both you and they can expect, going into the job, that you can handle it. Remember, too, that there are false positives and false negatives even when they're testing specifically for what they want. Failure to figure out a puzzle doesn't even mean the person isn't good at figuring out puzzles; just that in this case, in this contrived, high stress set of circumstances (an interview), they were unable to come up with an answer in the time limit.

rdtsc 12y ago
Agreed on all points. But how would you interview a candidate? I see what not to do. Here is what I do: * Ask about their previous work. Dig into something they are excited or proud of. * Try to solve a problem together. Usually a simplified version problem I am actually solving at the moment at work. * If it is a new grad. I will ask them some simple questions about data structures, school projects. * If there is any sample code, anywhere, I like to see it and it is a big + sometimes. * See if and what kind of questions they ask. Does that work? What would you add/remove? I try not be a "dick" and take the approach of "ok, let's work on this together" approach because that is how things work here. Another approach (which I don't like as much) is to go by the "we want to hire smart people" mantra. "smart" here is is nebulous of course. So how do you do it? IQ tests. Oh but those are illegal, so just write a tests that looks like one without calling it an "IQ test". That involves puzzles usually too. So I think that is how puzzles became popular.
- lostcolony 12y ago
  Depends what you're looking for. None of the prior methods are -bad- if they're what you're looking for. I don't even object to IQ tests masquerading as not-IQ tests; it serves as a warning to me I don't want to work for you. Depending how many applicants you get, I'd start with a screener, a basic, customized problem that they get an hour to solve, that doesn't have a hard pass/fail, but is just a "Hey, let's see how they code when given a problem". If you have constraints you want to filter for, now is the time (you want speed, see above. You want production quality, give them more time than you think a basic implementation would take, and indicate you want the thing to be production quality; see what they do, what they ask, etc). If they pass that, yes, what you describe sounds fine, if it's what you're looking for in a hire. If you want to favor false positives, ask a variety of fairly trivial questions; you're trying to make sure you ask questions they may not have solved before, but which any reasonably competent dev can solve. Bonus points if the person scopes them beforehand. If you want to favor false negatives, ask harder questions, but make sure they actually are ones you deal with. If you're writing basic business CRUD apps, and your challenges are really in deployment, reliability, gathering and responding to user needs, etc, asking them to implement something from Cracking the Coding Interview is counter to your purposes. Ask them instead what it takes to build a reliable system. Are they familiar with doing that? What are some of the considerations? If they suggest distribution, are they familiar with CAP? Etc. Really, it all depends what you're looking for. If you want someone who is keen to learn about the domain you work in, ask them if they know about things they have no reason to know about, and indicating that "it's okay if you don't"; see if they admit it. See if they respond with enthusiasm when you start to explain it, "Oh, that's cool!" when confronted with a new idea is probably someone you want, "Huh, okay", maybe not. Etc. I readily admit, hiring is hard, extremely hit or miss, but a lot of companies seem confused about how it's supposed to work; don't borrow the interview practices of another company in a completely different industry. Google asks those questions? Google -can- ask those questions; they're trying to filter out people. You don't get 1000 applications for every job opening, you can't afford that. You also aren't dealing with the same problems; someone who fails those questions may still be a great hire for you.

rdtsc 12y ago

Agreed on all points. But how would you interview a candidate? I see what not to do. Here is what I do: * Ask about their previous work. Dig into something they are excited or proud of. * Try to solve a problem together. Usually a simplified version problem I am actually solving at the moment at work. * If it is a new grad. I will ask them some simple questions about data structures, school projects. * If there is any sample code, anywhere, I like to see it and it is a big + sometimes. * See if and what kind of questions they ask. Does that work? What would you add/remove? I try not be a "dick" and take the approach of "ok, let's work on this together" approach because that is how things work here. Another approach (which I don't like as much) is to go by the "we want to hire smart people" mantra. "smart" here is is nebulous of course. So how do you do it? IQ tests. Oh but those are illegal, so just write a tests that looks like one without calling it an "IQ test". That involves puzzles usually too. So I think that is how puzzles became popular.

lostcolony 12y ago
Depends what you're looking for. None of the prior methods are -bad- if they're what you're looking for. I don't even object to IQ tests masquerading as not-IQ tests; it serves as a warning to me I don't want to work for you. Depending how many applicants you get, I'd start with a screener, a basic, customized problem that they get an hour to solve, that doesn't have a hard pass/fail, but is just a "Hey, let's see how they code when given a problem". If you have constraints you want to filter for, now is the time (you want speed, see above. You want production quality, give them more time than you think a basic implementation would take, and indicate you want the thing to be production quality; see what they do, what they ask, etc). If they pass that, yes, what you describe sounds fine, if it's what you're looking for in a hire. If you want to favor false positives, ask a variety of fairly trivial questions; you're trying to make sure you ask questions they may not have solved before, but which any reasonably competent dev can solve. Bonus points if the person scopes them beforehand. If you want to favor false negatives, ask harder questions, but make sure they actually are ones you deal with. If you're writing basic business CRUD apps, and your challenges are really in deployment, reliability, gathering and responding to user needs, etc, asking them to implement something from Cracking the Coding Interview is counter to your purposes. Ask them instead what it takes to build a reliable system. Are they familiar with doing that? What are some of the considerations? If they suggest distribution, are they familiar with CAP? Etc. Really, it all depends what you're looking for. If you want someone who is keen to learn about the domain you work in, ask them if they know about things they have no reason to know about, and indicating that "it's okay if you don't"; see if they admit it. See if they respond with enthusiasm when you start to explain it, "Oh, that's cool!" when confronted with a new idea is probably someone you want, "Huh, okay", maybe not. Etc. I readily admit, hiring is hard, extremely hit or miss, but a lot of companies seem confused about how it's supposed to work; don't borrow the interview practices of another company in a completely different industry. Google asks those questions? Google -can- ask those questions; they're trying to filter out people. You don't get 1000 applications for every job opening, you can't afford that. You also aren't dealing with the same problems; someone who fails those questions may still be a great hire for you.