Recently, I interviewed for Software Developer profile in a big product based company. Although many questions asked there were already given on Glassdoor and GeeksForGeeks. I prepared for them also but don’t know why I forgot the concepts or approach for many questions. Then I analyzed what happened to me and I think that my problem solving approach is not good and it needs improvement.
Here are the steps which I follow when solving a problem associated with DS and Algorithms or when preparing for interview:
- I look at the question and think of its solution for maximum 1 minute.
- If I am able to find a solution then I match my solution with the provided solution.
- But if I am not able to solve it (which happens most of the time), then I look at the brute force solution, try to understand it by drawing the cases and iterations on paper diagramatically.
- After that I try to write the solution code without seeing it on paper and then check whether I have written it correctly or not.
- Then I write it on code editor (either eclipse or gedit) and check again whether I have written correctly or not.
- Then I feel confident and move on to the next question.
I feel like this approach of mine is more sort of cramming than understanding the concept and I think that’s why I forgot the solutions in the interview. Moreover, I am able to find some of the solutions by brute force but I’m not able to find optimized solutions. So, I want to ask how can I improve my problem solving approach? I am really frustrated with my performance in the interview and I really want to improve myself to get a job in a big product-based company.
Can anyone please help and provide their valuable suggestions?
Any problem is becoming easier when you break it down to subtasks and subcategories. I consider 3 types of problems:
Classic problems aimed to check the knowledge of classic data structures like Stack, Queue or Hash Table - after a while it’s fairly easy to spot them and I feel that most interviews have these kind of problems in mind.
CURE: Learn basic data structures and understand how to connect dots between problem and data structure.
EXAMPLES: Depth-first search (Stack), Breath-first search (Queue), finding/counting substrings, subarrays etc. (Hash Table)
NOTE: Stack and Queue in JS both is an Array, and Hash Table - simply Object. No need to re-create a wheel
Method/functional problems - problems aimed to check knowledge of native methods/functionality. Before jumping into
for loop and
if...else madness, take a break and think if there are any native solutions to your problem.
CURE: MDN is your friend, learn each native method and you’ll be surprised how much problems are got you covered
EXAMPLE: Almost every problem here on freeCodeCamp
Brain puzzles - aimed to test ability to think outside the box and your reasoning - most difficult problems and also are fairly easy to spot, as they would sound something like “There 2 girls, one facing South and other - North and yet they see each other without mirrors”…
CURE: No cure - just don’t panic and start talking reasonably, so you look smart
I always thought it was silly to have stupidly hard algorithm tests in interviews.
How would you solve this stupidly hard linked list problem youll never see outside of a book in this unrealistic time?
Easy… google it.
Why not give people realistic problems ?
Because the way you approach this problem and how you solve it, describes a lot about how you would tackle actual real-world problems that you’ll face on the job.
Is it fair? Probably not. But an interview only has so much time available to judge your performance and make a decision.
I’d break it down into manageable chunks, get support from other developers or Google it if I get stuck.
But none of how you’re actually doing your job is measured in tests like that, it’s just the ability to memorize algorithms.
First of all, there are no “stupidly hard algorithm tests” in most interviews.
Most of them are the easy ones, like reversing a Linked List or stuff like that.
It’s all about how you think and how you can transfer your knowledge.
On the job, there will be a lot of different variants of problems,
therefore you need a lot of transfer skills.
You can easily see, if a person only memorized something or if he also understood it.
Why no real life problems?
Because most real life problems (whatever this should be) are also not in the scope of a company’s work.
Hi Mike. I really haven’t found that at all in my experience, code challenges ove been sent from several junior level roles in my area have been 4/3rd kyu level on code wars.
Bear in mind though these were created by Employment agencies.