Clarifying Questions
Ask clarifying questions to make sure you understand the scope of the problem so that you'll be solving the right problem. The interviewer may be testing you to see if you know how to gather requirements and communicate.Don't rush into coding and risk solving the wrong problem or missing the interviewer's point. This is your chance to shine, to show the interviewer that you can communicate well and get to the heart of problems.
Identify Pattern
Identify patterns: does this problem look like a search, dynamic programming, graph, or sorting problem? Don't have to tell your interviewer. This step is for yourself.Examples and Test Cases
Come up with examples and test cases. This will make the problem concrete and provide test cases with which you will test your solution later on.Brainstorm Approaches
Come up with 2-3 approaches and briefly run them by the interviewer but don't write up any code yet. If you need some time to come up with the optimal solution, you can start by outlining what a brute force solution would look like.Running time and space (Big-Oh for interviews)
Do basic running time and space complexity estimates for your approaches.Code
Code quickly, systematically, and cleanly.Test
Test & debugDon't forget to double check your work and walk through the solution using one of the test cases you came up with.
This is part 1 of a two part series. Skip over to part 2 you'd like . For coding interviews, we are interested in gauging the asymptotic efficiency of algorithms both in terms of running time and space. The formal study of analysis of algorithms is called complexity theory, a rich field with fascinating and complicated math. For interviews, we only need a few basic concepts. Asymptotic efficiency is concerned with how the running time or memory requirements of an algorithm grows with the input size, so it is intimately concerned with how well algorithms scale to larger inputs. This is important in Computer Science and in practice because whereas some algorithms work well enough for small inputs of say < 10 inputs, the running time and space grows far faster than the input size and thus large inputs of say 10s to millions of inputs becomes impractical (usually meaning taking hours or even years of execution time). Consider sorting. Say for the sake of argument that sorting
Comments
Post a Comment