Priya Sharma

Priya did her CS masters at BITS Pilani with a thesis on query optimization in PostgreSQL. Before that she shipped production web applications for five years across a Django backend, a Node.js services layer, and a React frontend that together moved real user traffic. The combination matters for tutoring. Most web-and-database assignments fail because the student understands one tier and treats the others as opaque; she works comfortably across all three and shows students the seams. 750+ CSHH assignments later, her sessions still feel like a code walkthrough from a senior teammate rather than a lecture.

Her favorite class of bug is the slow query. A student arrives with a Django view that returns the right data but takes 8 seconds. Priya opens the Django Debug Toolbar, sees 47 SQL queries fired for a single page render, and walks the student through the N+1 pattern that select_related and prefetch_related were designed to solve. The fix is usually three character changes. The lesson, that the ORM is hiding work the database actually has to do, takes longer and is the part students remember. Specific case from this semester: a CS186 project where a 14-table join was rewritten as a materialized view, dropping page render from 12 seconds to 200ms. The student kept the EXPLAIN ANALYZE output as a reference for their final.

On the JavaScript side her teaching priority is the event loop. Async control flow breaks more student code than any other single mechanism, and most curricula introduce promises and async/await without grounding either in the underlying queue model. Priya draws the call stack, the microtask queue, and the macrotask queue on the same page. Then she walks through a setTimeout(0) versus a Promise.resolve().then() example and asks the student to predict the print order. Students who get this right once usually do not write another race condition they cannot reason about. The diagram is on the whiteboard for the rest of the session.

A representative database optimization she documented for a returning student. The query was a customer-orders join in PostgreSQL filtering by date range, used to power a billing dashboard. The original plan did a sequential scan on a 4M-row orders table because the date column was wrapped in a function call inside the WHERE clause (date_trunc(order_date) BETWEEN ...), which defeated the existing btree index. The fix was to rewrite the predicate as order_date >= start AND order_date < end, which the planner could use the index for. Query time went from 4.2 seconds to 12 milliseconds. The student took the EXPLAIN ANALYZE comparison to their database course office hours and got a better grade on the final by re-explaining it.

React assignments are where students get the most surprises. The component renders, but it renders four times instead of once. Or it stops re-rendering when the parent state updates. Priya walks through the reconciler model on paper before opening the editor. Component identity, the rules of hooks, the dependency arrays that useEffect actually compares. She has a saved diagram of a setState batch and the resulting render cycle that she shares at the start of every React session; students who internalize the diagram stop fighting the framework.

Her CSHH workflow starts with the data, not the code. Whatever the brief, she pulls the schema first, runs the relevant queries by hand in psql or sqlite3 to confirm shape and cardinality, then builds the application layer on top of a verified data path. For React assignments she does the same with the component tree: sketch the prop flow on paper, identify which state lives where, then implement. A "good" student question for Priya is one that includes the schema, the failing query, and the EXPLAIN output. With those three things she can usually answer in a paragraph; without them, the first session is data archaeology.