Full feature set: authentication, notice posting, department filtering, push notifications, search, attachments, admin panel, analytics.

Walking skeleton (week 6):

• UI: a single page that displays a list of hard-coded notices.
• API: one endpoint GET /api/notices returning a JSON array (from the real database, not hard-coded).
• Database: a notices table with two rows inserted manually.
• Deployment: deployed to a live URL, with CI running on every commit.
• Authentication: skipped for now — added in week 7.

What this validates: the front-end can talk to the back-end, the back-end can talk to the database, and the deployment pipeline works. Every subsequent feature is an increment to this skeleton rather than a new integration risk.

Anti-pattern to avoid: spending six weeks building the "perfect" back-end before the front-end touches it. By the time integration happens, mismatched assumptions cause days of rework.

Subject: CSE student seeking referral for SDE Intern role — Aarav Sharma

Hi Rahul,

I'm Aarav Sharma, a third-year CSE student at [University]. I came across
your profile through the alumni network — I noticed you graduated from
the same college in 2021 and now work at [Company].

I'm applying for the SDE Intern role at [Company] (Job ID: 12345). My
background: strong in Python and JavaScript, two deployed full-stack
projects, one AWS certification, and 350+ DSA problems solved. My
portfolio: github.com/aarav.

If you're open to it, would you be willing to refer me? I've attached
my resume. If not, no problem at all — I understand you're busy.

Thank you for your time.
Regards,
Aarav

Why it works:

• States who you are and the shared context (same college).
• Names the specific role and job ID.
• Quantifies your background in one line.
• Provides a portfolio link for verification.
• Makes a specific, bounded ask (referral).
• Acknowledges the possibility of refusal gracefully.

Common mistakes: asking for a "referral" without specifying the role; sending a generic template; not providing a resume or portfolio link; asking for too much (e.g. "Can you get me a job?").

Problem: Given an array of integers and a target, return the indices of the two numbers that add up to the target. Assume exactly one solution.

Brute force approach: nested loops, checking every pair. Time complexity \(O(n^2)\), space \(O(1)\).

Optimal approach: use a hash map to record each element's index. For each element \(x\), check if \((target - x)\) has already been seen.

def two_sum(nums, target):
    seen = {}
    for i, num in enumerate(nums):
        complement = target - num
        if complement in seen:
            return [seen[complement], i]
        seen[num] = i
    return []

Complexity: Time \(O(n)\), Space \(O(n)\).

Interview discussion points: Why a hash map instead of sorting? (Sorting would be \(O(n \log n)\) and would lose the original indices.) Can we handle duplicates? (Yes — the map stores the first occurrence; the second occurrence finds it.) What if no solution exists? (Return an empty list or raise an exception, depending on the spec.)

Problem: Given a string, find the length of the longest substring without repeating characters.

Approach: sliding window with a hash map tracking the last index of each character.

def length_of_longest_substring(s):
    last_seen = {}
    left = 0
    max_length = 0
    for right, ch in enumerate(s):
        if ch in last_seen and last_seen[ch] >= left:
            left = last_seen[ch] + 1
        last_seen[ch] = right
        max_length = max(max_length, right - left + 1)
    return max_length

Trace for "abcabcbb": right=0 'a' → max=1; right=1 'b' → max=2; right=2 'c' → max=3; right=3 'a' seen at 0 ≥ left(0) → left=1; max=3; right=4 'b' seen at 1 ≥ left(1) → left=2; max=3; right=5 'c' seen at 2 ≥ left(2) → left=3; max=3; right=6 'b' seen at 4 ≥ left(3) → left=5; max=3; right=7 'b' seen at 6 ≥ left(5) → left=7; max=3. Result: 3 ("abc").

Complexity: Time \(O(n)\), Space \(O(\min(n, |\Sigma|))\) where \(|\Sigma|\) is the character set size.

Interview discussion points: Why is the condition last_seen[ch] >= left necessary? (To avoid moving the window backwards when the previous occurrence is already outside the current window.) What if the string contains Unicode characters? (Same approach works; the character set is larger.)

Problem: Given the root of a binary tree, determine whether it is a valid binary search tree.

Common wrong approach: check only that each node's value is between its immediate children. This fails for cases where a node deep in the right subtree is smaller than an ancestor higher up.

Correct approach: recursive check with bounds (min, max) that tighten as we descend.

def is_valid_bst(root):
    def validate(node, low, high):
        if not node:
            return True
        if not (low < node.val < high):
            return False
        return validate(node.left, low, node.val) and \
               validate(node.right, node.val, high)
    return validate(root, float('-inf'), float('inf'))

Complexity: Time \(O(n)\), Space \(O(h)\) for the recursion stack (h = tree height).

Alternative approach: inorder traversal — a valid BST produces a strictly increasing sequence.

Interview discussion points: Why not just compare each node to its children? (Counterexample: 5 as root, 1 as left child, 6 as right child with 4 as the left child of 6. Locally valid; globally invalid.) What if duplicates are allowed? (Change strict inequality to non-strict on one side, depending on the definition.)

Problem: Given an array of coin denominations and a target amount, return the minimum number of coins needed to make the amount. Return −1 if impossible.

Approach: bottom-up dynamic programming. Let \(dp[i]\) = minimum coins to make amount \(i\). Then \(dp[i] = \min_{c \in coins, c \le i} (dp[i - c] + 1)\).

def coin_change(coins, amount):
    dp = [float('inf')] * (amount + 1)
    dp[0] = 0
    for i in range(1, amount + 1):
        for c in coins:
            if c <= i:
                dp[i] = min(dp[i], dp[i - c] + 1)
    return dp[amount] if dp[amount] != float('inf') else -1

Trace for coins = [1, 2, 5], amount = 11: dp[0]=0; dp[1]=1; dp[2]=1; dp[3]=2; dp[4]=2; dp[5]=1; dp[6]=2; dp[7]=2; dp[8]=3; dp[9]=3; dp[10]=2; dp[11]=3. Result: 3 (5 + 5 + 1).

Complexity: Time \(O(\text{amount} \times |\text{coins}|)\), Space \(O(\text{amount})\).

Interview discussion points: Why not greedy? (Greedy fails for some coin systems, e.g. coins = [1, 3, 4], amount = 6: greedy gives 4+1+1 = 3 coins, but optimal is 3+3 = 2 coins.) How to reconstruct the actual coins used? (Maintain a separate array of choices, or backtrack through dp.)

Structure: Present → Past → Future. 90 seconds maximum.

Model answer: "I'm currently a final-year Computer Science student at [University], with a focus on backend engineering and cloud infrastructure. Over the past two years, I've built three full-stack applications — the most significant is a campus notice portal that's used by 400+ students across four departments, where I designed the backend, implemented JWT authentication and deployed it with GitHub Actions CI. I've also completed an internship at [Company] where I worked on the internal API team, learning how production systems are observed and maintained. In the future, I want to grow into a backend engineer role where I can own systems end-to-end, and eventually move into platform or infrastructure engineering."

Why this works: It follows a clear structure (present role → past experience with specifics → future direction). It quantifies achievements (400+ users, three applications). It names specific technologies and outcomes. It gives the interviewer natural entry points for follow-up questions.

What to avoid: Reciting your entire resume chronologically. Giving personal details irrelevant to the role. Sounding rehearsed without being genuine. Taking more than 90 seconds.

The trap: Either naming a fake weakness ("I work too hard") — which signals dishonesty — or revealing a weakness that is fatal for the role.

The correct formula: name a genuine weakness that is not central to the role, describe what you have done about it, and show measurable progress.

Model answer: "Earlier in my degree, I struggled with public speaking — I would avoid presenting in class even when I knew the material. I realised this would limit me in a career where engineers present to stakeholders, so I joined the college's technical club and volunteered to give tutorials. My first two were rough, but by the fifth I was comfortable. I've now presented at three club events and given a 20-minute talk on version control at a workshop. I'm still not a natural presenter, but I no longer avoid it — and I've learned that preparing thoroughly is more valuable than natural confidence."

Why this works: The weakness is genuine (not a humble-brag), specific, and non-fatal (a backend engineer who is not a natural presenter is fine). The response shows self-awareness, action, and measurable progress. The closing insight — preparation matters more than natural confidence — signals maturity.

Model answer using STAR:

• Situation: In my second year, I was the technical lead for our college's annual tech fest website. We had 3 weeks and a team of four.
• Task: I was responsible for the overall architecture and the payment gateway integration.
• Action: I underestimated the payment integration complexity and pushed it to the last week. When we tested it five days before launch, we discovered the gateway required a business account with a lengthy verification process — which we did not have. I had not read the documentation carefully enough at the start.
• Result: We had to scrap online payment and use a manual UPI system, which added administrative work and reduced the number of registrations. The site launched on time but the experience was diminished. I documented the failure in a post-mortem, and for every subsequent project I now read the integration documentation fully before committing to a deadline. I also build a "walking skeleton" of external integrations in week 1 to validate assumptions early.

Why this works: It is a genuine failure with real consequences. The candidate takes ownership ("I underestimated... I had not read the documentation"). The response ends with a concrete change in behaviour that has been applied since. This is what interviewers look for — not the failure, but the learning.

What to avoid: A failure that was not your fault ("my teammate dropped out"). A failure that is too trivial ("I forgot to reply to an email"). A failure with no learning described. Blaming others.

Recruiter: "What are your salary expectations?"

Candidate: "I'm primarily focused on finding the right role where I can learn and contribute. On compensation, I've researched that fresher SDE roles at product companies in Bangalore typically range from ₹12–18 LPA. I'd be comfortable within that range depending on the full package and the scope of the role. Could you share the budgeted range for this position?"

Why this works: It signals flexibility, provides a researched range (not a hard number), demonstrates market awareness, and politely shifts the conversation to the recruiter's budget.

If the offer is below the range:

"Thank you for the offer — I'm genuinely excited about the role. Based on my research and my two deployed projects plus the AWS certification, I was hoping for a base closer to the upper end of my range. Is there flexibility to move to X? If not, I'd like to understand how the compensation grows in the first 18 months."

1. Computational thinking is the process of formulating a problem and expressing its solution so that a computer can execute it. Four pillars: Decomposition, Pattern Recognition, Abstraction, Algorithm Design.

2. Finiteness, Definiteness, Input, Output, Effectiveness.

3. git fetch downloads remote changes but does not modify the working directory; git pull = fetch + merge and does modify the working directory.

4. CIA triad: Confidentiality (control: AES-256 encryption), Integrity (control: SHA-256 hashing with digital signatures), Availability (control: redundant servers and 3-2-1 backups).

5. Default-deny is a firewall policy where all traffic is blocked by default and only explicitly allowed traffic is permitted. It is the recommended best practice over default-allow.

6.

7.

git switch main
git pull origin main
git switch -c feature/xyz
# implement, add, commit
git fetch origin
git rebase origin/main
git push -u origin feature/xyz
# open PR, review, CI, merge
git switch main && git pull
git branch -d feature/xyz
git push origin --delete feature/xyz

8.

9.

10. Given: 192.168.20.0/24, need ≥ 12 subnets, each ≥ 10 hosts.

Bits to borrow: \(2^n \ge 12 \Rightarrow n = 4\) (16 subnets). New prefix = \(24 + 4 = 28\).

Hosts per subnet: \(h = 32 - 28 = 4\); \(2^4 - 2 = 14\) usable hosts. ✓

First three subnet ranges (block size 16):

11. SDLC phases: Requirements (SRS), Design (design document), Implementation (source code + unit tests), Testing (test plan + defect report), Deployment (release build + user manual), Maintenance (patches).

Four maintenance types: Corrective (~20%, fix defects), Adaptive (~25%, adjust to new environments), Perfective (~50%, improve performance and maintainability), Preventive (~5%, reduce future failure risk).

Why maintenance dominates: Maintenance consumes 60–70% of a system's total lifetime cost. This is because software is used for years or decades after initial delivery, during which requirements evolve, environments change, defects are found, and improvements are needed. This makes maintainability a first-class quality attribute — readable code, good documentation, and modular design all reduce long-term cost.

1. ANI (narrow AI): one specific task, no transfer — exists today. AGI (general AI): human-level reasoning across any domain — theoretical. ASI (super AI): surpasses the best human minds in every domain — hypothetical.

2. Supervised (Random Forest), Unsupervised (K-Means), Semi-supervised (self-training), Reinforcement Learning (Q-Learning / PPO).

3. VM: hardware-level virtualisation, each VM runs a full guest OS, stronger isolation, slower startup, GBs in size. Container: OS-level virtualisation, shares the host kernel, lighter isolation, millisecond startup, MBs in size.

4. A professional portfolio is a curated collection of evidence demonstrating skills, projects and achievements — a proof-of-work document. A résumé is a 1-page targeted summary designed to secure an interview. The portfolio shows; the résumé summarises.

5. Any four of: Public, Client and Employer, Product, Judgment, Management, Profession, Colleagues, Self.

6. LLM generation pipeline:

1. Tokenisation — input text is split into sub-word tokens using BPE; each token maps to an integer ID.
2. Embedding — each token ID becomes a dense vector; positional information is added.
3. Self-attention — each token computes query, key and value vectors; attention weights are computed against every other token in the context window.
4. Feed-forward and stacking — each transformer block has attention and feed-forward layers; dozens are stacked.
5. Output projection — the final hidden state is projected onto the vocabulary to produce a probability distribution over the next token.
6. Decoding — a token is sampled (greedy, top-k, nucleus, temperature) and appended; the loop repeats.

Three prompt-engineering techniques: (i) Chain-of-thought — "Solve step by step, showing all calculations." (ii) Few-shot — provide 2–5 examples of input–output pairs. (iii) Role prompting — "You are a senior security auditor reviewing this code."

7. RIASEC: Holland's model classifies people and work environments into six types (Realistic, Investigative, Artistic, Social, Enterprising, Conventional). Most individuals have a combination of 2–3 dominant types, expressed as a three-letter code.

SWOT: Strengths and Weaknesses are internal (skills, CGPA, gaps); Opportunities and Threats are external (market demand, competition).

Why self-assessment is first: Without knowing your interests, strengths and values, any goal is arbitrary — potentially someone else's goal for you. Self-assessment defines the starting point for skill-gap analysis, prevents mismatched career choices, and reveals values that determine long-term satisfaction.

8. Four dimensions of professional readiness: Technical (projects, coding, certifications), Behavioural (communication, teamwork, conflict resolution), Attitudinal (ownership, initiative, resilience), Documentary (portfolio, CV, LinkedIn, GitHub).

7 Cs of communication with examples:

• Clear — "I will send the report by Friday 5 PM" not "I'll try to get it to you soon."
• Concise — lead with the conclusion, then provide detail.
• Concrete — "Reduced load time by 40%" not "improved performance."
• Correct — proofread twice; verify technical claims.
• Coherent — use headings, numbered lists and transitions.
• Complete — anticipate follow-up questions and answer in advance.
• Courteous — acknowledge others; disagree with ideas, not people.

9. Triple constraint: Quality = f(Scope, Time, Cost). The three constraints are interdependent. Increasing scope requires increasing time or cost, or reducing quality. Example: A team is asked to add a payment gateway two weeks before launch. Since time and cost are fixed, they must either drop another feature (reduce scope) or ship the feature without adequate testing (reduce quality — unacceptable for payments). The professional response is to identify a lower-priority feature to defer.

Five project life cycle phases with deliverables: Initiation (project charter), Planning (project plan, schedule, risk register), Execution (deliverables, status reports), Monitoring and Control (performance reports, change requests), Closure (final report, lessons learned).

10. Skill-gap analysis for Cloud Security Engineer:

Total weighted gap: 10 + 10 + 15 + 8 = 43

Top three priorities:

1. Cloud (weighted gap 15) — the largest gap and highest weight; absolutely critical.
2. Linux (10) — foundational for everything else in cloud and security.
3. Networking (10) — required to understand VPCs, security groups, firewalls.

Three SMART actions:

1. Cloud: Complete the AWS Solutions Architect Associate certification and pass with ≥ 80% within 14 weeks, studying 1.5 hours daily and completing 6 hands-on labs per week (VPC, IAM, S3, EC2, RDS, Lambda). Verified by certification credential ID.
2. Linux: Complete a Linux administration course (permissions, processes, systemd, shell scripting, networking commands) and administer a Linux VM on AWS for 8 weeks, documenting configuration decisions in a GitHub repository. Verified by repository and course certificate.
3. Networking: Finish a networking course covering TCP/IP, subnetting, DNS, TLS, VPNs and firewalls, and solve 150 subnetting problems with ≥ 90% accuracy within 8 weeks. Verified by course certificate and accuracy log.

11. Applying the IEEE/ACM code to the hard-coded secrets scenario:

Recommended action: (1) do not ignore it. (2) Speak to the colleague privately and explain the risk clearly without accusation. (3) Rotate the key immediately — removing the file is not enough because it is in the Git history. (4) Help move the key to environment variables or a secrets manager; purge the key from history with git filter-repo or BFG; force-push and inform collaborators. (5) If the colleague refuses to act, escalate in writing to the security team or manager. (6) Recommend a systemic fix: pre-commit hooks or CI checks that scan for secrets, plus a .gitignore entry for .env files.

Key principle: the goal is not to punish but to eliminate the risk and prevent recurrence.

Review cadence: this plan is reviewed every six months. The specific actions change as opportunities arise; the direction remains constant unless there is a compelling reason to change it.

Walking skeleton vs prototype:

Why it reduces integration risk: Integration is the largest source of schedule risk in any project. When teams build components separately and integrate late, mismatched assumptions cause days of rework. The walking skeleton forces integration issues to surface early — in week 4 or 6 rather than week 12 — when there is still time to address them. Every subsequent feature is an increment to a working system rather than a new integration risk.

12-week capstone milestone plan with 6 gates:

If the walking skeleton gate is missed (no working end-to-end flow by week 6):

• Immediate response: Stop adding features. The team must focus entirely on achieving a working end-to-end flow. A working thin slice is more valuable than a partial thick slice.
• Investigate the blocker: Is it technical (a hard integration problem), organisational (team member unavailable), or scope-related (trying to do too much)? The response differs.
• Reduce scope aggressively: Cut the walking skeleton down to the absolute minimum — one endpoint, one table, one page. The goal is to validate the integration paths, not to demo functionality.
• Escalate to the supervisor: If the team cannot achieve the walking skeleton within 2 extra weeks, the supervisor must be informed. The project plan may need to be revised.
• Consequences of continuing without it: Integration risk accumulates. By week 10, when you finally try to wire everything together, you discover mismatched APIs, missing endpoints, configuration issues, and environment differences. The remaining weeks are consumed by integration debugging instead of feature completion.

MoSCoW prioritisation: Must-have, Should-have, Could-have, Won't-have — a method for categorising project scope by priority.

Applied to a campus event management system:

Rule of thumb: if the debt could cause a security breach, data loss, or an undiagnosable failure, it is unacceptable. If it merely slows development, it can be documented and accepted with a plan to address it.

Stages of the campus placement process and preparation:

Two-pointer technique: A technique for solving array or string problems in \(O(n)\) time by maintaining two indices that move through the data structure according to a rule. Commonly used for: sorted array sum problems, sliding window problems, and problems where one pointer moves faster than the other.

Container With Most Water:

Problem: Given an array of non-negative integers where each element represents the height of a vertical line, find two lines that together with the x-axis form a container holding the most water.

Approach: Start with pointers at both ends. The area is \(\min(h_L, h_R) \times (R - L)\). Move the pointer with the smaller height inward, because the area is limited by the shorter line — moving the taller line inward can only decrease or maintain the width without the possibility of increasing the height.

def max_area(height):
    left, right = 0, len(height) - 1
    max_water = 0
    while left < right:
        h = min(height[left], height[right])
        w = right - left
        max_water = max(max_water, h * w)
        if height[left] < height[right]:
            left += 1
        else:
            right -= 1
    return max_water

Trace for height = [1,8,6,2,5,4,8,3,7]: left=0 (h=1), right=8 (h=7): area = 1×8 = 8; left++. left=1 (h=8), right=8 (h=7): area = 7×7 = 49; right--. left=1, right=7 (h=3): area = 3×6 = 18; right--. left=1, right=6 (h=8): area = 8×5 = 40; right--. left=1, right=5 (h=4): area = 4×4 = 16; right--. left=1, right=4 (h=5): area = 5×3 = 15; right--. left=1, right=3 (h=2): area = 2×2 = 4; right--. left=1, right=2 (h=6): area = 6×1 = 6; right--. Loop ends. Result: 49.

Complexity: Time \(O(n)\), Space \(O(1)\).

Longest Common Subsequence (LCS): Given two strings, find the length of the longest subsequence common to both. A subsequence is a sequence that appears in the same relative order but not necessarily contiguously.

Recurrence relation: Let \(dp[i][j]\) be the length of the LCS of the first \(i\) characters of string A and the first \(j\) characters of string B.

\[ dp[i][j] = \begin{cases} 0 & \text{if } i=0 \text{ or } j=0 \\ dp[i-1][j-1] + 1 & \text{if } A[i-1] = B[j-1] \\ \max(dp[i-1][j],\ dp[i][j-1]) & \text{otherwise} \end{cases} \]

Base cases: \(dp[0][j] = 0\) for all \(j\) (empty string A has no common subsequence); \(dp[i][0] = 0\) for all \(i\) (empty string B has no common subsequence).

def lcs(A, B):
    m, n = len(A), len(B)
    dp = [[0] * (n + 1) for _ in range(m + 1)]
    for i in range(1, m + 1):
        for j in range(1, n + 1):
            if A[i - 1] == B[j - 1]:
                dp[i][j] = dp[i - 1][j - 1] + 1
            else:
                dp[i][j] = max(dp[i - 1][j], dp[i][j - 1])
    return dp[m][n]

Trace for A = "ABCBDAB", B = "BDCABA": the final answer is 4, corresponding to the LCS "BCBA" or "BDAB".

Complexity: Time \(O(m \times n)\), Space \(O(m \times n)\). Space can be optimised to \(O(\min(m, n))\) by keeping only two rows.

(a) Second-highest salary from Employees:

SELECT MAX(salary) AS second_highest
FROM Employees
WHERE salary < (SELECT MAX(salary) FROM Employees);

Alternative using LIMIT/OFFSET:

SELECT DISTINCT salary
FROM Employees
ORDER BY salary DESC
LIMIT 1 OFFSET 1;

(b) Departments with more than 10 employees:

SELECT department_id, COUNT(*) AS employee_count
FROM Employees
GROUP BY department_id
HAVING COUNT(*) > 10;

(c) Employees earning more than their department's average:

SELECT e.name, e.salary, e.department_id
FROM Employees e
WHERE e.salary > (
    SELECT AVG(salary)
    FROM Employees
    WHERE department_id = e.department_id
);

Alternative using a window function:

SELECT name, salary, department_id
FROM (
    SELECT name, salary, department_id,
           AVG(salary) OVER (PARTITION BY department_id) AS dept_avg
    FROM Employees
) sub
WHERE salary > dept_avg;

Why thread context switch is cheaper: When switching between processes, the OS must save and restore the full process state, including the memory management unit (MMU) state — the page tables and TLB (translation lookaside buffer). The TLB must be flushed because virtual-to-physical mappings change between processes, and the cache locality is destroyed. When switching between threads of the same process, the address space is identical, so the MMU state does not change, the TLB is preserved, and cache locality is largely retained. Only the thread-specific state (registers, program counter, stack pointer) needs to be saved and restored.

Sequence of events when a user types "https://example.com":

1. URL parsing: The browser identifies the scheme (https), hostname (example.com), and default port (443).
2. Browser cache check: The browser checks its cache for a recently resolved IP and any cached resources. If a valid entry exists and has not expired, it may skip steps 3–5.
3. DNS resolution:
   • Check OS cache and hosts file.
   • If not found, query the configured recursive DNS resolver (typically the ISP or a public resolver like 8.8.8.8).
   • The resolver queries the root server → the TLD server for .com → the authoritative nameserver for example.com.
   • The IP address is returned and cached at multiple levels with a TTL.
4. TCP three-way handshake:
   • Client sends SYN to the server's IP on port 443.
   • Server responds with SYN-ACK.
   • Client sends ACK. The connection is established.
5. TLS handshake:
   • Client sends ClientHello with supported cipher suites and a random value.
   • Server responds with ServerHello, its certificate (containing public key and CA signature), and its own random value.
   • Client validates the certificate chain against its trust store, checks the domain name, and verifies expiry.
   • Both parties perform a key exchange (typically ECDHE) to derive a shared session key.
   • All subsequent traffic is encrypted with symmetric encryption (AES-GCM).
6. HTTP request: The browser sends an encrypted GET / request with headers (Host, User-Agent, Accept, Cookies).
7. Server processing: The server routes the request, executes application logic, queries the database if needed, and constructs an HTTP response.
8. HTTP response: The server returns a status code (200), headers, and the HTML body. Static assets (CSS, JS, images) may be served from a CDN.
9. Browser rendering: The browser parses HTML, builds the DOM, fetches and executes CSS and JavaScript, and paints the page. Sub-resources may trigger additional requests.
10. Connection teardown or reuse: The connection may be kept alive for subsequent requests (HTTP keep-alive) or closed after a timeout.

Design a URL Shortener (e.g. bit.ly):

1. Requirements:

• Functional: Given a long URL, generate a short URL. When the short URL is visited, redirect to the original. Support custom aliases (optional). Provide analytics (click counts, referrers).
• Non-functional: Read-heavy (100:1 read:write). Low latency (< 100 ms). High availability. Short URLs should be unpredictable (prevent enumeration).
• Scale assumptions: 100M new URLs per day; 10B redirects per day.

2. API design:

POST /api/v1/urls
  Body: { "long_url": "https://...", "custom_alias": "optional" }
  Response: { "short_url": "https://sho.rt/abc123", "expires_at": null }

GET /{short_code}
  Response: 302 Redirect to long_url

GET /api/v1/urls/{short_code}/stats
  Response: { "clicks": 1234, "created_at": "...", "referrers": {...} }

3. Data model:

urls table:
  short_code   VARCHAR(10) PRIMARY KEY
  long_url     TEXT NOT NULL
  user_id      BIGINT
  created_at   TIMESTAMP
  expires_at   TIMESTAMP NULL

clicks table (or use a time-series store):
  short_code   VARCHAR(10)
  clicked_at   TIMESTAMP
  referrer     VARCHAR(255)
  country      VARCHAR(2)
  user_agent   TEXT

4. URL generation:

• Use a globally unique ID generator (e.g. Snowflake or a distributed counter).
• Encode the ID in base62 (0–9, a–z, A–Z) to produce a short string.
• For a 7-character base62 code, \(62^7 \approx 3.5\) trillion unique URLs.
• For custom aliases, check for collisions and reject if already taken.

5. Redirection flow:

• Client requests GET /abc123.
• The application checks a cache (Redis) for the short code.
• On cache miss, query the database.
• If found, return 302 redirect. If expired or not found, return 404.
• Asynchronously record the click in a message queue for analytics processing.

6. Scaling considerations:

• Caching: Hot URLs are cached in Redis with an LRU eviction policy. Cache hit ratio should exceed 90%.
• Database sharding: Shard by short code using consistent hashing. This spreads load and enables horizontal scaling.
• Read replicas: Since the workload is read-heavy, use read replicas to distribute the read load.
• Rate limiting: Prevent abuse of the creation endpoint (e.g. 100 URLs per user per hour).
• CDN for redirects: A geographically distributed set of edge servers can handle redirects with minimal latency.
• Asynchronous analytics: Click events go to a message queue (Kafka) and are processed by a separate analytics pipeline, decoupling the redirect path from analytics processing.

7. Analytics:

• Click events streamed to Kafka → consumed by a batch/stream processor → aggregated into a time-series database (ClickHouse, Druid) → served via an analytics API.
• Daily aggregation reduces query load.
• Geographic and referrer data enables insights for users.

Question: "Tell me about a time you had to make a difficult decision."

Model STAR response:

• Situation: In my third semester, I was the technical lead for a team of four building a college event management system. Two weeks before the deadline, we discovered that our chosen database (MongoDB) was causing performance issues — certain queries took 3–4 seconds on a dataset of 100,000 records, which would be unacceptable for the production scale of the campus fest.
• Task: As the lead, I had to decide whether to continue optimising MongoDB or to migrate to a relational database (PostgreSQL) with only two weeks remaining. Either choice carried significant risk: staying meant possible performance failures at the fest; migrating meant risking the deadline.
• Action: I gathered data before deciding. I benchmarked the three slowest queries with proper indexes in MongoDB — two improved substantially with compound indexes, but one (a multi-join aggregate) remained slow. I built a small prototype in PostgreSQL and benchmarked the same queries; they were 5–10× faster. I presented the findings to the team with three options: (a) optimise MongoDB further and accept some risk, (b) migrate to PostgreSQL and cut two lower-priority features to make time, (c) use MongoDB for most data but denormalise the problematic collection. The team discussed and chose option (b) — migrate and cut. I then planned the migration carefully: schema design in one day, data migration script in a day, and the rest of the time for re-implementing queries and testing.
• Result: We migrated successfully with 3 days to spare. Query performance improved by an order of magnitude, and the system handled the fest traffic without a single performance incident. We cut two non-essential features (event ratings and social sharing) which we documented as deferred work. The lesson I took: decisions under uncertainty are best made with evidence — building the PostgreSQL prototype took 4 hours and gave us the data we needed to decide confidently rather than guessing.

Why this works: It is a real, specific decision with genuine stakes. The candidate demonstrates structured thinking, evidence-based decision-making, collaborative leadership, and reflective learning. The response is honest about the trade-off (cutting features) rather than pretending there was a perfect solution.

Referral request email to a college alumnus:

Subject: CSE student seeking referral for SDE Intern role — Aarav Sharma

Dear Ms. Priya Nair,

I am Aarav Sharma, a third-year Computer Science student at [University].
I found your profile through the college alumni network — I noticed you
graduated from our CSE department in 2021 and currently work as a
Software Engineer at [Company].

I am applying for the SDE Intern role at [Company] (Job ID: 12345).
My background: strong in Python and JavaScript, two deployed full-stack
projects (including a campus notice portal used by 400+ students),
one AWS Cloud Practitioner certification, and 350+ DSA problems solved.
Portfolio: github.com/aarav

If you are open to it, would you be willing to refer me for this role?
I have attached my resume for your reference. If you are unable to, I
completely understand — thank you for considering it.

Thank you for your time and consideration.

Warm regards,
Aarav Sharma
+91-XXXXXXXXXX | aarav@example.com | linkedin.com/in/aarav-sharma

Justification of each element:

What to avoid: A generic template; asking without specifying the role; no resume or portfolio link; over-long messages; asking for more than a referral ("Can you get me a job?"); multiple follow-ups.

90-day plan for a new graduate joining a software team:

Overarching habits for all 90 days:

• Send a weekly summary to your manager (what you did, what you plan, what blocks you).
• Ask questions when stuck for more than 30 minutes.
• Keep a personal learning journal.
• Invest in relationships with teammates, not just the code.
• Take care of sleep, exercise and non-work activity.