A few suggestions for how to answer a problem solving- or coding-type interview question:
- Talk as you work through the probem. The interviewer is trying to determine how you go about tackling a difficult problem and the more you communicate, the easier this is and the better it reflects on you. You're going to have to be able to discuss what you're doing with coworkers and this is one good way to show the intervewer that you have those skills.
- Ask lots of questions. Make sure you fully understand the constraints on the problem and what they want. Do this before you start designing and coding. Again, you'll likely get ill-defined problems once you start working and you should show the interviewer that you can ferret out the true work from a poor specification.
- Don't be afraid to make mistakes. Most people don't get the right answer the first time and have to iterate through the problem to figure it out. It's never bad to sketch out a quick brute-force solution first-thing as it usually helps to have a working base from which to derive your eventual solution. It is important, however, that you can explain the strengths and weaknesses of any solution you come up with, especially the time it will take to run. It's also important to keep refining your solution to an even better answer.
- Use appropriate languages and techniques for the question being asked. If you're asked a low-level programming or data structures question then don't start spewing out a bunch of STL-based C++ code; chances are the interviewer is interested in knowing that you actually know how a linked list works "under the covers". Of course, if they're probing your knowledge of STL then an STL-based answer would be appropriate. Ask the interviewer if you have any doubt.
- Always check your work. Walk though your algorithm with some sample input to make sure that you have everything correct. Check every edge case. Make sure that you're verifying that the inputs are correct. This is where you show the interviewer that you have good attention to detail.
- Never give up. Never admit that you're stumped. Simplify the problem if need be, come up with a design then add any complexities back in. If they ask something you don't know then admit it and ask questions to try to figure it out. Deriving the answer from clues is often more impressive than simply knowing the answer up-front.
Your goal for the interview is to show the interviewer that you have the abilities they're likely to need. Such skill tests can be vital in selling yourself to them; figure out what they're likely to want and use the test to show them what you can do.
Slashdot Mirror
A few suggestions for how to answer a problem solving- or coding-type interview question:
- Talk as you work through the probem. The interviewer is trying to determine how you go about tackling a difficult problem and the more you communicate, the easier this is and the better it reflects on you. You're going to have to be able to discuss what you're doing with coworkers and this is one good way to show the intervewer that you have those skills.
- Ask lots of questions. Make sure you fully understand the constraints on the problem and what they want. Do this before you start designing and coding. Again, you'll likely get ill-defined problems once you start working and you should show the interviewer that you can ferret out the true work from a poor specification.
- Don't be afraid to make mistakes. Most people don't get the right answer the first time and have to iterate through the problem to figure it out. It's never bad to sketch out a quick brute-force solution first-thing as it usually helps to have a working base from which to derive your eventual solution. It is important, however, that you can explain the strengths and weaknesses of any solution you come up with, especially the time it will take to run. It's also important to keep refining your solution to an even better answer.
- Use appropriate languages and techniques for the question being asked. If you're asked a low-level programming or data structures question then don't start spewing out a bunch of STL-based C++ code; chances are the interviewer is interested in knowing that you actually know how a linked list works "under the covers". Of course, if they're probing your knowledge of STL then an STL-based answer would be appropriate. Ask the interviewer if you have any doubt.
- Always check your work. Walk though your algorithm with some sample input to make sure that you have everything correct. Check every edge case. Make sure that you're verifying that the inputs are correct. This is where you show the interviewer that you have good attention to detail.
- Never give up. Never admit that you're stumped. Simplify the problem if need be, come up with a design then add any complexities back in. If they ask something you don't know then admit it and ask questions to try to figure it out. Deriving the answer from clues is often more impressive than simply knowing the answer up-front.
Your goal for the interview is to show the interviewer that you have the abilities they're likely to need. Such skill tests can be vital in selling yourself to them; figure out what they're likely to want and use the test to show them what you can do.