This content originally appeared on DEV Community and was authored by Aditya Tyagi
A framework to solve any technical interview question
I have been working as a Senior Software Engineer — II (Frontend) from quite some time now and have been on both sides of the interview table. I have given a lot of technical interviews and have taken the same amount (if not more).
From white-boarding the data structures and algorithmic questions to pair-programming with my interviewer, its been an eye-opening & humbling experience of how draining these interviews can get!
Therefore, over these last 4 years, I have come up with this little framework that has helped me crack multiple roles in various tech companies.
There are 5 major parts to this problem solving approach
- Understand the problem
- Explore concrete examples
- Break it down
- Solve or Simplify
- Look back and refactor
Let’s go through each one of them in detail:
Understand The Problem
As soon as you are given the question, do not start slapping the keyboard and declaring variables. Breathe. Read the question and then re-read it.
“It is foolish to answer a question that you do not understand.”
- “How to Solve it” by George Polya
Then, try to note down answers to the following questions:
- Can I restate the problem in my own words?
- What are the inputs that go into the problem? This is the place where you can ask the interviewer for the edge cases with respect to inputs.
- What are the outputs that should come from the solution to the problem?
- Can the outputs be determined from the inputs? In other words, do I have enough information to solve the problem?
- How should I label the important pieces of data (variables declaration) that are part of the problem?
Explore Concrete Examples
Coming up with examples can help you understand the problem better. These examples also provide sanity checks that your solution works the way it should work.
This can help you to understand the nature of inputs and outputs more clearly and reveal any corner/edge cases.
These are nothing but user stories or unit tests for the problem statements.
For example, consider this question:
Write a function charCount which takes a string and returns count of each character in the string?
The examples of this can be:
charCount("aaa"); // Output -> {a:3}
charCount("hello"); // Output -> {h:1, e: 1, l: 2, o: 1}
// Check examples for empty inputs
charCount(""); // Output -> { }
// Check examples for invalid inputs
charCount(1234); // Output -> { }
// Check examples for invalid inputs
charCount(false); // Output -> { }
Break It Down
This is one of the most important, yet most ignored/skipped step. You need to keep the interviewer on the same page throughout your problem solving journey.
- Communicate while breaking the problem down
- Ask questions like “Does this sound good?” or “Am I going the right path?”
- Write comments and not the actual code.
- Explicitly write out the steps you need to take. You need to just write the pseudo-code or steps that you will be taking to solve the problem.
The process of breaking down the problem compels you to think about the code you will write before you write it and helps you catch any lingering conceptual issues or misunderstandings. This is an important step to follow and will help you immensely before you dive in and have to worry about the details like syntax of the code.
Solve or Simplify
By the time you arrive at this step, you should already have the pseudo-code written. All you have to do is just write the code now.
Defeat Them in Detail: The Divide and Conquer Strategy.
Look at the parts and determine how to control the individual parts, create dissension and leverage it.
- Robert Greene
If you are “stuck” and are not able to proceed, do not worry. Try to break down the problem into smaller problems. Try to identify a simpler problem and then solve it. This will also give you a psychological sense of achievement and thus help you proceed with the problem “emotionally”.
Yes, emotionally. There have been times when I started sweating, mouth went dry while solving a DSA question. One has to be in a balanced mental state to come down to a solution as this is a mental game!
To simplify:
- Find the core difficulty in what you are trying to do
- Temporarily ignore the difficulty
- Write a simplified solution
- Then incorporate that difficulty back in
Look Back And Refactor
This is the last piece, but the piece of this framework that will distinguish between a great candidate from a good one!
For refactoring, ask yourself:
- Can I check the result?
- Can I derive the result differently?
- Can I understand the solution at a glance? Is the solution readable?
- Can I use the same method for some other problem?
- Can I improve the performance of the solution?
- Can I think of other ways to refactor?
- How have other people solved the same problem? This is something that comes in “Looking Back” area of the framework!
All the very best for your interview (if you have any coming up).
Thanks for reading ❤
If this blog was able to bring value, please follow me on Medium! Your support keeps me driven!
Originally published on adityatyagi.com
Want to connect?
Follow me on Twitter and LinkedIn or reach out in the comments below!
My name is Aditya. I am a Senior Software Engineer - II (Frontend). I blog about web development!
This content originally appeared on DEV Community and was authored by Aditya Tyagi
Aditya Tyagi | Sciencx (2022-06-24T15:06:32+00:00) 4+ years of cracking technical interviews. Retrieved from https://www.scien.cx/2022/06/24/4-years-of-cracking-technical-interviews/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.