How to Prepare for a Technical Skills Assessment

I'm often asked what to do if one can't solve a coding problem after pondering it for 15-20 minutes. People often hit a wall while preparing for coding interviews. I did too. Here are my suggestions: 👉𝐏𝐫𝐚𝐜𝐭𝐢𝐜𝐞 𝐀𝐜𝐭𝐢𝐯𝐞𝐥𝐲: Instead of passively reading the explanation after 15-20 minutes, try to struggle with the problem a bit longer. This is where the learning really happens. If you can't solve it, try to identify which part of the problem you find challenging. Is it the initial approach? Is it a tricky corner case? Once you've identified your weak point, you can then focus on solutions to that specific issue. 👉𝐔𝐧𝐝𝐞𝐫𝐬𝐭𝐚𝐧𝐝 𝐭𝐡𝐞 𝐂𝐨𝐧𝐜𝐞𝐩𝐭𝐬, 𝐍𝐨𝐭 𝐉𝐮𝐬𝐭 𝐭𝐡𝐞 𝐒𝐨𝐥𝐮𝐭𝐢𝐨𝐧𝐬: While it's tempting to memorize solutions, the interviewers are more interested in how you think and approach a problem. So, focus on the underlying techniques, patterns, and algorithms. Once you deeply understand a concept, you'll be able to apply it to a variety of questions. 👉𝐒𝐩𝐚𝐜𝐞𝐝 𝐑𝐞𝐩𝐞𝐭𝐢𝐭𝐢𝐨𝐧: Instead of reviewing all questions every day, use the spaced repetition technique. For example: 1. Review a question you've solved today. 2. Review it again in two days. 3. If you solve it successfully, review it again in a week. 4. If you still solve it successfully, review it again in two weeks. This technique will help you remember the approach over the long term. 👉𝐃𝐢𝐬𝐜𝐮𝐬𝐬 𝐰𝐢𝐭𝐡 𝐏𝐞𝐞𝐫𝐬: Talking through your solution, or even your confusion, with someone else can be very beneficial. This could be in online forums, study groups, or with friends preparing for similar interviews. Explaining your thought process to someone else can help solidify your understanding. 👉𝐂𝐚𝐭𝐞𝐠𝐨𝐫𝐢𝐳𝐞 𝐏𝐫𝐨𝐛𝐥𝐞𝐦𝐬: Many problems can be grouped together into certain categories like sliding window. Once you've solved a few problems in a category, try to summarize the general approach that apply to that category. This way, when faced with a new problem, you can try to fit it into a known category and apply the corresponding techniques. 👉𝐌𝐨𝐜𝐤 𝐈𝐧𝐭𝐞𝐫𝐯𝐢𝐞𝐰𝐬: Consider mock interviews with friends or using platforms that offer this service (check https://lnkd.in/gwrarnyD). This not only helps with problem-solving but also gets you comfortable with explaining your thought process. 👉𝐕𝐚𝐫𝐢𝐚𝐭𝐢𝐨𝐧 𝐢𝐬 𝐊𝐞𝐲: Instead of solving similar problems repeatedly in a short span, try a mix. For instance, after two-pointer problems, move on to recursion, then sliding window, and then come back to two-pointers. This cyclic variation helps cement your learning better. 👉𝐔𝐧𝐝𝐞𝐫𝐬𝐭𝐚𝐧𝐝 𝐌𝐢𝐬𝐭𝐚𝐤𝐞𝐬: Whenever you can't solve a problem, instead of just reading the solution, ask yourself why you couldn't solve it. Is there a pattern or concept you're consistently missing? By recognizing your weak spots, you can focus on improving in those areas. #codinginterview #datastructures

Here’s how I use NeetCode to prepare for technical interviews: ➡️ Being good at LeetCode looks like being able to see a new problem and recognize how it fits into the pattern (problem solving strategies, data structures, use cases) of previous problems you’ve seen. The benefit of using NeetCode instead of just doing random LeetCode problems is that it allows you to develop this pattern recognition. ➡️ I mainly use the “Roadmap” tab, which breaks down 150 LeetCode problems (the NeetCode 150) by topic area. I just follow the tree from top to bottom. ➡️ I got the advice to finish one topic completely before moving onto the next one, so that’s what I do. This goes back to pattern recognition: doing the same type of problem over and over will allow you to pick up on the tools and ways of thinking you keep revisiting in order to solve the problem type. It’s like if an electrician fixes 5 lightbulbs in a row, sooner or later they don't need to wonder what tool they should be using. They will reach for their wrench as soon as they need to fix a 6th lightbulb. ➡️ I set a stopwatch and begin solving the problem. If I’m not able to figure it out after 30-45 minutes, I stop and watch the solution videos. Sometimes I just need to watch the conceptual part of the video and then I’m able to figure out what I was missing, but sometimes I have to watch the whole video and literally copy the NeetCode solution. ➡️ After I finish this process, I go to my tracker and note what happened. I list down the following information: 1️⃣ The problem number & type. 2️⃣ How hard I thought the problem was on a scale of 1 (easy money) to 10 (screaming, crying, throwing up). (If the score is above a 6, then I make a note to revisit the problem.) 3️⃣ How much time I spent working on the problem. 4️⃣ What general steps I took to solve the problem and any patterns I recognized between problems. 5️⃣ Any other lessons and notes I took away from the problem (i.e. errors I ran into, documentation I forgot and had to search up.) I definitely didn’t do all of these things every day. Sometimes I only tried the problem for 10 minutes before watching the solution video. Sometimes I stopped halfway on a problem and picked it back up the next day. It’s amazing what sleeping on a problem can do. What’s the best advice you’ve heard around getting good at LeetCode problems? That’s all for now— ~aminah. —— If you got value from this post, consider following and republishing! 🫶🏾

Just a while back, I made an internal move at Microsoft & switched teams.  In the last few weeks, I prepared for interviews while juggling my day-to-day work. With just a couple of hours a day to prep, I knew I had to work smarter, not harder. Here’s how I approached it: 1️⃣ Clear Thought Process With limited time, I knew that the first thing I had to do was structure my thought process. How did I do it? —  Looked back on my experience of both giving and taking interviews to refine how I think through problems out loud. — I prioritized practice for clear communication and logical problem-solving. — I knew I wasn’t expected to memorize every possible solution; everyone always wants to see how you think. 2️⃣ System Design For system design, I didn’t try to learn everything, instead, I stuck to my fundamentals and practiced some breakdowns.  ✅ Used Grokking the System Design Interview to brush up on key concepts.  ✅ Reviewed fundamental designs like a rate limiter, Instagram, and Dropbox.  ✅ Stuck to high-impact resources: – https://lnkd.in/dXfPYfsr – https://lnkd.in/dSWCA6u7 – https://lnkd.in/duPMUhbK 3️⃣ For Coding Interviews I didn’t waste time grinding endless problems. Instead, I: — Brushed up on system libraries & useful tricks I might’ve forgotten. — Solved a few problems in key data structures (arrays, linked lists, trees) to stay sharp. I already knew enough, just wanted to make sure I could remember and apply it when needed. If you're ever short on time for your interviews, focus on clarity, structure, and communication. And whatever you do, don’t get stuck in the endless prep loop! Instead:  ✔ Revisit the basics  ✔ Test yourself with mock interviews  ✔ Just start, it’s okay if you don’t feel 100% ready The worst that happens? You will fail a couple of interviews before succeeding.  The best? You ace the first interview and move forward.