What is the best approach for solving coding challenges you are not familiar with?

Write it down! As you are writing it, think about creating a flow chart starting with "What is available to me" and ending with "What is the end goal of the problem". Then try breaking down the problem into sub-problems which you can fit into this flow-chart. Different people will use different approaches to solve a new problem. But as long as you understand the flow properly you will learn and solve it :)

Think of understanding the problem like reading a recipe before cooking. Carefully follow the instructions, ask questions if needed, and ensure you know exactly what you're aiming for before you start.

It may not appear helpful from the start but read the problem several times, at least more than twice. This helps you to fill in all blind spots in the process of understanding the problem in its entirety. You sufficiently understand the problem when you can clearly identify the inputs required, constraints in the process, your doubts, additional questions, and any others. It is a vital part of solving the problem and you must spend enough time (resources) to do it well.

First of all, write down the problem or its statement. Its input, expected output, constraints if any. Check if you find any pattern in there. DO NOT go for optimized approach directly. Lets say its an algorithmic problem: Try to solve using Brute-force. As you'll build your brute-force, you'll start realizing the optimization point. Such as some part of it getting repeated so go for recursion and then dynamic programming, or is it binary search or tree or graph etc. etc. Once, you come up with a solution, challenge your solution, why its good and then how it can be done better.

In my experience, dry running an approach with some quick sample input values on a sheet of paper, looking at the iterations your algorithm goes through helps get clarity on smaller edge cases that you might have missed. I always test with edge values, vanilla flow and an infinite value flow.

No need to jump on optimized solution directly. A starting point should be your brute-force solution. Then you'll find a pattern, so check the constraints as they are really helpful. If your some part of code getting repeated, you might consider recursion but it uses auxiliaries space, you might want to consider Dynamic programming etc. Challenging your solution is one of the best way to reach optimal state. However, its important that you're well aware of linear and non-linear type of data structure.

Look at the input/output constraints given in the question. For example, if an array will contain 100 elements at max, you can think upto order of N^3 solution, but if the array can contain 10^5 or more elements, you might want to think of algorithms or data structures that work in O(NlogN) or lesser time complexity.

I agree. The mode of the interview also matters. In a one-on-one interview, the interviewer is often interested in your understanding of the problem, your approach to solving it, and a technical check of your grasp of relevant concepts for the potential solution. On the other hand, if an online challenge platform is used for assessment, your primary focus should be providing a solution in the specific context of the problem's requirements. If a particular method, package, or algorithm is requested for the solution, you must use it. However, if the platform is only testing your solution with test data and validating the outcomes, any approach that solves the problem should suffice.

Think of choosing your approach like picking the right path in a maze. You'll decide how to navigate based on the twists and turns of the problem. Make sure to explain your choice, like telling a friend why you're taking a certain route in a maze.

Before choosing the most suitable approach, one should make a brute-force solution that functionaly solves the problem. Humans are always confused in case of alternatives, what I do is to brainstorm the key pointers or KPIs for the assessment of a particukar solution. For example: Memory/Computation Cost and Requirements, coding efforts, risk(failures), coverage of edge cases. Leading this, these KPIs will help anyone to choose the best option of tools/data structures available to serve the case and that provide the best tradeoff among all the considered KPIs.

If you're doing a whiteboard interview, one super helpful tip I found when I interviewed and I got 18 offers was to write the outline and leave whitespace on the white board between function/methods skeletons. This tip for managing space on the whiteboard comes in really handy towards the end as you start running out of time- you don't want to be erasing and rewriting code at the end frantically. Also, bring your own (thin, optimized) markers- don't rely on the ones the company provides

You will most likely get pushback from your interviewer if you start writing pseudocode. This is often viewed as a waste of time. Writing a short outline is viewed as a positive.

Imagine you're making a to-do list before tackling a task. Write down the steps you'll take in plain language, like giving yourself a roadmap. It's like planning your journey before you start.

Tackling unfamiliar coding challenges starts with pseudocode. - Pseudocode breaks problems into manageable steps. - It provides clarity without language-specific syntax. - Outlining logic first reduces coding errors. - Iterative refinement ensures optimal solutions. - Using comments can guide actual coding. Think first, code effectively.

Writing pseudocode or outline is important yet we often neglect their purpose. They are different from code because they are short summary/steps lf the whole code. Now, if they take even 30% of the whole time required to code, then the purpose is killed. In a nutshell, the pseudo/outline or a visual representation of steps is required but one should always practice of summarizing them in the shortest yet clear view.

Your initial iteration of the solution may not always be the best, so it's wise to begin by using the flowchart or algorithm you've already developed. Validate and thoroughly test your solution for various scenarios, including those it should work for and those it shouldn't. Often, developers concentrate solely on writing code that meets the problem's requirements but overlook testing it against invalid inputs or cases. Once you've confirmed that your code works effectively, you can then focus on optimizing it to enhance non-technical aspects such as readability, scalability, commenting, and adopting good naming conventions.

Always start coding incrementally - Begin implementing your solution incrementally, one step or sub-problem at a time. - Test each part independently as you got to identify and fix the potential issues early. - Once you have a working solution, do consider optimizing it for better efficiency and readability.

While coding the solution, try to use the programming language related to the position you are interviewing about. In most cases, the interviewer will specify the language they want you to answer in. Firstly, focus on the main objective. Make sure your code works in "happy path", that is, in the best-case scenario and it has a good structure. Afterward, you need to consider edge cases and add error handling where applicable.

Now it's time to write your code, just like crafting a recipe from your notes. Use a programming language you're comfortable with, follow its rules, and give your code clear names. Keep it simple, like cooking without unnecessary ingredients, and make it easy to understand, like a well-written recipe.

You should always use the language and set of structures/function you are suitable with. The best way is to start with a working solution in the first step. In case the code contains complex steps in between, you should always check the before and after of those particular lines. Remember, try to test them on very smaller set of inputs/data records. In case you have to roam up and down to read the codes again and again, change the structure. For example: If I write a function on top while it's usage is in the last of code. To change the inputs and function's body, I need to move up and down that kills my focus. What I prefer is to keep the code of function in place of function call and once it's validated, I will make it a function.

One should think of the problems a line of code may make while writing it. For example: While writing X= a/c I should understand that this code will provide an exception on c=0. Writing a set of test conditions is very important and that's why a TDD(Test Driven Development) is preferred.

Think of testing and debugging like trying on shoes. Check if they fit comfortably by testing them on different paths, and if they pinch your toes, fix them before you step out.

Usually, the interviewer provides the test cases to test the code. But while coding itself, try to think of the edge cases to incorporate them in your solution before hand.

Code that isn't tested it not complete, it's that simple. You are responsible for the product you make, and other people are relying on your work. Not testing it before signing off on something wastes other people's time. Test thoroughly - proportional to the task. A complex task should be tested more thoroughly than one with a small surface area. Think outside the box - how would someone use this? What could go wrong? Could the code's use change over time, and are we ready for that? Lastly - make sure it fails gracefully. You might miss something, so make sure your errors help fix the issue, and make sure the failure of your code doesn't break everything else.

Lets assume that you've cracked the problem with your clever approach, but don't pop the champagne just yet! Now it's time to put on your detective hat and test your solution like a pro. Hunt down those sneaky bugs, make sure it runs like a well-oiled machine, and if needed, give it a turbo boost for top-notch performance. Your programming skills are your secret sauce here!

Big problems, should be broken down into small manageable problems. Assuming time isn't a key factor, I find it best to start with the trivial / naive approach. This will get you going quickly and will at least put one viable solution which solves the main problem on the board. The naive approach doesn't have to be coded, just written down. After you have the naive approach figured out, think of it's pitfalls and try to solve them. Usually the naive approach will have one major pitfall, which is the key to figuring out the less naive approach. There might also be pitfalls to the less naive approach, which opens the door to an even better approach.

Remember that solving unfamiliar coding problems is a skill that improves with practice. Don't be discouraged if it takes time to become proficient at it. Learning from your mistakes and seeking help or guidance from peers or online resources can be valuable in your coding journey.

Coding challenges are not just about finding the right answer but also about demonstrating your problem-solving skills and coding proficiency. Patience, practice, and a systematic approach will help you become more adept at handling unfamiliar challenges

Being used to import libraries is a serious thing. Learn to code in native language as often as possible to overcome the challenge. Ex. Python native VS importing other inclusive libraries, or APIs ( Pandas, Numpy) etc. I paid the price out of this innocent habit and the very thought got me paralyzed at the live coding session.

I've found that dedicating time to online coding platforms has significantly boosted my confidence in tackling complex programming problems. It's a must for anyone aspiring to excel in technical interviews.