Forem: Rakesh Reddy Peddamallu

complete path to becoming a professional UI engineer

Rakesh Reddy Peddamallu — Tue, 14 Apr 2026 06:55:18 +0000

Here's your complete path to becoming a professional UI engineer, broken down into phases:

Phase 1 — Foundations (2–3 months)

This is non-negotiable ground. Everything else builds on this. Don't rush it.

HTML: Semantic elements, forms and validation, accessibility basics, ARIA roles, the DOM structure, data attributes, meta tags.

CSS: The box model, specificity and the cascade, Flexbox, CSS Grid, positioning (static, relative, absolute, fixed, sticky), units (px, rem, em, %, vh/vw), pseudo-classes and pseudo-elements.

Vanilla JavaScript: Variables, functions, loops, arrays, objects, DOM manipulation, event handling, the basics of async (callbacks → promises → async/await).

Project to build: A fully static multi-page personal portfolio site — no frameworks, just HTML, CSS, and vanilla JS.

Phase 2 — Core JavaScript Depth (1–2 months)

You need to actually understand JS before jumping into React, or you'll be copy-pasting code you don't understand.

Closures, scope, and the this keyword. The event loop and how the browser executes code. Promises and async/await in depth. The Fetch API and working with REST APIs. ES modules (import/export). Array methods: map, filter, reduce, find. Error handling with try/catch.

Project to build: A weather app or movie search app that fetches real data from a public API, displays results, handles loading and error states — all in vanilla JS.

Phase 3 — React & Component Thinking (2–3 months)

React is the industry standard. Learn it deeply, not just the surface.

JSX syntax. Components, props, and state with useState. Side effects with useEffect. Conditional rendering and lists. Lifting state up and prop drilling. useContext for shared state. useRef for DOM access. Custom hooks. React Router for multi-page apps. Fetching data inside components, handling loading and error states.

Project to build: A full CRUD app — something like a task manager or expense tracker — with multiple routes, persistent data via localStorage, and clean component structure.

Phase 4 — Styling Systems & Design (1–2 months)

This is what separates developers who can code from developers who can build beautiful products.

CSS variables and theming. Responsive design and media queries properly. Mobile-first thinking. Tailwind CSS — understand the utility-first approach. CSS Modules for scoped styles. Basic design principles: spacing, typography scale, color contrast, visual hierarchy. Dark mode implementation. How to read and implement a Figma design accurately.

Project to build: Rebuild an existing well-designed website (like Stripe's landing page or a popular SaaS product) as a pixel-faithful clone using React and Tailwind.

Phase 5 — Professional Tooling & TypeScript (1–2 months)

This is what makes you functional in a real team codebase.

TypeScript: types, interfaces, generics, typing React components and hooks. Vite as a build tool — understand what bundlers do. ESLint and Prettier — linting and formatting. npm and managing dependencies. Environment variables. Git beyond the basics: branching, rebasing, pull requests, resolving merge conflicts. Writing readable commit messages.

Project to build: Convert your Phase 3 CRUD app entirely to TypeScript. Fix every type error without using any.

Phase 6 — State Management & Data Fetching (1 month)

Once apps grow, local state isn't enough.

When you need global state and when you don't. Zustand as a lightweight state manager — learn this before Redux. React Query (TanStack Query) for server state — caching, refetching, pagination, optimistic updates. The difference between client state and server state. Basic GraphQL concepts.

Project to build: A more complex app with real API integration — like a GitHub profile explorer or a Hacker News clone — using React Query for all data fetching.

Phase 7 — Performance & Quality (1–2 months)

This is where junior ends and mid/senior begins.

Core Web Vitals: LCP, CLS, FID/INP — know what they measure and how to improve them. Lazy loading images and components with React.lazy and Suspense. useMemo and useCallback — know when they help and when they're overkill. List virtualization for large datasets. Debouncing and throttling. Code splitting and bundle analysis. Using Chrome DevTools to profile and find bottlenecks.

Testing: Unit testing with Vitest/Jest. Component testing with React Testing Library. End-to-end testing with Playwright. The testing pyramid: know what to test at each level.

Project to build: Audit one of your previous projects using Chrome DevTools and Lighthouse. Fix every performance issue you find. Add a full test suite.

Phase 8 — Next.js & Production Thinking (1–2 months)

Most professional React jobs use Next.js or a similar framework.

SSR vs SSG vs CSR — know the tradeoffs deeply. The Next.js App Router. Server Components vs Client Components. Route handlers and API routes. Image optimization. Environment configuration. Deployment to Vercel. SEO basics: meta tags, Open Graph, structured data.

Project to build: A full-stack Next.js app deployed to production — a blog with a CMS, or a SaaS landing page with a contact form backed by a real database.

Phase 9 — Accessibility & Security (ongoing)

Most developers ignore these. Mastering them makes you stand out.

Accessibility: WCAG AA compliance. Keyboard navigation and focus management. Screen reader testing (use VoiceOver or NVDA). Color contrast requirements. Accessible forms, modals, and custom components.

Security: XSS prevention — never trust user input. CORS and why it exists. Authentication patterns: JWT, sessions, OAuth flows. Content Security Policy headers. CSRF basics.

Phase 10 — Collaboration & Career Skills (ongoing)

The skills that actually get you hired and promoted.

Reading other people's code without getting lost. Writing clear pull request descriptions. Giving and receiving code review feedback. Breaking a vague design into a component tree. Estimating tasks (badly at first, then less badly). Communicating blockers early. Writing documentation that future-you will thank present-you for.

Honest timeline

If you study and build consistently (3–4 hours a day): 12–18 months to be genuinely hireable as a junior-to-mid UI engineer. Phases 1–6 get you to hireable. Phases 7–10 get you to strong mid-level.

The single biggest mistake people make is spending too long in tutorial mode and not enough time building real things that break in ways tutorials don't prepare you for. After Phase 2, every phase should be 40% learning and 60% building.

Want me to go deep on any specific phase?

concepts to learn

Rakesh Reddy Peddamallu — Sat, 11 Apr 2026 17:43:29 +0000

🧠 1. JavaScript (your real foundation — React is just a layer)

If this is shaky, everything collapses.

Core concepts

Closures (not definition — real use cases)
Scope chain
Hoisting (functions vs variables vs let/const)
this (call, apply, bind)
Prototypes & inheritance
Event loop (microtasks vs macrotasks)

👉 You should be able to explain:

“Why does Promise run before setTimeout?”

Async mastery

Promises chaining
async/await vs .then
Error handling patterns
Parallel vs sequential execution (Promise.all, etc.)

Advanced JS (this is where mid-level → senior happens)

Debouncing & throttling (implement from scratch)
Deep vs shallow copy
Currying
Memoization
Immutability (why it matters in React)

⚛️ 2. React Core (but deep, not surface level)

Rendering & lifecycle

What triggers re-render?
Parent → child render flow
Reconciliation algorithm (high level is fine)
Keys (why index is bad — but also when it's okay)

Hooks (this is where interviews focus heavily)

useEffect (timing, cleanup, dependency traps)
useState batching behavior
useRef (why it doesn’t trigger re-render)
useMemo vs useCallback vs React.memo

👉 You should clearly answer:

“Why is my useEffect running twice?” (React 18 Strict Mode)

Advanced patterns

Controlled vs uncontrolled components
Compound components pattern
Render props
Higher Order Components (HOC)
Custom hooks (design clean APIs)

⚡ 3. React Performance (high signal topic)

Avoiding unnecessary re-renders
Memoization strategy (not overusing it)
List rendering optimization
Virtualization (like react-window)
Code splitting (React.lazy, Suspense)

👉 Strong answer:

“How do you debug performance issues in React?”

🏗️ 4. State Management (you need opinions here)

Local vs global state
Context API (and its limitations)
Redux (why, when, when NOT)
Zustand / lightweight stores
Server state vs client state (React Query mindset)

👉 You should say:

“I wouldn’t use Redux here because…”

🌐 5. API & Data Layer

REST vs GraphQL (basic tradeoffs)
Caching strategies
Error handling patterns
Request cancellation (AbortController)
Pagination / infinite scroll

🎨 6. Browser & UI Fundamentals (people ignore this and suffer)

Browser internals

DOM vs Virtual DOM
Reflow & Repaint
CSS specificity
Layout systems (Flexbox, Grid)

Performance basics

Critical rendering path
Lazy loading images/components
Debouncing user input (search bars etc.)

🧩 7. System Design (frontend version)

This is your SDE-2 differentiator

You should be able to design:

Dashboard UI (you literally built one — use it)
Chat app (you’re working on it — perfect)
Data-heavy table (filters, sorting, pagination)

Focus on:

Component structure
State flow
API handling
Performance tradeoffs

🧪 8. Testing (at least decent level)

Unit testing (Jest)
React Testing Library
Mocking APIs
Testing user behavior (not implementation)

🔐 9. Auth & Security (VERY underrated)

Since you worked on IAM — use it.

JWT vs session
Token refresh flow
Secure storage (cookies vs localStorage)
XSS / CSRF basics

🧱 10. Architecture & Real-world Thinking

This is where you stand out.

Folder structure
Reusable components
Separation of concerns
API abstraction layer
Microfrontends (you’ve touched this — leverage it)

⚠️ Brutal truth (you’ll appreciate this)

Most 4-year devs:

Know hooks ✅
Can build UI ✅
Cannot explain WHY things work ❌

That’s exactly what interviews test.

🧭 Simple way to check yourself

If you can confidently answer questions like:

“Why does React re-render?”
“How does event loop work?”
“When would you NOT use useEffect?”
“How would you design a scalable table?”

👉 You’re in top ~15%.

💥 My opinion on you (based on your work)

You already have an edge:

Dashboard work
IAM flow
Complex UI

If you package that into clear explanations, you’ll crack strong companies.

If you want next level:
I can give you:

🔥 30 real interview questions (React + JS + design)
🎯 or do a mock interview and expose gaps

Just tell me what you want.

Leetcode - 23. Merge k Sorted Lists

Rakesh Reddy Peddamallu — Mon, 15 Sep 2025 16:29:19 +0000

When working with linked lists, a classic problem you’ll encounter is:

“Given k sorted linked lists, merge them into one sorted linked list and return it.”

This problem is a favorite in interviews (especially LeetCode #23) because it combines understanding of linked lists, divide-and-conquer, and complexity trade-offs. Let’s dive in step by step.

🧩 Problem Breakdown

We’re given k linked lists, each individually sorted. Our task is to merge them into one sorted linked list.

For example:

Input:
lists = [
  1 -> 4 -> 5,
  1 -> 3 -> 4,
  2 -> 6
]

Output:
1 -> 1 -> 2 -> 3 -> 4 -> 4 -> 5 -> 6

💡 Approach

There are multiple ways to solve this problem:

Brute Force: Put all nodes into an array, sort, then rebuild a linked list.

Simple, but sorting all nodes takes O(N log N) time, where N is the total number of nodes.
Not very elegant.

Min-Heap / Priority Queue: Keep all heads of the lists in a heap, repeatedly pop the smallest.

Efficient (O(N log k)) but requires a heap implementation.

Divide and Conquer (our approach):

Repeatedly merge pairs of lists (like merge sort).
Each merge is linear, and we keep halving the number of lists until one remains.
Clean and efficient without extra data structures.

We’ll use divide and conquer here.

🛠 Step 1: Merging Two Sorted Lists

We first need a helper to merge two sorted linked lists. This is like the merge step of merge sort.

const merge_two_lists = (list1, list2) => {
    let dummy = new ListNode();
    let head = dummy;

    while (list1 && list2) {
        if (list1.val < list2.val) {
            head.next = list1;
            list1 = list1.next;
        } else {
            head.next = list2;
            list2 = list2.next;
        }
        head = head.next;
    }

    if (list1) head.next = list1;
    if (list2) head.next = list2;

    return dummy.next;
}

This runs in O(n + m) where n and m are the lengths of the two lists.

🛠 Step 2: Merging K Lists Using Divide and Conquer

We now merge lists pair by pair until only one list remains.

var mergeKLists = function (lists) {
    if (!lists || lists.length === 0) {
        return null;
    }

    while (lists.length > 1) {
        let mergedLists = [];

        for (let i = 0; i < lists.length; i += 2) {
            let l1 = lists[i];
            let l2 = (i + 1) < lists.length ? lists[i + 1] : null;
            mergedLists.push(merge_two_lists(l1, l2));
        }

        lists = mergedLists;
    }

    return lists[0];
};

📊 Complexity Analysis

Merging Two Lists: O(n + m)
Merging K Lists (Divide & Conquer):
- Each round halves the number of lists.
- We perform log k rounds.
- Each node is processed in every merge step, so total work is O(N log k).

Where:

N = total number of nodes across all lists
k = number of lists

Space Complexity

We only use a few pointers and a dummy node.
O(1) extra space (not counting recursion stack if you write a recursive merge).

✅ Key Takeaways

The divide and conquer approach is elegant, efficient, and doesn’t require additional data structures.
Time complexity: O(N log k)
Space complexity: O(1)

If you need even faster performance in practice, a priority queue (min-heap) is often used, especially when k is very large. But for clean code and interviews, this divide-and-conquer approach is a winner.

Leetcode - 427. Construct Quad Tree

Rakesh Reddy Peddamallu — Tue, 09 Sep 2025 16:26:18 +0000

QuadTrees are a fascinating data structure, often used in image compression, spatial indexing, and graphics. In this blog, we’ll solve the LeetCode 427 – Construct Quad Tree problem, step by step.

📌 Problem Statement

You are given an n x n binary grid (only 0 and 1 values).

Your task is to construct a QuadTree based on this grid:

Each node in the tree represents a sub-square of the grid.
If the sub-square contains all the same values (0 or 1), it becomes a leaf node.
Otherwise, it splits into four children:
- topLeft
- topRight
- bottomLeft
- bottomRight

📖 What is a QuadTree?

A QuadTree recursively divides a 2D space into four quadrants.

For example, take this 4x4 binary grid:

The top-left 2x2 block is all 1 → becomes a leaf node.
The top-right 2x2 block is all 0 → another leaf node.
The bottom-left 2x2 block is all 0.
The bottom-right 2x2 block is all 1.

So the root node will split into four leaves.

🛠️ Approach

We’ll use DFS (divide and conquer) to recursively build the tree:

Check if the current sub-square is uniform (all values are the same).

If yes → return a leaf node.
If not → split into four quadrants.

Recursive Subdivision:

Divide the current square of size n into four n/2 quadrants.
Recursively construct the QuadTree for each.

Build the Node:

If it’s a leaf → isLeaf = true.
If not → isLeaf = false and link four children.

✅ Solution Code

/**
 * // Definition for a QuadTree node.
 * function Node(val, isLeaf, topLeft, topRight, bottomLeft, bottomRight) {
 *    this.val = val;
 *    this.isLeaf = isLeaf;
 *    this.topLeft = topLeft;
 *    this.topRight = topRight;
 *    this.bottomLeft = bottomLeft;
 *    this.bottomRight = bottomRight;
 * };
 */

/**
 * @param {number[][]} grid
 * @return {Node}
 */
var construct = function (grid) {

    const dfs = (n, r, c) => {
        let isAllSame = true;
        let firstVal = grid[r][c];

        // check if all values in current n x n block are the same
        for (let i = 0; i < n; i++) {
            for (let j = 0; j < n; j++) {
                if (grid[r + i][c + j] !== firstVal) {
                    isAllSame = false;
                    break;
                }
            }
            if (!isAllSame) break;
        }

        // case 1: all same → leaf node
        if (isAllSame) {
            return new Node(firstVal === 1, true, null, null, null, null);
        }

        // case 2: not uniform → divide into 4 parts
        let half = Math.floor(n / 2);
        let topLeftNode = dfs(half, r, c);
        let topRightNode = dfs(half, r, c + half);
        let bottomLeftNode = dfs(half, r + half, c);
        let bottomRightNode = dfs(half, r + half, c + half);

        return new Node(true, false, topLeftNode, topRightNode, bottomLeftNode, bottomRightNode);
    };

    return dfs(grid.length, 0, 0);
};

⏱️ Complexity Analysis

Time Complexity

At each level, we scan an n x n block to check if it’s uniform.
Then we split into 4 subproblems of size n/2.

So recurrence:

T(n) = 4T(n/2) + O(n^2)

This looks like O(n^2 log n) in the worst case.
But since each cell is checked only once in practice, the overall complexity simplifies to O(n^2).

👉 This is optimal since we must inspect every cell at least once.

Space Complexity

The recursion depth is O(log n) (each time we halve n).
The QuadTree itself can take up to O(n^2) nodes in the worst case (checkerboard pattern).

So space complexity is O(n^2).

🎯 Key Takeaways

QuadTrees are great for representing 2D uniform data efficiently.
If a subgrid is uniform, we don’t need to store every cell → compression.
Divide & conquer makes this problem elegant and intuitive.

Leetcode - 148. Sort List

Rakesh Reddy Peddamallu — Mon, 01 Sep 2025 11:41:18 +0000

Sorting a linked list isn’t as straightforward as sorting an array. With arrays, we can do quick sort or heap sort thanks to random access. But linked lists only allow sequential access, making those methods inefficient.

That’s where merge sort shines. It works beautifully on linked lists because splitting and merging can be done in-place with pointers. Let’s dive in.

🔹 Problem Statement

Given the head of a linked list, return the list sorted in ascending order.

Example:

Input:  4 → 2 → 1 → 3
Output: 1 → 2 → 3 → 4

🔹 Approach: Divide and Conquer

We apply the merge sort strategy:

Divide: Use the slow–fast pointer trick to find the middle and split the list into two halves.
Conquer: Recursively sort both halves.
Combine: Merge the two sorted halves back together.

🔹 Step 1: Find the Middle

We use two pointers:

slow moves one step at a time.
fast moves two steps at a time.

When fast reaches the end, slow will be at the middle.

const getMid = (head) => {
    let slow = head;
    let fast = head.next; // ensures we stop at the "first middle" for even length

    while (fast && fast.next) {
        slow = slow.next;
        fast = fast.next.next;
    }

    return slow; // returns middle node
}

🔹 Step 2: Merge Two Sorted Lists

This step is similar to merging two sorted arrays:

const merge = (list1, list2) => {
    let dummy = new ListNode(0);
    let tail = dummy;

    while (list1 && list2) {
        if (list1.val < list2.val) {
            tail.next = list1;
            list1 = list1.next;
        } else {
            tail.next = list2;
            list2 = list2.next;
        }
        tail = tail.next;
    }

    // attach the remaining part
    tail.next = list1 || list2;
    return dummy.next;
}

🔹 Step 3: Recursive Merge Sort

var sortList = function (head) {
    if (!head || !head.next) return head; // base case

    // 1. Split into two halves
    let mid = getMid(head);
    let right = mid.next;
    mid.next = null; // break the link
    let left = head;

    // 2. Recursively sort both halves
    left = sortList(left);
    right = sortList(right);

    // 3. Merge the sorted halves
    return merge(left, right);
};

🔹 Walkthrough Example: `4 → 2 → 1 → 3`

Step 1: Initial Split

Mid = 2
Left = 4 → 2
Right = 1 → 3

Step 2: Sort Left (`4 → 2`)

Mid = 4
Left = 4
Right = 2
Merge → 2 → 4

Step 3: Sort Right (`1 → 3`)

Mid = 1
Left = 1
Right = 3
Merge → 1 → 3

Step 4: Merge the Halves

Merge 2 → 4 and 1 → 3:

Compare 2 vs 1 → pick 1
Compare 2 vs 3 → pick 2
Compare 4 vs 3 → pick 3
Leftover → 4

Result: 1 → 2 → 3 → 4 ✅

Recursion Tree

sort(4 2 1 3)
   /        \
sort(4 2)  sort(1 3)
  /   \      /   \
 4     2    1     3

Merges:
(4,2) → (2 4)
(1,3) → (1 3)
(2 4) + (1 3) → (1 2 3 4)

🔹 Complexity Analysis

Time Complexity:
- Splitting takes O(log n) levels.
- Each merge across levels costs O(n).
- Overall: O(n log n).
Space Complexity:
- Merge happens in-place with pointers → O(1) extra space.
- Recursion depth = O(log n).

🔹 Why Merge Sort Works Best for Linked Lists?

Quick sort needs random access (bad for linked lists).
Merge sort only needs sequential traversal (perfect fit).
Splitting and merging are pointer operations, so memory overhead is minimal.

✅ Final Takeaway

Use slow–fast pointers to find the middle.
Recursively sort both halves.
Merge with pointer juggling.
Achieve O(n log n) efficiency with minimal space overhead.

👉 Next time someone asks “How do you sort a linked list?”, you’ve got a clean, interview-ready answer. 🚀

Backend Interview Prep Beyond LeetCode (For 3 Years Experience)

Rakesh Reddy Peddamallu — Sun, 31 Aug 2025 18:29:33 +0000

Most backend engineers spend months grinding LeetCode. But in reality, backend interviews are about much more than algorithms.

At 3 years of experience, interviewers want to know if you can design reliable APIs, work with databases efficiently, and build systems that scale.

Here’s the complete roadmap to prepare for backend interviews apart from DSA.

🔑 1. Core Language & Coding Skills

You need to be solid in the language you’ll interview in (Java, Python, Go, Node.js, etc.).

Data structures: arrays, maps, sets, queues
Object-oriented principles (SOLID, design patterns)
Concurrency, async programming (threads, promises, goroutines, etc.)
Error handling, logging, testing practices

📚 Resources

Effective Java (if in Java)
Design Patterns (Gang of Four book)
Language-specific docs

🌐 2. APIs & Web Fundamentals

Since most backend = APIs, expect deep questions here:

REST vs GraphQL (tradeoffs)
Authentication & Authorization (JWT, OAuth2, sessions)
Rate limiting, pagination, idempotency
Caching strategies (client, CDN, server-side)
API versioning & backward compatibility

📚 Resources

RESTful API design guidelines by Microsoft
Designing APIs with Swagger and OpenAPI

🗄️ 3. Databases & Storage

Databases are the heart of backend systems.

SQL: Joins, indexes, transactions, normalization vs denormalization
NoSQL: When to use MongoDB, Redis, DynamoDB
ACID vs BASE
Database sharding, replication, partitioning
Query optimization (EXPLAIN, indexing strategies)

📚 Resources

SQL Antipatterns (Bill Karwin)
MongoDB University (free courses)

⚡ 4. System Design (Backend-Oriented)

The big one: they’ll test your ability to design systems, not just functions.

Common questions:

Design a URL shortener (TinyURL)
Design an e-commerce backend (cart, checkout, inventory)
Design a rate limiter
Design a chat service (like WhatsApp)
Design logging/metrics pipeline

Focus on:

Scalability: load balancers, horizontal vs vertical scaling
Databases: choosing SQL vs NoSQL
Message queues (Kafka, RabbitMQ, SQS)
Caching (Redis, Memcached)
Microservices vs monolith

📚 Resources

System Design Primer (GitHub repo)
Educative’s Grokking Modern System Design

⚙️ 5. Infrastructure & DevOps Basics

You don’t need to be a DevOps engineer, but you must understand:

Containers & orchestration (Docker, Kubernetes basics)
CI/CD pipelines
Monitoring & logging (Prometheus, Grafana, ELK stack)
Cloud basics (AWS/GCP/Azure services like S3, EC2, Lambda)

📚 Resources

The Twelve-Factor App principles
FreeCodeCamp YouTube (Docker & Kubernetes tutorials)

🔒 6. Security Fundamentals

Interviewers often check if you can build secure systems.

Hashing, encryption (bcrypt, AES)
SQL injection, XSS, CSRF
HTTPS/TLS basics
Secure password storage & authentication flows

📚 Resources

OWASP Top 10

💻 7. Practical Coding Rounds

Beyond DSA, expect hands-on backend tasks like:

Build a REST API with CRUD & authentication
Design a rate limiter middleware
Build a message queue simulator
Implement caching layer with Redis

👉 Tip: Practice these by building small services with your stack (Node.js/Express, Spring Boot, Django, etc.).

👥 8. Behavioral & Team Skills

At 3 years, they expect:

Ownership: “Tell me how you debugged a production issue.”
Tradeoffs: “When would you use SQL vs NoSQL?”
Collaboration with frontend & DevOps teams

🛠 Suggested Roadmap

Here’s a practical way to prepare:

Language + APIs (2–3 weeks)
Databases (SQL & NoSQL, 2 weeks)
System Design (small to mid-scale) (3 weeks)
Infra basics (Docker, caching, queues) (2 weeks)
Build small backend projects (apply your learning)

✨ Final Thoughts

DSA clears the initial bar, but backend interviews are about real-world engineering: designing APIs, managing databases, scaling systems, and ensuring security.

To stand out in a 3 years backend interview, focus on:

APIs & databases (real-world problems)
System design (small to medium scale)
Hands-on projects (showing you can build, not just solve puzzles)

That’s how you show you’re not just a coder, but a backend engineer ready for scale.

Frontend Interview Prep Beyond LeetCode (For 3 Years Experience)

Rakesh Reddy Peddamallu — Sun, 31 Aug 2025 18:25:42 +0000

Most developers preparing for frontend interviews drown themselves in LeetCode. While data structures and algorithms are important, frontend interviews go far beyond just solving DSA problems.

If you’re preparing for a 3 years experience role, companies expect you to not only write clean code but also design scalable UIs, understand the browser deeply, and optimize for performance.

Here’s a roadmap of what you should prepare apart from LeetCode, with the best resources included.

🔑 1. Core JavaScript & Browser Fundamentals

This is the foundation of every frontend interview. Expect in-depth questions here.

Closures, hoisting, event loop, promises, async/await
this, prototype chain, classes, modules
Debounce, throttle, memoization, polyfills (implementations)
Deep vs shallow copy, immutability
DOM manipulation, shadow DOM, virtual DOM concepts
Event delegation, bubbling vs capturing

📚 Resources

JavaScript.info
You Don’t Know JS (Kyle Simpson)

⚛️ 2. React (or Your Main Framework)

At 3 years exp, you need to know React beyond the basics.

Hooks in depth (useMemo, useCallback, useReducer)
Context API vs Redux vs Zustand (state management tradeoffs)
Suspense and concurrent rendering
Controlled vs uncontrolled components
Performance optimization (lazy loading, code splitting, React Profiler)

📚 Resources

React.dev (new docs are amazing)
EpicReact.dev (Kent C. Dodds, premium but worth it)

🏗️ 3. Frontend System Design

You’ll likely get design-type problems like “build a scalable dashboard” or “design a search component with autocomplete.”

Component design patterns (container/presentational, compound components)
State management strategies in large apps
Microfrontends & module federation (high-level)
Caching, pagination, infinite scroll patterns
Performance budgets (bundle splitting, lazy loading, caching strategies)

📚 Resources

Frontend System Design Guide
Grokking Frontend System Design (Educative)

🎨 4. Styling, UI & Accessibility

Interviewers often test practical CSS and accessibility knowledge.

Flexbox & CSS Grid deeply
Positioning, stacking context, z-index
Responsive design techniques
Accessibility (ARIA roles, keyboard navigation, screen reader support)

📚 Resources

CSS Tricks
Kevin Powell’s YouTube channel

⚡ 5. Performance & Web Internals

They want to know if you can keep apps fast.

Repaint vs reflow
Lighthouse metrics (FCP, LCP, CLS, TBT)
Image optimization, code splitting, caching
Browser storage (localStorage, sessionStorage, IndexedDB)

📚 Resources

Web.dev Learn

💻 6. Practical Coding Rounds

Beyond DSA, you’ll get real-world UI problems. Some common ones:

Build a Todo app with filtering & persistence
Create a table with sorting, pagination, infinite scroll
Implement a debounced search box with API calls
Write a custom React hook

👉 Tip: Practice small projects instead of only solving LeetCode.

👥 7. Behavioral & Team Skills

At 3 years, interviewers also want to see maturity:

Ownership: “Tell me about a tricky UI bug you solved.”
Tradeoffs: “Why Redux over Context?”
Collaboration: working with backend and product teams

🛠 Suggested Roadmap

Here’s how you can structure your prep:

Revise JS deeply (2–3 weeks)
Master React & ecosystem (2–3 weeks)
Do 4–5 small projects (table, dashboard, search box, etc.)
Learn frontend system design (mock design problems)
Mix DSA with UI coding tasks

✨ Final Thoughts

LeetCode clears the initial bar, but your frontend expertise is what sets you apart. Companies want to see if you can build real, scalable, and performant apps—not just reverse a linked list.

So focus on:

JavaScript + React fundamentals
Frontend system design
UI building & optimization

That’s how you’ll stand out in a 3 years frontend interview.

Leetcode - 108. Convert Sorted Array to Binary Search Tree

Rakesh Reddy Peddamallu — Sun, 31 Aug 2025 18:00:27 +0000

When you’re given a sorted array, you might be asked to convert it into a height-balanced binary search tree (BST). A BST is called height-balanced if the depth of the two subtrees of every node never differs by more than one.

This problem comes up often in interviews because it beautifully combines recursion, binary search thinking, and tree construction.

💡 Intuition

Since the array is sorted, the middle element naturally makes the best root:

Everything to the left of the middle is smaller → belongs to the left subtree.
Everything to the right of the middle is larger → belongs to the right subtree.

By always picking the middle element as the root (and recursively repeating this for subarrays), we ensure the tree stays as balanced as possible.

For example:

nums = [-10, -3, 0, 5, 9]

Step 1: Pick middle → 0 (root)
            0
           / \
Step 2:  -10   5
             \    \
Step 3:      -3    9

This results in a height-balanced BST.

🛠️ Approach

Use recursion with two pointers (l and r) to define the current subarray.
Base case: if l > r, return null (no tree to build).
Find the middle index:

   let m = Math.floor((l + r) / 2);

Create a new TreeNode with nums[m].
Recursively build:

Left subtree → helper(l, m - 1)
Right subtree → helper(m + 1, r)
1. Return the node.

📜 Code (JavaScript)

/**
 * Definition for a binary tree node.
 * function TreeNode(val, left, right) {
 *     this.val = (val===undefined ? 0 : val)
 *     this.left = (left===undefined ? null : left)
 *     this.right = (right===undefined ? null : right)
 * }
 */
/**
 * @param {number[]} nums
 * @return {TreeNode}
 */
var sortedArrayToBST = function (nums) {
    const helper = (l, r) => {
        if (l > r) return null;

        let m = Math.floor((l + r) / 2);
        let node = new TreeNode(nums[m]);

        node.left = helper(l, m - 1);
        node.right = helper(m + 1, r);

        return node;
    }

    return helper(0, nums.length - 1);
};

⏱️ Complexity Analysis

Time Complexity: O(n)
Each element in the array becomes a node in the tree exactly once.
Space Complexity: O(log n) (average case, due to recursion stack depth)
Since the tree is balanced, the maximum recursive calls go as deep as the height of the tree, which is log n.
In the worst case (if array is skewed or large recursion overhead), it can be O(n).

✨ Key Takeaways

Sorted array + middle element logic → perfectly balanced BST.
Divide-and-conquer strategy keeps the tree height minimal.
This is a classic recursion problem that also reinforces binary search thinking.

Leetcode -79. Word Search

Rakesh Reddy Peddamallu — Sun, 31 Aug 2025 12:33:30 +0000

The Word Search problem is a classic interview question that tests recursion, grid traversal, and backtracking. In this blog, we’ll solve it two ways:

Using a Set to track visited cells (clear and beginner-friendly).
Using an in-place optimization (cleaner and space-efficient).

📌 Problem Statement

We are given a 2D board of characters and a word. We need to check if the word exists in the board.

Rules:

The word can be constructed from letters of adjacent cells (up, down, left, right).
A cell cannot be used more than once in the same path.

Example:

Board:
A B C E
S F C S
A D E E

Word: "ABCCED"
Output: true

💡 Approach 1: Using a Set

The idea is simple:

Try every cell (r, c) as a potential starting point.
Use DFS to explore neighbors.
Keep a Set of visited cells (so we don’t revisit them).
Backtrack: after exploring, remove the cell from the Set.

✅ Code (with Set)

var exist = function (board, word) {
    let rows = board.length;
    let cols = board[0].length;
    let pathSet = new Set();

    const backtrack = (i, r, c) => {
        if (i === word.length) return true;

        if (r < 0 || c < 0 || r >= rows || c >= cols ||
            board[r][c] !== word[i] ||
            pathSet.has(r + "," + c)) {
            return false;
        }

        pathSet.add(r + "," + c);

        let res = backtrack(i + 1, r + 1, c) ||
                  backtrack(i + 1, r - 1, c) ||
                  backtrack(i + 1, r, c + 1) ||
                  backtrack(i + 1, r, c - 1);

        pathSet.delete(r + "," + c); // backtrack cleanup

        return res;
    };

    for (let r = 0; r < rows; r++) {
        for (let c = 0; c < cols; c++) {
            if (backtrack(0, r, c)) return true;
        }
    }
    return false;
};

⚙️ Complexity (Set version)

Time Complexity:
- Worst case: O(rows × cols × 4^L) where L = length of the word.
Space Complexity:
- The Set stores up to L cells.
- Recursion depth = L.
- So O(L) extra space.

This is intuitive and great for understanding recursion, but we can do better.

💡 Approach 2: Optimized In-Place Marking

Instead of maintaining a Set, we can modify the board in-place:

At each step, temporarily set the current cell to "#" to mark it visited.
Explore neighbors.
Restore the original character when backtracking.

This way, “visited check” happens naturally because a "#" will never match the next character in word.

✅ Code (in-place optimization)

var exist = function (board, word) {
    let rows = board.length;
    let cols = board[0].length;

    const backtrack = (i, r, c) => {
        if (i === word.length) return true;

        if (r < 0 || c < 0 || r >= rows || c >= cols ||
            board[r][c] !== word[i]) {
            return false;
        }

        // Mark visited by modifying the board
        let temp = board[r][c];
        board[r][c] = "#";

        let res = backtrack(i + 1, r + 1, c) ||
                  backtrack(i + 1, r - 1, c) ||
                  backtrack(i + 1, r, c + 1) ||
                  backtrack(i + 1, r, c - 1);

        // Restore for other paths
        board[r][c] = temp;

        return res;
    };

    for (let r = 0; r < rows; r++) {
        for (let c = 0; c < cols; c++) {
            if (backtrack(0, r, c)) return true;
        }
    }
    return false;
};

⚙️ Complexity (Optimized version)

Time Complexity: Still O(rows × cols × 4^L).
Space Complexity: Only recursion depth → O(L). No Set, no extra storage. Cleaner and faster.

🔑 Comparison

Feature	With Set	In-place Optimization
Clarity	✅ Easy to follow	⚡ Cleaner, shorter
Extra Space	O(L) (Set)	O(1) extra
Speed	Slightly slower	Faster in practice
Interview value	Good starter	Impressive finish

✨ Takeaways

Set approach: Great for beginners, shows clear backtracking logic.
In-place approach: Professional, space-efficient, and elegant.
Both methods teach the importance of backtracking cleanup — the trick that makes recursion work correctly.

👉 In an interview, I’d start with the Set approach to explain my thought process, then optimize to the in-place version to show deeper problem-solving skills.

22. Generate Parentheses

Rakesh Reddy Peddamallu — Sun, 31 Aug 2025 04:48:52 +0000

Got it, Rakesh 🚀 Let’s turn this into a neat blog post. I’ll explain the problem, walk through the approach, give a complexity analysis, and finally embed your visualization iframe.

Here’s a polished draft for your blog:

Generate Parentheses — Explained with Backtracking & Visualization

One of the classic problems in coding interviews (especially LeetCode #22) is "Generate Parentheses". It’s a great way to understand backtracking, recursion, and how constraints guide the search space.

Problem Statement

Given n pairs of parentheses, generate all possible combinations of well-formed parentheses.

Example:

Input: n = 3
Output: ["((()))","(()())","(())()","()(())","()()()"]

Approach

This problem is a textbook case for backtracking.
We want to build strings step by step, only adding characters when they keep the parentheses valid.

Rules for Valid Parentheses:

We can add an opening parenthesis "(" as long as we haven’t used up all n.
We can add a closing parenthesis ")" only if the number of closing brackets is less than the number of opening ones so far (to avoid invalid strings like ")(").

We use a stack to build the current sequence and a recursive function to explore all possibilities.

Code Implementation

/**
 * @param {number} n
 * @return {string[]}
 */
var generateParenthesis = function (n) {
    let stack = [];
    let res = [];

    const backtrack = (openN, closedN) => {
        // Base case: if both counts reach n, we found a valid string
        if (openN === n && closedN === n) {
            res.push(stack.join(""));
            return;
        }

        // Add "(" if we still have openings left
        if (openN < n) {
            stack.push("(");
            backtrack(openN + 1, closedN);
            stack.pop(); // backtrack
        }

        // Add ")" if it's valid
        if (openN > closedN) {
            stack.push(")");
            backtrack(openN, closedN + 1);
            stack.pop(); // backtrack
        }
    };

    backtrack(0, 0);
    return res;
};

Complexity Analysis

Time Complexity: Each valid sequence has length 2n. The number of valid sequences is the nth Catalan number:

$$
C_n = \frac{1}{n+1} \binom{2n}{n}
$$

So, the complexity is O(Cn × n) (since joining each sequence takes O(n) time).

Space Complexity:
- The recursion depth is at most 2n.
- We use a stack of size 2n in the worst case.
- Result storage takes O(Cn × n).

So overall space complexity is O(Cn × n).

Visualization 🎨

Here’s an interactive visualization of the backtracking tree:

Final Thoughts

This problem is a perfect introduction to backtracking. It teaches how to explore a search space while pruning invalid paths early. Once you master this, you’ll notice a similar structure in problems like N-Queens, Combinations, and Subsets.

👉 Tip: When stuck in a backtracking problem, always ask:

“What choices do I have at this step?”
“What constraints stop me from making a choice?”

Leetcode - 52. N-Queens II

Rakesh Reddy Peddamallu — Sat, 30 Aug 2025 13:00:15 +0000

🏰 Solving the N-Queens Problem with Backtracking

The N-Queens problem is a classic in algorithms and interview prep. It asks:

Place N queens on an N×N chessboard so that no two queens attack each other.

Queens can attack vertically, horizontally, and diagonally. The task is to count the total number of valid arrangements.

✨ Key Insight

When placing queens row by row:

Each row can have only one queen.
Each column can have only one queen.
Each diagonal can have only one queen.

So, at each step, we just need to check if placing a queen in the current cell (r, c) is safe. If yes → place it and recurse to the next row.

⚙️ Backtracking Approach

We use recursion to try all possible placements:

Row by row recursion – Start from row 0, and for each column, check if placing a queen is valid.
Use sets for quick lookup:

col: columns where queens are already placed.
posDiag: positive diagonals (r + c is constant).
negDiag: negative diagonals (r - c is constant).
1. If a position (r, c) is safe:
Place queen → add to sets.
Recurse for next row.
Backtrack → remove from sets.
1. When r === n, we found a valid arrangement → increment result.

🖥️ Implementation (JavaScript)

/**
 * @param {number} n
 * @return {number}
 */
var totalNQueens = function (n) {
    let col = new Set();
    let posDiag = new Set();
    let negDiag = new Set();
    let res = 0;

    const backtrack = (r) => {
        if (r === n) {
            res += 1;  // Found a valid board
            return;
        }

        for (let c = 0; c < n; c++) {
            // Check if queen can be placed
            if (col.has(c) || posDiag.has(r + c) || negDiag.has(r - c)) {
                continue;
            }

            // Place queen
            col.add(c);
            posDiag.add(r + c);
            negDiag.add(r - c);

            // Recurse to next row
            backtrack(r + 1);

            // Backtrack (remove queen)
            col.delete(c);
            posDiag.delete(r + c);
            negDiag.delete(r - c);
        }
    };

    backtrack(0);
    return res;
};

⏱️ Time & Space Complexity

Time Complexity: O(N!)
- In the worst case, we try N options for row 1, N-1 for row 2, and so on.
- The actual branching is smaller due to pruning (invalid placements), but O(N!) is a safe upper bound.
Space Complexity: O(N)
- Sets col, posDiag, and negDiag hold at most N elements.
- Recursion stack depth is N.

✅ Example Run

For n = 4, the valid solutions are 2:

. Q . .      . . Q .
. . . Q      Q . . .
Q . . .      . . . Q
. . Q .      . Q . .

The function correctly returns 2.

🎯 Final Thoughts

This problem is a perfect introduction to backtracking because you learn how to try, prune, and backtrack.
Sets make the lookup O(1), which is much cleaner than scanning the board every time.
Once you master this, you can extend it to actually return the board configurations instead of just counting them.

Leetcode - 39. Combination Sum

Rakesh Reddy Peddamallu — Sat, 30 Aug 2025 09:31:41 +0000

The Combination Sum problem is a classic backtracking question from LeetCode (#39).

We are given:

An array of positive integers candidates (no duplicates inside).
A target integer target.

We must return all unique combinations where the chosen numbers add up exactly to target.
Numbers can be reused unlimited times.

🎯 Example

candidates = [2, 3, 6, 7], target = 7

Output:

[
  [2, 2, 3],
  [7]
]

Why?

[2, 2, 3] → adds to 7
[7] → also adds to 7
No other valid combinations exist.

🧠 Approach – Backtracking (DFS)

This is a search problem. Think of it like exploring all possible "paths" of numbers until:

The sum equals target → ✅ valid combination
The sum exceeds target → ❌ invalid, stop
We’ve tried all numbers → ❌ stop

We use DFS + backtracking:

Start at index 0 with an empty path [] and total 0.
At each step:

Either include the current candidate (stay on same index since we can reuse it).
Or skip it and move to the next index.
1. Whenever total === target, we push a copy of the path into results.
2. Backtrack by popping out the last choice and continue exploring.

✅ Code (JavaScript)

/**
 * @param {number[]} candidates
 * @param {number} target
 * @return {number[][]}
 */
var combinationSum = function (candidates, target) {
    let res = [];

    const dfs = (i, curr, total) => {
        if (total === target) {
            res.push([...curr]); // store valid combination
            return;
        }

        if (i >= candidates.length || total > target) {
            return; // stop exploring
        }

        // 1. Choose the current number
        curr.push(candidates[i]);
        dfs(i, curr, total + candidates[i]); // stay on i since reuse is allowed
        curr.pop(); // backtrack

        // 2. Skip the current number
        dfs(i + 1, curr, total);
    };

    dfs(0, [], 0);
    return res;
};

⏱️ Time and Space Complexity

Let’s analyze:

Time Complexity

In the worst case, each number can be chosen multiple times until we exceed the target.
The height of the recursion tree is at most target / min(candidates).
At each level, we branch into choose or skip → about 2^n style growth.
Worst-case complexity: O(2^n * t) where t is the target (because we keep adding numbers until reaching it).

In practice, it runs much faster due to pruning (total > target).

Space Complexity

O(target/min(candidates)) for the recursion depth (stack space).
Plus storage for results, which could be exponential in the number of combinations.

🚀 Key Takeaways

Backtracking is perfect when we need all possible solutions.
The trick is in branching:
- Reuse the current candidate → dfs(i, ...)
- Skip it → dfs(i+1, ...)
The stopping condition if (i >= candidates.length || total > target) prevents infinite recursion.

Forem: Rakesh Reddy Peddamallu

complete path to becoming a professional UI engineer

Phase 1 — Foundations (2–3 months)

Phase 2 — Core JavaScript Depth (1–2 months)

Phase 3 — React & Component Thinking (2–3 months)

Phase 4 — Styling Systems & Design (1–2 months)

Phase 5 — Professional Tooling & TypeScript (1–2 months)

Phase 6 — State Management & Data Fetching (1 month)

Phase 7 — Performance & Quality (1–2 months)

Phase 8 — Next.js & Production Thinking (1–2 months)

Phase 9 — Accessibility & Security (ongoing)

Phase 10 — Collaboration & Career Skills (ongoing)

Honest timeline

concepts to learn

🧠 1. JavaScript (your real foundation — React is just a layer)

Core concepts

Async mastery

Advanced JS (this is where mid-level → senior happens)

⚛️ 2. React Core (but deep, not surface level)

Rendering & lifecycle

Hooks (this is where interviews focus heavily)

Advanced patterns

⚡ 3. React Performance (high signal topic)

🏗️ 4. State Management (you need opinions here)

🌐 5. API & Data Layer

🎨 6. Browser & UI Fundamentals (people ignore this and suffer)

Browser internals

Performance basics

🧩 7. System Design (frontend version)

🧪 8. Testing (at least decent level)

🔐 9. Auth & Security (VERY underrated)

🧱 10. Architecture & Real-world Thinking

⚠️ Brutal truth (you’ll appreciate this)

🧭 Simple way to check yourself

💥 My opinion on you (based on your work)

Leetcode - 23. Merge k Sorted Lists

🧩 Problem Breakdown

💡 Approach

🛠 Step 1: Merging Two Sorted Lists

🛠 Step 2: Merging K Lists Using Divide and Conquer

📊 Complexity Analysis

Space Complexity

✅ Key Takeaways

Leetcode - 427. Construct Quad Tree

📌 Problem Statement

📖 What is a QuadTree?

🛠️ Approach

✅ Solution Code

⏱️ Complexity Analysis

Time Complexity

Space Complexity

🎯 Key Takeaways

Leetcode - 148. Sort List

🔹 Problem Statement

🔹 Approach: Divide and Conquer

🔹 Step 1: Find the Middle

🔹 Step 2: Merge Two Sorted Lists

🔹 Step 3: Recursive Merge Sort

🔹 Walkthrough Example: 4 → 2 → 1 → 3

Step 1: Initial Split

Step 2: Sort Left (4 → 2)

Step 3: Sort Right (1 → 3)

Step 4: Merge the Halves

Recursion Tree

🔹 Complexity Analysis

🔹 Why Merge Sort Works Best for Linked Lists?

✅ Final Takeaway

Backend Interview Prep Beyond LeetCode (For 3 Years Experience)

🔑 1. Core Language & Coding Skills

🌐 2. APIs & Web Fundamentals

🗄️ 3. Databases & Storage

⚡ 4. System Design (Backend-Oriented)

⚙️ 5. Infrastructure & DevOps Basics

🔒 6. Security Fundamentals

💻 7. Practical Coding Rounds

👥 8. Behavioral & Team Skills

🛠 Suggested Roadmap

✨ Final Thoughts

Frontend Interview Prep Beyond LeetCode (For 3 Years Experience)

🔑 1. Core JavaScript & Browser Fundamentals

🔹 Walkthrough Example: `4 → 2 → 1 → 3`

Step 2: Sort Left (`4 → 2`)

Step 3: Sort Right (`1 → 3`)