DEV Community: Sarthak Agrawal

Ship one complete product to learn application engineering

Sarthak Agrawal — Wed, 30 Sep 2026 04:30:00 +0000

Application engineering is often taught as separate lists for backend, frontend, UX, analytics, and distribution. A product forces those lists to meet.

The 12-week Application Engineering roadmap uses one complete product as the synthesis. The first four weeks cover the request and data path: HTTP, queues, authentication, object modeling, state management, web security, pagination, API design, client engineering, and interface design.

Those topics become useful when they share a contract. An authenticated action needs a UI state, an API boundary, authorization, a data model, an error path, and a way to retry safely. Pagination affects the API and the interface. A queue changes when the user can expect a result.

The middle phase adds real-time messaging and interactive systems. The learner has to decide which state is authoritative, how clients reconnect, which updates can be dropped, and how the interface explains delay or conflict. A live feature is not complete when two browser windows happen to update once.

The final phase covers product analytics, positioning, landing pages, and on-page SEO. This is not a marketing appendix. Analytics checks whether the workflow is used. Positioning explains who the product is for. The landing page and search surface make the product understandable before sign-in.

The synthesis artifact should be a working product with an end-to-end guest or user journey, measured behavior, and a clear release boundary. That makes the learning legible. Instead of claiming familiarity with a stack, the learner can show how a real requirement moved through interface, API, storage, operations, and distribution.

The complete roadmap is at https://learn.significanthobbies.com/curriculum/roadmaps/application-engineering-12w.

Systems foundations should start below the framework

Sarthak Agrawal — Tue, 29 Sep 2026 04:30:00 +0000

Framework knowledge helps you ship. Systems knowledge helps when the framework becomes slow, unsafe, or surprising.

The 12-week Systems Foundations roadmap starts below application code. Data representation, program memory, the compute and storage hierarchy, and operating-system mechanics form the first phase. These topics explain why a value has a size, why an allocation moves, why a cache miss matters, and what the kernel does for a process.

The middle phase connects those mechanics through network protocols and concurrency. A request now crosses buffers, scheduling points, synchronization boundaries, and failure states. The learner has to discuss the production tradeoffs: latency, throughput, contention, cancellation, backpressure, and resource limits.

The final phase adds runtime performance and security isolation. Performance work begins with a reproducible workload and a profile. Isolation work begins by naming the trust boundary and the resources that cross it. Both need evidence because both invite confident guesses.

The synthesis artifact asks the learner to connect the layers. A useful artifact might trace one request or workload from representation through memory, runtime, network, and isolation, then identify and measure one bottleneck or risk. The exact implementation matters less than whether the causal path is clear.

This is a good antidote to tool-first learning. A container, event loop, database driver, or runtime is easier to reason about when you can explain the mechanisms it packages. The goal is not to avoid abstractions. It is to know when an abstraction is leaking and what evidence to collect next.

The complete roadmap is at https://learn.significanthobbies.com/curriculum/roadmaps/systems-foundations-12w.

Learn DSA by invariants, not solution memory

Sarthak Agrawal — Mon, 28 Sep 2026 04:30:00 +0000

Recognizing a problem from a screenshot is not the same as recognizing its structure. Interview practice becomes more durable when every solution has an invariant you can explain.

The 30-day DSA Practice roadmap starts with arrays and strings, then moves through linear structures, trees and heaps, search and greedy methods, graphs, dynamic programming, and bit manipulation. The order is familiar. The rule for completing a problem is more important: solve it without a reference, explain the invariant, and add one edge-case test.

For a sliding window, the invariant might describe what the current window contains and when the left boundary can move. For binary search, it states where the answer can still exist. For a heap, it explains which candidates have been retained and why. For dynamic programming, it defines the subproblem before writing the recurrence.

The extra edge-case test forces that explanation to meet code. Empty input, duplicate values, disconnected graphs, overflow, or a one-element boundary often exposes a remembered template that was applied without understanding.

Complexity analysis belongs in the same loop. State what each pointer, queue entry, recursive call, or table cell can do. Then derive time and space from those operations. This is more reliable than attaching a memorized Big O label at the end.

Pattern practice still matters, but the pattern is a prompt for reasoning. The goal after 30 days is not a large solved count. It is being able to identify the shape, choose a defensible approach, implement it cleanly, and repair it when the first test breaks the assumption.

The complete roadmap is at https://learn.significanthobbies.com/curriculum/roadmaps/dsa-practice.

Practice system design under a 45-minute clock

Sarthak Agrawal — Sun, 27 Sep 2026 04:30:00 +0000

System design practice can become a collection of memorized diagrams. A better target is a repeatable decision process that still works when the prompt changes.

The 30-day HLD Practice roadmap begins with requirements and capacity, then covers load balancing, consistent hashing, consensus, storage, queues, caching, and rate limiting. These are not boxes to include by default. They are tools whose value depends on scale, failure behavior, and the contract the system must keep.

The first week isolates primitives. Designing a load balancer, hash ring, or leader election mechanism in a small exercise makes its assumptions visible. The second week connects distributed components behind the request path. Queue boundaries, storage choices, and real-time messaging now have to work together.

The second half uses full cases: news feed, video streaming, ride sharing, collaborative editing, search, and RAG. A 45-minute answer needs an order. Start by classifying functional and non-functional requirements. Estimate the dominant read, write, storage, and bandwidth dimensions. Choose an initial data model and request path. Then find the bottleneck or failure mode that justifies the next component.

The useful practice happens in the explanations between boxes. Why is this write asynchronous? Which operation needs strong consistency? What becomes stale? Where can an idempotency key stop a duplicate? What metric tells the operator that the design is failing?

A credible interview design is not the one with the most infrastructure. It is the smallest design that meets the stated load and explains how it degrades.

The complete roadmap is at https://learn.significanthobbies.com/curriculum/roadmaps/hld-practice.

Build hybrid search with a frozen query set

Sarthak Agrawal — Sat, 26 Sep 2026 04:30:00 +0000

Hybrid search is easy to describe: combine lexical and vector retrieval. Proving that the combination is better takes a more careful sequence.

The 30-Day Retrieval Basics roadmap starts with lexical search. The learner builds a tokenizer, inverted index, and BM25 ranker before reaching embeddings. That order matters. Lexical retrieval gives exact terms, inspectable scores, and a strong baseline that is cheap to run.

Week two freezes the query set and builds an evaluation harness. Ranking metrics now have concrete inputs: queries, relevance judgments, result lists, and a cutoff. Changing the retriever without keeping this set stable would make the comparison harder to trust.

Week three adds vector retrieval. A brute-force index keeps the first implementation readable. The learner can inspect similarity, top-k behavior, and metadata filters before approximate nearest-neighbor structures introduce another quality and latency tradeoff.

The final week combines the two result lists and adds reranking. Reciprocal Rank Fusion is useful here because it can merge rankings without pretending the scores from BM25 and vector similarity share one scale. The capstone must show whether the hybrid path improves the frozen queries and where it makes them worse.

This workflow resists a common search mistake: adding embeddings before defining the failures they are meant to fix. Some queries need semantic recall. Others depend on an exact identifier, name, or phrase. A hybrid system earns its complexity when the evaluation shows that each retriever covers a real weakness in the other.

The complete roadmap is at https://learn.significanthobbies.com/curriculum/roadmaps/retrieval-30-day.

Developer tools need repository context and safe remediation

Sarthak Agrawal — Fri, 25 Sep 2026 04:30:00 +0000

A useful developer tool has to understand more than the file currently open. The risk of a change often lives in imports, tests, generated artifacts, build rules, ownership, and runtime behavior elsewhere in the repository.

The 12-week Developer Tools and Code Intelligence roadmap starts with code review, static and dynamic analysis, and testing infrastructure. These are different evidence sources. Static analysis can trace syntax and data flow without running the program. Dynamic analysis observes an execution. Tests encode selected contracts. None is complete alone.

The middle phase builds repository context. Codebase graphs expose relationships. Blast-radius analysis asks what depends on a symbol or package. Repository intelligence brings in structure, instructions, history, and conventions. IDE and CLI tooling turn that context into an interaction that fits actual work.

The final phase adds coding-agent systems, software supply-chain health, and automated debugging or remediation. This is where safety becomes part of product design. A tool that proposes a dependency change should show why it is needed, which manifests it will touch, what compatibility evidence exists, and how the result will be checked. A debugging agent should separate a hypothesis from the command or observation that supports it.

The synthesis artifact is a repository-aware tool, not a generic code chatbot. Its value should be measurable through findings, false positives, time saved, accepted remediations, or a repeatable benchmark. Its limits should be visible too.

Good developer tools reduce the distance between a question and trustworthy evidence. Automation helps only when the evidence survives the convenience.

The complete roadmap is at https://learn.significanthobbies.com/curriculum/roadmaps/developer-tools-12w.

Study distributed systems through failure, not diagrams

Sarthak Agrawal — Thu, 24 Sep 2026 04:30:00 +0000

A clean architecture diagram is drawn after the network has behaved. Distributed systems become interesting when a request is retried, a replica lags, a partition appears, or a workflow resumes after a crash.

The 12-week Distributed Systems roadmap begins with the mechanisms that shape those failures. HTTP lifecycle, idempotency, load balancing, consistent hashing, retries, consensus, replication, sharding, and the CAP tradeoff form the first four weeks.

Each mechanism has a practical question attached. What makes a retry safe? Which key should choose a shard? What does a stale read look like to the caller? When does jitter prevent a recovery storm? These questions turn vocabulary into behavior.

The middle phase moves into queues, event streams, caching, and real-time messaging. The focus is on production boundaries: backpressure, ordering, cache stampedes, delivery guarantees, and the point where a synchronous request should become durable work.

The final four weeks cover distributed infrastructure, durable workflows, and failure recovery. The synthesis artifact asks the learner to test failures and explain recovery, not only present a happy-path design. A credible result names the state owner, retry policy, idempotency boundary, visibility into partial progress, and terminal failure state.

This is also a better interview habit. When a design includes a queue or replicated store, the next sentence should describe what happens when it is delayed, duplicated, stale, or unavailable. The failure path often reveals whether the component belongs in the design at all.

The complete roadmap is at https://learn.significanthobbies.com/curriculum/roadmaps/distributed-systems-12w.

Learn LLM serving as a memory and scheduling problem

Sarthak Agrawal — Wed, 23 Sep 2026 04:30:00 +0000

A language model server is not only a model behind an HTTP endpoint. Its behavior depends on memory layout, token scheduling, kernels, routing, hardware, and the economics of each request.

The 12-week Inference and Serving roadmap begins with the model mechanics required to reason about that system. Tokenization, attention, transformer blocks, sampling, checkpoints, LoRA, quantization, and structured output establish what the engine must execute and preserve.

The path then turns those operations into serving mechanisms. Inference engines organize execution. KV caches retain state between generated tokens. Paged attention changes how that state is managed. Continuous batching mixes work from different requests. Model routing chooses a path based on cost or capability rather than sending every query to the same model.

Weeks five through eight move closer to the hardware. Flash Attention, speculative decoding, GPU utilization, and inference hardware are treated as tradeoffs, not isolated tricks. A faster kernel can still lose at the system level if it increases memory pressure, complicates batching, or only helps a shape the service rarely sees.

The final phase connects cost and latency with local inference, browser runtimes, and WebGPU. The synthesis requires measurement across the path. Useful evidence includes the workload, model and precision, batch behavior, memory use, latency distribution, throughput, and the quality boundary that the optimization must keep.

This perspective changes the learning question. Instead of asking which serving framework is fastest, ask which resource is limiting the workload and which scheduling or representation change addresses that limit.

The complete roadmap is at https://learn.significanthobbies.com/curriculum/roadmaps/inference-serving-12w.

Build agent systems from bounded loops outward

Sarthak Agrawal — Tue, 22 Sep 2026 04:30:00 +0000

Many agent demos begin with a model, a tool list, and a loop. Production problems begin as soon as the loop has authority, state, and time.

The 12-week Agent Systems roadmap starts with the small mechanics: structured output, tool calling, bounded agent loops, memory, and MCP integrations. The step-limit exercise is deliberately basic. A loop that cannot explain when it stops is not ready for more tools.

The next phase introduces coordination, explicit communication interfaces, and browser or computer use. These topics are grouped because coordination is not just adding more agents. Each participant needs a contract for messages, ownership, failure, and handoff. Computer use raises the cost of ambiguity because the tool can act on a real interface with state the model may not fully observe.

The final four weeks focus on durability and control. Long-running work needs persisted state, resumable execution, scheduled triggers, permission boundaries, and safe recovery after partial failure. A sandbox limits what an agent can touch. Durable execution limits what a crash can erase. Both are part of correctness.

The synthesis artifact asks the learner to combine these pieces into one system and test its failure modes. A useful result should show what the agent can do, which actions require authority, where state lives, how retries behave, and how an operator can stop or inspect the run.

Starting with bounded loops keeps the design honest. Autonomy is not the number of iterations a model can run. It is the amount of useful work the system can complete while its scope, state, and failure behavior remain legible.

The roadmap is at https://learn.significanthobbies.com/curriculum/roadmaps/agent-systems-12w.

Build AI evaluations that survive a model change

Sarthak Agrawal — Mon, 21 Sep 2026 04:30:00 +0000

An AI evaluation is easy to trust when it confirms the release you already want. The harder test is whether it still helps after the prompt, model, tool, or traffic mix changes.

The 12-week Evaluation and AI Reliability roadmap begins below the evaluation layer. It covers enough model mechanics, probability, and descriptive statistics to explain what a metric measures and what it misses. It then moves into LLM evaluations, coding-agent benchmarks, and tool-use evaluations.

That foundation matters because different tasks fail differently. Exact match may fit a constrained output. A tool-using agent needs checks for action selection, arguments, side effects, recovery, and final evidence. A coding benchmark can reward a patch that passes a narrow test while missing the requested behavior.

The middle four weeks move from a local score to a production evaluation system. Prompt versions are explicit. Regression tests use frozen cases. Hallucination and failure detection become named behaviors. Quality, cost, and latency are measured together, because a release that improves one dimension can quietly damage another.

The final phase adds agent observability, tracing and replay, evidence-backed verification, and human review. The synthesis artifact is not a leaderboard. It is an evaluation and observability system that can reproduce a failure, compare a candidate with a baseline, and show where human judgment still enters.

A useful evaluation should make a bad release harder to justify. It should also make a good release easier to explain without stretching one number into a general claim.

The complete roadmap is at https://learn.significanthobbies.com/curriculum/roadmaps/ai-reliability-12w.

A coding agent needs a harness, not a longer prompt

Sarthak Agrawal — Sun, 20 Sep 2026 04:30:00 +0000

A coding agent can produce a plausible patch with a good prompt. Reliable progress across a real repository needs more than prompt quality.

The Harness Engineering roadmap treats the environment around the agent as a system. The first build turns implicit expectations into scoped repository instructions and executable checks. The second makes the workspace readable from a fresh checkout: structure, setup, readiness, and permissions should be discoverable without private history.

Continuity arrives in the third build. A later session needs the goal, current progress, evidence, blockers, and next action. Without that durable state, long-running work becomes a series of confident restarts.

The fourth build adds scope control and runtime feedback. The agent needs a bounded authority surface and evidence that tells it whether to continue, replan, complete, or escalate. This is where a harness starts to look less like a prompt wrapper and more like an operating system for work.

The fifth build separates maker and checker. The checker reconstructs the contract and gathers fresh evidence instead of accepting the maker's claim that the task is done. The final two builds connect initialization, execution, recovery, verification, and terminal states, then compare the automated loop with a baseline and remove one component to see whether it mattered.

This sequence makes one distinction clear: agent capability and agent reliability are different properties. A strong model can still fail in an unreadable workspace, lose state between sessions, exceed its scope, or verify its own assumptions.

The seven-build roadmap is at https://learn.significanthobbies.com/curriculum/roadmaps/harness-engineering.

Trace one tensor from model math to serving cost

Sarthak Agrawal — Sat, 19 Sep 2026 04:30:00 +0000

AI systems material often splits into separate subjects: model math, GPU kernels, runtimes, and production serving. That makes each topic easier to name and harder to connect.

Trace a Tensor uses one workload as the thread. The first week starts with data representation and backpropagation. The point is to explain what a tensor contains, how its shape affects a computation, and what work a forward pass creates for the backward pass.

The second week follows the same data through the compute, memory, and storage hierarchy. Before changing a kernel, the learner has to profile the runtime and identify where time or bandwidth is actually going. That prevents an interesting optimization from becoming a substitute for diagnosis.

The third week changes the work. Flash Attention and quantization are studied as different ways to reduce movement or numerical cost. Both come with a quality or correctness boundary, so the exercise is not complete when the faster path runs. It must preserve the behavior the system needs.

The final week moves into engines, continuous batching, and serving economics. Latency, throughput, utilization, quality, and cost now sit in the same decision. The capstone asks for a reproducible workload or performance model, a measured bottleneck, a before-and-after comparison, and a defended optimization.

That shape is more useful than memorizing a stack diagram. It gives every abstraction a place in one causal chain: values become tensors, tensors create work, the machine schedules that work, and the serving system pays for the result.

The complete roadmap is at https://learn.significanthobbies.com/curriculum/roadmaps/trace-a-tensor.