4 ms·

This has been my strategy for a while, and it's always worked for me. I never study for interviews, and I can usually find jobs. In my experience, technical q

This has been my strategy for a while, and it's always worked for me. I never study for interviews, and I can usually find jobs. In my experience, technical questions typically fall into two categories. The first is trivia about a programming language or other tool. The only people who need to "cram" for these are people who lied on their resume. Everybody else will answer these questions pretty easily just from working with the tools and having hands on experience. These are weed out questions to keep people honest. The second category is to see how the candidate thinks about problems and solving them. It's not helpful to "cram" for these because the problem space is too large, and it would defeat the point anyway. If a company wanted people who've memorized "Coding Interviews For Dummies," they would just put that in the job requirements. In reality, the job they're hiring for doesn't have cookie cutter problems and solutions, and they want to see how the interviewee will work through a problem to find a solution. Knowing the answer to these in advance can actually hurt because it doesn't show them what they're looking for.

privacybuff 13y ago
"I see it says here you're an [particular platform] programmer? Ok, have you ever worked with [particular SDK]? Oh, you have, ok what are the parameters to [arbitrary method in said SDK with over 6 parameters]" This is an actual question I got. I don't consider it weeding out people to keep them honest. I had worked with that SDK, I might have even used that particular API (though it was not a common one in the area I was working with that SDK). Here's the error I think. These problems do not ask the candidate to demonstrate their problem solving capability. They ask the candidate for a solution, and they are often presented in such a way as to imply that's all the interviewer wants to hear: He expects you to just rattle off a solution. I don't think "seeing how the candidate thinks about problems" is very useful. Either someone can reason about the problem, or they can't. When you ask them a trick question like this ("find loops in a linked list" was one I used back before I learned how to interview people) they either can solve it fairly easily or they can't. If they are constantly stuck, you have no information about their programming ability. I think that's the error. People think that "getting stuck" means they are poor at problem solving. (and rarely, possibly never, has an interviewer asked me questions relevant to understanding how I solve problems.) The pressure of an interview session, combined with the fact that most interviewers are not really all that competent at problem solving in the first place (about %50 of the time they ask the problem wrong and then have to change it while I'm solving what they actually asked, or what they asked is nonsensical) means that you get a lot of false negatives. I'm self employed now so I write software all day long. I am constantly solving my own problems. I've been doing this for decades. Still you put me in an interview and ask me to sort a linked list, and I'll be spending %50 of my energy trying to get over the fact that the interviewer seems to expect me to just blurt out an answer. (even though I know they want to see me solve the problem).

privacybuff 13y ago

"I see it says here you're an [particular platform] programmer? Ok, have you ever worked with [particular SDK]? Oh, you have, ok what are the parameters to [arbitrary method in said SDK with over 6 parameters]" This is an actual question I got. I don't consider it weeding out people to keep them honest. I had worked with that SDK, I might have even used that particular API (though it was not a common one in the area I was working with that SDK). Here's the error I think. These problems do not ask the candidate to demonstrate their problem solving capability. They ask the candidate for a solution, and they are often presented in such a way as to imply that's all the interviewer wants to hear: He expects you to just rattle off a solution. I don't think "seeing how the candidate thinks about problems" is very useful. Either someone can reason about the problem, or they can't. When you ask them a trick question like this ("find loops in a linked list" was one I used back before I learned how to interview people) they either can solve it fairly easily or they can't. If they are constantly stuck, you have no information about their programming ability. I think that's the error. People think that "getting stuck" means they are poor at problem solving. (and rarely, possibly never, has an interviewer asked me questions relevant to understanding how I solve problems.) The pressure of an interview session, combined with the fact that most interviewers are not really all that competent at problem solving in the first place (about %50 of the time they ask the problem wrong and then have to change it while I'm solving what they actually asked, or what they asked is nonsensical) means that you get a lot of false negatives. I'm self employed now so I write software all day long. I am constantly solving my own problems. I've been doing this for decades. Still you put me in an interview and ask me to sort a linked list, and I'll be spending %50 of my energy trying to get over the fact that the interviewer seems to expect me to just blurt out an answer. (even though I know they want to see me solve the problem).