SDE - Intern

Step 1 : Naive / two-pass approach (what you might try first):
Traverse the list once to compute its length len.
If N > len, return -1.
Otherwise traverse again to the (len - N + 1)-th node from the start and return its value.
This is simple and works, but it does two traversals. 

Step 2 : Optimized / expected approach (two-pointer, one pass):
Use two pointers fast and slow, both starting at head.
Move fast forward by N steps.
If during this initial move fast becomes NULL before finishing the N steps, that means N > length → return -1.
If fast becomes NULL exactly after the N steps, then N == length and the answer is head.
Now move both fast and slow forward simultaneously (one step at a time) until fast becomes NULL.
When fast reaches NULL, slow will point to the Nth node from the end.
Return slow->data.
This does a single pass and O(1) extra space (the commonly accepted “one-pass” solution). 
Example walkthrough: list 1 -> 2 -> 3 -> 4, N = 3
Move fast ahead 3 steps (after those moves fast points to 4).
Move fast and slow together once: fast → NULL, slow → 2. Return 2.

Step 1: I first represented the toll plazas and connections as a graph using an adjacency list, since the given paths form a tree and ensure a unique path between any two nodes.

Step 2: For each journey (start, end), I performed a DFS/BFS to find the path and calculated the total tax cost by summing up all the node taxes along that path.

Step 3: Then I considered the optimization rule where we can halve the tax of some non-adjacent nodes. I realized this is similar to choosing an independent set in a tree where adjacent nodes cannot both be halved.

Step 4: To solve this, I applied a Tree DP approach:
dp[u][0] → max saving if node u is not halved.
dp[u][1] → max saving if node u is halved (then children cannot be halved).
I solved it recursively to maximize the savings.

Step 5: Finally, I computed the initial total tax across all journeys, then subtracted the maximum savings obtained from the DP. This gave me the minimum possible tax sum for all journeys.

Tip 1: Stay confident and answer naturally as HR looks for honesty and personality fit, not just perfect answers.
Tip 2: Support your answers with real experiences (internship learnings, hackathon experiences, or teamwork examples).
Tip 3: For tricky questions, keep it simple and avoid jargon. For example, while explaining a project to a non-technical user, use day-to-day analogies.

Step 1: Parse each string record carefully and convert it into structured data (e.g., (stockName, quantity, value)); validate format and handle malformed entries.
Step 2: For lists 1 and 2 (the input lists to be combined), insert/update an entry for each stock in an unordered_map (or equivalent) to aggregate counts/values.
Step 3: Parse the third list (the expected/final list) into a separate map expectedMap with the same structure.
Step 4: For every stock in the aggregated map, compute the difference vs expectedMap (missing stock in expected → difference = aggregated value; stock only in expected → difference = -expected value, etc.). Build the reconciliation report entries for these differences.
Step 5: Include any stocks present only in expectedMap (not in aggregated) in the report as well.
Step 6: Return the reconciliation report in the required output format (sorted or unsorted depending on the problem statement). If the interviewer asked, also provide a human-readable summary (e.g., “AAPL: +10 units, GOOG: -5 units”), and handle rounding/precision for monetary values.
Step 7: Explain and implement optimizations when asked: use hashing for O(1) lookups, streaming parsing if lists are huge, and pay attention to memory usage.

System design / architecture

1) I clarified the scope and requirements (functional and non-functional) before drawing anything.
2) I sketched a high-level diagram showing major components (UI, backend services, databases, caches, load balancers, external integrations).
3) I explained data flow for core use-cases and identified where state is stored and how it’s accessed.
4) I described chosen technologies (frontend stack, backend framework, DB choice) and why each fit the use-case.
5) I discussed scaling strategies (horizontal scaling, stateless services, caching, sharding) and failure handling (retries, circuit breakers, monitoring).
6) I detailed deployment and CI/CD (how I built, tested, and deployed changes), and any cloud services used (e.g., storage, managed DB, container orchestration).
7) I explained design trade-offs (consistency vs availability, cost vs performance) and why I picked certain approaches.
8) I finished with possible improvements and next steps (e.g., optimizations, adding observability, cost reduction).

Implementation and technical detail questions
1) I justified data structure choices for key features (e.g., why use a trie/hashmap/heap/graph for a specific problem).
2) I described algorithms and complexity (time & space) for important modules and showed how I optimized them.
3) On follow-ups I gave code-level ideas or pseudocode for critical parts and described edge cases I’d test for.

Important corner cases & topics the manager probed (be prepared to cover these):
1) Handling high request volume and burst traffic (rate limiting, autoscaling).
2) Data consistency and how to handle eventual consistency vs strong consistency.
3) Database schema design for large-scale data, indexing, and query patterns.
4) Failure scenarios and recovery (partial failure, network partitions).
5) Security concerns (authentication, authorization, data encryption).
6) Cost trade-offs when using managed cloud services vs self-managed infra.
7) Edge cases from resume projects (unexpected inputs, latency spikes, third-party failures).

Tips for similar managerial rounds:
Tip 1: Always start by clarifying requirements and constraints.
Tip 2: Draw a clear high-level diagram first, then zoom into components the interviewer cares about.
Tip 3: Explain trade-offs explicitly, interviewers love to hear the why.
Tip 4: Use real metrics from your past projects if available (e.g., “reduced latency by X%”), it shows impact.

1) I gave concrete examples where I took ownership (define the problem, planned implementation, drove execution, measured results).
2) For conflicts, I explained a structured approach: listen, find common ground, propose data-backed solutions, and escalate only when necessary.
3) I emphasized teamwork examples from hackathons/internships where I coordinated stakeholders and delivered on time.