Skip to main content

Problem Solving Checklist

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. Running time and space (Big-Oh for interviews)

    Do basic running time and space complexity estimates for your approaches.

  6. Code

    Code quickly, systematically, and cleanly.

  7. Test

    Test & debug

    Don't forget to double check your work and walk through the solution using one of the test cases you came up with.

Labels:

Comments

Post a Comment

Popular posts from this blog

Top 5 Books for Language-Specific Interview Questions

Shrunk and White of Programming When you put down that you know a certain programming language or languages on your resume, you are setting certain expectations for the interviewer. I would strongly caution against putting down "expert" in a language unless you invented or are one of the language's maintainers. You are giving your interviewer the license to quiz you on programming language lore. There are a handful of concepts that are considered "standard" knowledge for each language which go broadly beyond syntax and general semantics. These concepts commonly involve major pitfalls in a given language and the idiomatic technique for negotiating these pitfalls and writing efficient and maintainable code. Note, although the concepts are considered idiomatic, you can seldom infer them from knowledge of syntax and semantics alone. The tricky part here is that most courses that teach a particular programming language do not cover these idiomatic techniques and e...
Post a Comment
Read more

Complexity Analysis for Interviews, Part 1

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 ...
Post a Comment
Read more

Programming Language Governance (1)

As software eats the world, the programming languages used to build the software themselves grow and evolve. When new programming languages start out, they are often the product of an individual or a small group of people, though there are several famous examples of top-down programming language design where the PL is designed by committee from the outset (e.g., ALGOL . However, when a PL gets to a certain level of adoption, the inventors sometimes submit the PL to one of the standardization bodies: ISO C++, ANSI C, ANSI FORTRAN, ECMA/ISO C#, and ECMA ECMAScript. Others continue to retain their independent governance bodies (e.g., Python, Java). In either case, the governing bodies specify a process for evolving PLs: Java: Java Specification Requests C++: C++ papers Python: Python Enhancement Proposals Rust: RFCs C#: Language Proposals ECMAScript: ECMAScript Proposals Each of these governance bodies is like a small government. Many have voting ...
Post a Comment
Read more