Skip to main content

Best practices for solving programming Interview questions

You see it's much easier than you think there exists a limit set of rules you should apply to most of the programming interview questions which involves algorithms and data structures. I have prepared a summary of them for you, just read below and get your tips for today.

When you have no clue / Under panic attack => Brute Force!

If you don't have a clue, brute force the fu**** question! In most cases the question you are presented with has a brute force solution.  Mention clearly that you are brute forcing it and say that the time complexity is O(n^2) or whatever it is.  Then think where do you waste time in your brute force solution, try to improve that part, in many cases, this will get you closer to the actual answer.

By brute forcing you get to be familiarize with the problem better.  A common theme for brute forcing means you are going to have a for loop inside a foor loop something like the below, so it's great to get familiarize with common bruteforcing snippets, example:

// Brute force find all continuous subsequences.
for (int startIndex = 0; startIndex < arr.length; startIndex++) {
  for (int Index = 0; endIndex < arr.length; endIndex++) {
    for (int i = startIndex; i++; i < endIndex) {
       System.out.println(arr[i]); time complexity O(n^3) as we have loops nest.

Add space, maybe with hashmap

No idea how to brute force? imagine you have more memory space, use an additional hashmap to help you.  Sometimes the answer even relies on that on additional space, if you could solve it this way, again, say the time and space complexity and ask if to reduce the space complexity, if yes continue with next steps.

Can you massage the input?

Sometimes if you just sort the input or apply a transformation to it, the problem is easily solved, so try to sort it at first, see if it helps.  (this might not be the final answer but it can take you a step further).

Is the problem easy for one item of input? 2 items of input? => recursion

If you can solve the problem easily with 2 item input, 1 item of input, then recursion matches, try to apply it and see if it helps.

Data structures brainstorm

Start thinking of the different data structures you know, hashmapset, .. if you could apply them to the data in the problem or use their help would it help?

Don’t try in place string changes copy to a new string

Don't overcomplex yourself with in place string replacement, at least at first, use another data structure.

Whiteboard: Describe the algorithm in exact words then just translate it to code

To make writing on whiteboard easier, first, describe the algorithm in words, then translating to whiteboard is easier.

Recursion recipe let's say for sort

Left, right = split(input) // first split can be in sort body
sort(left) // call self with left
sort(right) // call self with right
merge(left, right) // create new merge method.

Cut linked list in half recipe

Use slow and fast pointers, fast moves! then when fast get's to the end of the list this means your slow pointer is at the middle of the linked list!

Useful coding snippets for interviews

Get familiarize with coding snippets which are extremely useful for interviews.  See:

Audio version of this blog (like a podcast)

Now by far the best book (although I think I could have created a better version) for studying for programing interviews is: "Cracking The Coding Interview"

Got more tips and patterns? Any tricks that help you? comment and let us know!!


Popular posts from this blog

Functional Programming in Scala for Working Class OOP Java Programmers - Part 1

Introduction Have you ever been to a scala conf and told yourself "I have no idea what this guy talks about?" did you look nervously around and see all people smiling saying "yeah that's obvious " only to get you even more nervous? . If so this post is for you, otherwise just skip it, you already know fp in scala ;) This post is optimistic, although I'm going to say functional programming in scala is not easy, our target is to understand it, so bare with me. Let's face the truth functional programmin in scala is difficult if is difficult if you are just another working class programmer coming mainly from java background. If you came from haskell background then hell it's easy. If you come from heavy math background then hell yes it's easy. But if you are a standard working class java backend engineer with previous OOP design background then hell yeah it's difficult. Scala and Design Patterns An interesting point of view on scala, is

Alternatives to Using UUIDs

  Alternatives to Using UUIDs UUIDs are valuable for several reasons: Global Uniqueness : UUIDs are designed to be globally unique across systems, ensuring that no two identifiers collide unintentionally. This property is crucial for distributed systems, databases, and scenarios where data needs to be uniquely identified regardless of location or time. Standardization : UUIDs adhere to well-defined formats (such as UUIDv4) and are widely supported by various programming languages and platforms. This consistency simplifies interoperability and data exchange. High Collision Resistance : The probability of generating duplicate UUIDs is extremely low due to the combination of timestamp, random bits, and other factors. This collision resistance is essential for avoiding data corruption. However, there are situations where UUIDs may not be the optimal choice: Length and Readability : UUIDs are lengthy (typically 36 characters in their canonical form) and may not be human-readable. In URLs,

Dev OnCall Patterns

Introduction Being On-Call is not easy. So does writing software. Being On-Call is not just a magic solution, anyone who has been On-Call can tell you that, it's a stressful, you could be woken up at the middle of the night, and be undress stress, there are way's to mitigate that. White having software developers as On-Calls has its benefits, in order to preserve the benefits you should take special measurements in order to mitigate the stress and lack of sleep missing work-life balance that comes along with it. Many software developers can tell you that even if they were not being contacted the thought of being available 24/7 had its toll on them. But on the contrary a software developer who is an On-Call's gains many insights into troubleshooting, responsibility and deeper understanding of the code that he and his peers wrote. Being an On-Call all has become a natural part of software development. Please note I do not call software development software engineering b