Iyfjky

Question

I was rejected in a recent interview. That was the final stage and there were only two candidates remaining. Apparently we were on par on pretty much everything except he was better at problem solving during the technical interview stage, so they gave him the offer.

The problems were rather simple, but presented in very unconventional ways. As a recent graduate, my only experience has only been with textbook problems. It took me awhile before I could solve them and that was with several hints from the interviewers.

I wonder if there is an optimum approach to solving problems, especially for problems you are unfamiliar with.

Coding interview question: how to be comfortable enough doing a certain task that naturally wouldn't happen very often? Wait, are we talking about coding? — Jun 4 '14 at 15:55
possible duplicate of Coding interview question: how to be comfortable enough doing a certain task that naturally wouldn't happen very often? — Jun 19 '14 at 13:28

jmort253â™¦ 10.4k54376 · Accepted Answer · 2014-06-21 20:03:06Z

My problem solving approach boils down to this checklist, which I go through in sequence from top to bottom. This checklist pretty much summarizes the engineering problem solving approach - dispassionate, disciplined, systematic, relentless:

"What's the question?" In my case, I can trace 80% of the instances where I mis-answered to my getting the question wrong and not realizing that I had gotten the question wrong. FYI, in the other 20% of instances, I simply did not get the question.

"What information do I have to work with"?

"What information do I need to answer the question and that I don't have?"

"If I don't have the info I need, what assumptions can I safely make?"

"How do I go about checking my assumptions and verifying the integrity of the facts that I am working with?"

Of course, if I don't quite get the question and how it is supposed to be answered, I keep asking for clarifications until I get a road map. Sometimes, I impress people more with the questions I ask than the answers I give :)

And yeah, get a good night's sleep and come in with the attitude that no matter what happens, you will figure out a way to solve anything that's thrown at you. If you are utterly confident, your first reflex will be to try to figure it out. If you lack confidence in yourself, you're liable to collapse mentally into yourself the minute you are confronted with something you didn't expect.

Every military collapse started with a mental collapse that cascaded into an intellectual collapse and that culminated into a physical collapse. You can be defeated through no fault of your own but a collapse is something you do to yourself.

Beo 41025 · Answer 2 · 2014-06-04 13:25:33Z

Practice and preparedness.

In programming fields at least you can search the web for job interview questions / problems people have encountered and be a bit more prepared when you go in. Some companies give you homework assignments even.

Also think about what the company you are interviewing for does. Should you brush up on database solutions. Web technologies? Maybe they look for fast algorithms or general math skills?

In your off-time you can also practice thinking about and solving different hypothetical problems. Maybe there is a professional society or something on the web you can join to ask specific questions have your solutions reviewed?

Interviewing is also a skill. You get better at it the more you interview. Some people recommend interviewing for jobs you are not even interested in just to improve interview skills.

Every time I begin a new job hunt, I find I need 2 or 3 practice rounds before I get comfortable solving problems on a whiteboard while being stared at again. The 'traditional' tech interview is asinine, but you just have to realize it's a game and you have no choice but to play along if you want to work. — Jun 4 '14 at 14:01

score 4 · Answer 3 · 2014-06-19 12:05:14Z

The best way to respond to problem-solving questions in interviews (and anywhere else for that matter) is to know what you're doing. There is no technique to fake your way thru something like this. That is of course why these questions are asked. You failed not because you didn't have some magic technique or the other guy gamed the system, but because he was better than you. If you can't solve problems efficiently in a interview, you're also not going to solve problems efficiently when confronted with them on the job. It seems they rejected you for the right reasons.

You are therefore asking the wrong question. Your issue is not with problem solving during technical interviews, but just with problem solving. This is not the place to discuss problem solving methods, so I'll only be brief. Basically, problem solving comes down to understanding the subject matter and logical thinking. You can sit down and learn more of the former, but I'm not sure how well you can learn to do the latter. The biggest mistake people seem to make when confronted with a problem statement is to assume facts not presented, and then just flail around guessing at possible solutions instead of thinking carefully about what they know, what needs to get done, and how to proceed towards that goal. If the problem is diagnosing a failure, then you design a set of experiments that break the system down into two or more parts and tell you which parts the fault is not in.

Added in response to comments

Someone objected that problem solving in a interview is different from problem solving in the real world. That is the wrong way to look at it, and I reject that notion. Real problems during the real job don't come at convient times either. You often have the boss, sales, upper management, and/or customers breathing down your neck. Answers are rarely out there where you can google them. Stuff happens, sometimes right after you've come back from a week overseas and are jet-lagged.

Also, if you're stressed out in a interview, that's totally your fault. Stress can only ultimately come from you internally. At best the external world can create demands, not stress. The kind of person you want to hire won't get stressed out, they'll take it as a challenge instead. You don't want to hire the person that can only function when everything is just right. Deliberately creating a bunch of demands during the interview is one way of weeding out people like that.

I have interviewed enough engineers to have seen a clear difference to how people react to deliberately contrived tough problems. The good ones actually enjoy the challenge and dig in. These people know their stuff and know they know their stuff, so they don't get stressed out. Again, stress comes from inside. It's those that don't know their stuff and have low confidence that get stressed out and then usually screw up as a result.

Some people may know their stuff, but just react badly to being put on the spot. However, do you really want to hire someone like that? Perhaps in a sufficiently large organization you can create a peaceful niche for someone like that and thereby utilize them effectively. However, in a small company that kind of person wouldn't be able to function when the inevitable stuff happens.

That all said, one thing you should NOT do as a interviewer is to make the candidate feel stupid and unrespected. That's because in the real job you wouldn't do that either. If you really felt that way about someone, you'd ditch them. People that work for you have to feel that they have your support and respect, and they will perform better because of it. So be positive and supportive in the interview when you're giving them a hard problem. As I said before, the good ones will dig in and actually enjoy the challenge. The losers will get flustered and hang themselves without you having to help it along. I've done this a bunch of times and can tell you from experience the difference is quite clear.

Usually a candidate gets stressed in a interview not due to a hard problem, but because they realize they are getting caught having over-represented themselves. The hard problem is only the vehicle which exposes the fraud.

Someone also objected to contrived questions in a interview as being a good test of a candidate's knowledge, and that such knowledge can only be assessed after much longer term observation on the job. There is some truth to this, but it completely misses the point. What are you supposed to do, hire ever candidate for a month then blow off the ones that don't perform? Like it or not, a interview is a 30-45 minute window where you get to asses a candidate. And yes, you can get a good feel for someone's technical abilities in that time. Asking a few contrived problems is just one of the things you do during that time.

I interview mostly electrical engineers and have also interviewed for electrical engineering positions. As a candidate, I enjoy the interviews best, and walk away with a more positive impression of the company, when at least one interviewer gives me a technical grilling. I know my stuff, so to me such questions are fun. However, more importantly, such questions give me a chance to demonstrate that I know my stuff. It gives me a good feeling I'll be working with other people that know their stuff because if they didn't, they wouldn't have made it thru the interview process. When I don't get a technical grilling, I'm always worried what kind of bozos I would be working with. Remember that interviews are two-way. I have turned down job offers when I didn't feel the interviews let me show what I can do relative to the average zombie interviewing for the same position.

Hey Olin, I appreciate the tone of your answer, how you're able to remain objective yet not be insulting to those who might not have the skills to pass the interview. There's no smugness in your answer, and I can see that as being tough when explaining things like this. So great answer! With that said, I cleaned up some of the comments, and we may likely remove the rest, so if there's anything else you'd like to incorporate into your answer from here, please take one last look. — Jun 19 '14 at 3:42
@Jmort: OK, I updated the answer to respond to all the points raised in the comments. — Jun 19 '14 at 12:06
+1: My 30 minute code test (for senior develores) is fairly complicated for 30 minutes. It's worded similarly to what you might find in business requirements, but in the end when you boil it away it's simply a swap function with a shift component. I use it to see how a candidate translates a requirement into code, how they solve the problem, how they remove the "fluff" of the question. Most candidates I approve for hire don't produce actual usable code, but they see through the problem and show a positive attitude about solving it. — Jun 19 '14 at 12:18
This answer has some cogent points, though I would argue that equating the kind of pressure experienced in interviews (direct observation/judgment) and the kind of pressure experienced in an emergency (mostly time pressure) are a bit differentÃ¢Â€Â”and processed significantly different by the brain. Considering them to be the same would be a false equivalence fallacy. Another analogy might be someone who can't urinate while someone is watching, but can go fine when in a big hurry. To Olin's point, knowing your stuff certainly helps mitigate the "performance anxiety" more prevalent in interviews. — Sep 21 '16 at 10:09

kevin cline 15.6k43861 · Answer 4 · 2014-06-04 15:38:59Z

You can improve your problem-solving skills in two ways:

Learn the known techniques. Get a copy of something like Corman's Introduction to Algorithms and work through it, or take online courses in algorithms. This will take some time, but will put you ahead of your competition.

Practice. Go to websites like Project Euler and work through some of the problems. When you have solved a few dozen you will be well ahead of most programmers.

jmort253â™¦ 10.4k54376 · Accepted Answer · 2014-06-21 20:03:06Z