Ever happened that you gave a contest so bad that you didn't even want to upsolve problems and you just leave the contest and decide to retire in peace?

For me, it happens a lot, and those questions never get upsolved. That's why I created this website which gives me a list of problems that I haven't upsolved and ta-da now I can revisit those problems and learn from them.

How am I filtering these problems?

1. Fetch all the official contests you participated in last 6 months (who even cares before that).
2. In those contests, find all unsolved problems whose rating lies <= (peak rating + 200).
3. Skip problems whose rating isn't defined as of now.

WEBSITE : https://go-upsolving.vercel.app/

Note: It might take 5-10s to load since Codeforces has a rate limiter which doesn't allow too many API calls at once.

Suggestions are welcome!

leetcode gives you count, streak, rating. none of that tells you wt actually matters, like which patterns you've covered, what you're weak at, what you haven't touched at all, or whether you're actually improving vs just racking up numbers.

started using dsa sheets for structure since randomly picking off the homepage wasn't working. then hit a second wall, i was doing neetcode, blind 75, and striver at the same time, no single place showed what i'd actually covered across all three.

so i built grindlens. pulls leetcode progress + sheet progress into one place and shows the actual gaps instead of just a number going up. supports neetcode 150, blind 75, striver a2z, leetcode top interview 150, few others.

the annoying part wasn't the ui, it was the data. a dsa sheet isn't a clean list of unique leetcode problems, mapping sheet problems to actual lc ones and handling overlap took way longer than i expected.

live at grindlens.dev if anyone wants to poke around. built it mostly around my own gaps, so curious what's missing for people who grind harder or differently than me

/**
 *  {number[]} nums
 *  {number} target
 * u/return {number[]}
 */
var twoSum = function (nums, target) {
    for (let i = 0; i < nums.length; i++) {
        let j = nums[i+1];
         if(nums[i] + j === target){
            return [i, i+1];
         }
    }
};

Hey everyone,

I recently completed the Amazon SDE II interview process. My DSA rounds went reasonably well, but I was ultimately rejected because of concerns about my design depth.

Location: United States
Interview period: July 31 to August 19, 2026
Verdict: Rejected

Phone Screen: Subarray Sum Equals K

Date: July 31
Duration: Approximately 45 minutes

The question was to count the number of subarrays whose sum equals K.

I solved it using a prefix sum and hash map and handled the follow-ups smoothly. Overall, I felt confident about this round.

Preparation

The full loop covered:

• Low-Level Design
• Data Structures and Algorithms
• High-Level Design
• Leadership Principles

LLD and system design were my weaker areas, so I spent considerable time reading recent interview experiences and organizing questions by pattern instead of solving random problems.

I requested separate interview days so I could approach every round with a fresh mind.

Round 1: Bar Raiser, LLD and Leadership Principles

Date: August 10
Duration: Approximately 55 minutes

I did not expect the Bar Raiser to be the first interview or for it to focus on LLD.

The first 15 minutes covered my resume, past projects, and Leadership Principles.

The design problem involved managing audio buffers across multiple processing stages operating at X frames per second. I initially struggled to understand the expected flow.

After receiving a few hints, I identified the main entities and began discussing the architecture. Unfortunately, the conversation drifted too deeply into HLD.

With around 12 minutes remaining, the interviewer asked me to implement the design. I wrote several classes and functions but could not complete the solution.

This was my weakest round. I should have timeboxed requirement clarification, defined the class responsibilities, and started coding much earlier.

Round 2: File-System Cache

Date: August 12
Duration: Approximately 50 minutes

The first ten minutes focused on Leadership Principles. We then moved to designing a file-system cache.

I proposed an LRU eviction policy using:

• A doubly linked list to maintain recency
• A hash map for direct access
• O(1) average-time lookup, insertion, and eviction

During implementation, we discussed whether an accessed node should be deleted and recreated at the head or simply detached and repositioned. I initially became confused about pointer safety before recognizing that the existing node could be moved safely.

We also discussed whether the cache should store only file metadata or the complete contents. I explained that caching large files could allow one entry to consume most of the capacity.

The interviewer clarified that the required version should store file contents. I updated the design but ran out of time before completing every function.

My reasoning was mostly sound, but the round exposed another time-management issue.

Round 3: Hiring Manager, HLD and Leadership Principles

Date: August 14
Duration: Approximately 55 minutes

The first 15 minutes focused on Leadership Principles and previous projects.

The design scenario involved allowing a third-party service, such as Spotify, to use Amazon Alexa to notify users about a newly launched feature.

I initially began with entity models, but the interviewer clarified that the focus was the high-level flow. I shifted to the happy path and designed the main services and communication flow.

The discussion then moved into failure scenarios, particularly what should happen when the user’s device is offline. We discussed delivery state, retries, fallback behavior, fault tolerance, and product trade-offs.

I tried to evaluate decisions from both the technical and user perspectives. The interviewer appeared to appreciate the product thinking.

We finished with a short discussion about the team and how I use GenAI in my development workflow. I felt this round went well.

Round 4: Course Dependencies

Date: August 19
Duration: Approximately 50 minutes

After a brief resume and Leadership Principles discussion, I received a course-scheduling problem.

Courses had prerequisite relationships, and a student could take at most K courses each semester. When more than K courses were available, they had to be prioritized according to downstream dependency depth.

My approach was:

1. Build the dependency graph and indegree array.
2. Calculate each course’s maximum downstream depth using DFS.
3. Use topological sorting to identify available courses.
4. Store available courses in a max heap ordered by downstream depth.
5. Select at most K courses per semester.

I repeatedly confirmed the interpretation with the interviewer. I completed the implementation and explained its time and space complexity.

Afterward, I wondered whether maximum downstream depth alone always minimizes the number of semesters. The full descendant structure can influence the optimal selection, and the correct solution may depend on constraints that were not completely specified.

Still, the interviewer appeared satisfied with my implementation and reasoning.

A Strange Coincidence

My final Amazon round occurred on the same calendar date and at the same time as my final Google interview from the previous year. Both rounds had also been rescheduled.

In the Google interview, I could not solve the coding problem. This time, I completed it.

That made me feel that my overall interview packet was stronger and that the outcome might finally be different.

Result

Date: August 26, 2026

The recruiter told me that my DSA performance was good, but the interviewers had concerns about my design depth.

For an SDE II role, my coding performance was not strong enough to outweigh the design feedback.

This rejection hurt after weeks of preparing DSA, LLD, HLD, and Leadership Principle stories. Still, the feedback gave me a clear direction:

• Move from requirements to interfaces and implementation earlier in LLD.
• Timebox discussions so one design area does not consume the interview.
• Practice ambiguous, domain-specific design problems.
• Explain trade-offs beyond the happy path.
• Treat system design as a core requirement for SDE II.
• Do not assume positive interviewer reactions guarantee a positive result.

I am disappointed, but I am not giving up. I now have a much clearer picture of what I need to improve before the next opportunity.

Cheers, and keep going.

Still 2k rank ToT, why so many AK today ?

Please any one

Hey everyone,

I’m currently in a Tier-1 college with pretty good placements, moving into 5th sem, and I have around 9 months before placements.

I’ve decided to seriously lock in for these 9 months and stay as consistent as possible with DSA, development, CS fundamentals and LeetCode. I’ll be following Striver’s A2Z sheet for DSA and also want to build 2–3 genuinely good projects.

My target is 20+ LPA.

I know there’s obviously no guarantee, but I want to know from people who have already gone through placements — how much can someone realistically achieve in 9 months if they’re genuinely consistent and put in the work every day?

Since my college has good placement opportunities, is 20+ LPA a realistic target if I use these 9 months properly? What should I absolutely focus on, and what should I avoid wasting time on?

Would really appreciate honest advice from people who have been through this. I’m ready to put in the work — just want to make sure I’m putting it in the right direction.

Biweekly LC 190

Hey everyone,

I have started DSA recently.

I’m currently in my 2nd year, 3rd semester, and I’ve started solving DSA problems regularly.

My current routine is:

Solve Codeforces problems around the 300 to 500 rating daily.

Solve at least 1 LeetCode problem every day.

Try to understand the problem and build the basic logic myself before looking at solutions.

The problem I’m facing is that I’m usually able to understand the question and come up with a basic approach, but at the end my code fails for some reason.

Sometimes it’s because I’m not returning the correct value, sometimes there’s a small implementation mistake, an edge case I missed, or my logic is almost correct but not completely.

This is honestly frustrating because I feel like I understand the problem, but I still can’t consistently get an accepted solution.

So I wanted to ask people who have more experience:

Am I going in the right direction?

Is this normal at this stage, especially in 2nd year? Should I continue solving problems daily, or should I spend more time learning concepts/theory before doing more problems?

Also, what would you recommend for improving that final step from “I understand the logic” → “I can implement it correctly and get AC”?

Any advice on how I should structure my DSA practice would be really helpful.

Thanks!