5 Tech Interview Questions Every Sri Lankan Software Engineer Should Master

Sri Lankan tech employers — both the established service companies (Virtusa, WSO2, IFS, 99x, Calcey) and the local product startups — interview in surprisingly similar ways. The depth varies, but the question patterns repeat. Master these five, and you'll handle the bulk of any interview loop.

1. "Tell me about a time you made a technical trade-off."

This is the single most common senior-level question, and most candidates fumble it. They describe a decision but skip the trade-off part.

What interviewers actually want: evidence that you understand engineering is about constraints, not perfect answers.

Structure your answer:

1. The context (1 sentence — what were you building?)
2. The two or three real options you considered.
3. The factors you weighed (cost, deadline, team familiarity, future flexibility).
4. Your decision and why.
5. Honestly: what you'd do differently now.

A candidate saying "we picked PostgreSQL because we knew it, even though MongoDB would have been faster for this read-heavy workload — and three months later we did pay the cost in query complexity" lands much better than "we used PostgreSQL because it's reliable."

2. "Walk me through what happens when you type a URL into the browser."

The oldest question in the book, and still asked at almost every senior interview. Why? Because it tests breadth — DNS, TCP, TLS, HTTP, browser parsing, rendering. They're checking whether your knowledge has gaps a senior shouldn't have.

Hit these checkpoints, in order:

• DNS resolution (recursive resolver → root → TLD → authoritative).
• TCP three-way handshake.
• TLS handshake (and what's actually being negotiated).
• HTTP request, including headers and what cookies get attached.
• Server-side: load balancer → application server → database.
• Response: status code, headers, body.
• Browser parsing: HTML → DOM, CSS → CSSOM, JS execution, render tree, layout, paint.
• Subsequent requests for assets (CSS, JS, images).

Go deeper on whichever layer the interviewer pokes at. Bonus points for mentioning HTTP/2 multiplexing, browser caching, and CDN routing.

3. "How would you design a URL shortener?" (System Design)

The canonical "easy" system design question, included almost every loop above mid-level. Treat it like a real exercise, not a memorised script.

The framework:

1. Clarify requirements. Reads vs writes ratio? URL lifetime? Custom slugs? Analytics? Authentication?
2. Capacity estimation. "Assume 100M URLs/year, 100:1 read:write ratio, average URL is 100 bytes." Get to numbers.
3. API design. POST /shorten and GET /:code. Discuss request/response shapes.
4. Data model. Just (code, original_url, created_at, expires_at) — keep it minimal.
5. Code generation. Hash vs counter+base62. Discuss collisions and how you'd avoid them.
6. Scaling. Where do you cache (Redis for hot codes)? Where do you shard?
7. Failure modes. What if the database is slow? What if a code is requested before the write replicates?

Don't draw the entire AWS architecture in 5 minutes. The interviewer wants to see structured thinking, not box-and-arrow art.

4. "What's the difference between SQL and NoSQL, and when would you pick each?"

The trap: candidates list properties they memorised ("NoSQL is schemaless, SQL is relational, NoSQL scales horizontally") without explaining the why.

A good answer covers:

• ACID guarantees (when do you actually need them — payments, ledgers, anything financial).
• Schema evolution cost (how often does your data shape change?).
• Read/write patterns (point lookups by key vs complex joins and aggregations).
• Consistency vs availability trade-offs (CAP theorem in plain words).
• A concrete example you've worked on where one was clearly right.

For Sri Lankan banking interviews specifically: be ready to defend Postgres or Oracle for transactional systems. For startup product interviews: comfortable picking either based on the workload.

5. "Tell me about a bug you debugged that taught you something."

This is the question that separates juniors from seniors more than any leetcode problem. It tests:

• Whether you have a debugging methodology (or you just "try things").
• Whether you understand systems beyond your code.
• Whether you're honest about confusion and how you push through it.

Strong answers include:

• The symptom that the user/team noticed.
• Your hypotheses and how you ruled them out (logs, metrics, reproduction steps).
• The moment the penny dropped — and what you saw that you'd missed before.
• The fix, plus a defensive measure (test, alert, lint rule) so the same class of bug doesn't return.

Weak answer: "We had a bug, I fixed it." Strong answer: a 3-minute story with specific tools, specific surprise, and specific learning.

How to practise

• Write your answers down. You'll find half-baked thinking when it's text.
• Practise with a friend in your domain. A senior dev you trust will spot the gaps a Leetcode forum can't.
• Record yourself for system design. Most candidates speak too fast or skip steps; the recording is brutal but useful.

Most interviewers in Sri Lanka — even at the top tier — aren't trying to trick you. They want to know how you think. Show them the thinking, not just the answer.