Company-wise Interview Preparation
In short: Structure: business context → architecture → your role → tech stack → one challenge with a measurable result → process.
- Example: "I work on a loan-origination system for a European bank.
- It's an Angular frontend calling ASP.NET Core Web APIs, with SQL Server and Azure Service Bus for integration with the credit-scoring service, hosted on Azure App Service.
- I own the document-verification module and the reporting APIs.
- A key challenge was slow PDF generation timing out under load;
- I moved it to a background worker with Service Bus and blob storage, cutting API response time from 25 seconds to under 1 second.
- We work in two-week sprints with Azure DevOps pipelines and mandatory code reviews."
In short: Mention exposure to multiple clients, domains and technologies;
- structured training and certifications;
- global delivery experience;
- career paths (technical or managerial);
- and the company's specific strengths (a major client in your domain, a cloud or AI practice, a location).
- Example: "Working with global clients across banking and retail would broaden my domain knowledge.
- Your Microsoft cloud practice is strong, and your certification programmes would help me move towards solution architecture."
In short: Answer honestly with any constraints: "Yes, I'm comfortable with overlap with UK or US hours and occasional on-call support.
- I'm primarily a .NET developer but I've also worked on Angular and SSIS, and I'm open to learning what the project needs.
- I'd prefer Pune or Bengaluru, but I'm open to discussing other locations." Ask how often shifts rotate.
In short: These tests typically cover quantitative aptitude, logical reasoning, verbal ability, programming fundamentals and one or two coding problems, all under time pressure, with proctoring.
- Prepare with timed practice (aptitude books/sites, previous-year style questions), master one language for coding (input/output handling, strings, arrays), revise OOP, DBMS/SQL and OS basics, and read the official registration page for the current pattern, since sections change between years.
In short: "S: My manager wanted to ship a reporting feature by computing aggregates on every request.
- T: I believed it would overload the database at month-end.
- A: I gathered data — query costs and expected month-end traffic — and proposed pre-aggregating nightly with a fallback for today's data.
- He disagreed because of the timeline, so we agreed on a quick load test; the on-request version exceeded our latency target by 4×.
- R: We implemented my approach in 2 extra days; month-end reports stayed under 2 seconds.
- Had the test gone the other way, I'd have committed fully to his design." Show data, respect and commitment.
In short: Pick a story where you went beyond the ticket to understand the user's real problem: "Customers kept calling support about failed payments.
- Instead of just fixing the error message, I analysed 3 months of logs and found 40% of failures came from one bank's timeout.
- I added retries with idempotency keys and a clear status page for pending payments.
- Support calls on payments dropped by 60%." Quantify customer impact.
In short: "Our API had random 5-second spikes.
- Dashboards showed nothing obvious, so I collected traces and found the spikes coincided with Gen 2 garbage collections caused by large JSON payloads (over 85 KB) landing on the Large Object Heap.
- I switched to streaming serialisation and paginated the responses.
- P99 latency dropped from 5.2 s to 300 ms." Show detailed investigation and data.
In short: Clarify requirements and constraints (input size, edge cases), talk through examples, state a brute-force solution with its complexity, optimise (hash map, two pointers, sorting, BFS/DFS, DP), write clean code while explaining, test with examples and edge cases, and state time and space complexity.
- Communicate throughout — interviewers evaluate problem solving and communication, not just the final answer.
In short: Requirements: shorten URLs, redirect fast, custom aliases, expiry, analytics; read-heavy (say 100:1).
- API:
POST /urls→ short code;GET /{code}→ 301/302 redirect. - ID generation: base62 encoding of a unique ID (from a distributed ID generator or a pre-allocated range per server) to avoid collisions, or random codes with collision checks.
- Storage: key-value or SQL table (code PK → long URL, created, expiry, owner); cache hot codes in Redis; CDN/edge for redirects.
- Scale: stateless app servers behind a load balancer, DB replication/sharding by code, async analytics via a queue.
- Discuss 301 vs 302 (caching vs analytics), abuse/malware checks and rate limiting.
In short: Listen first and gather specifics (which defects, which releases, impact).
- Acknowledge and share a data-backed analysis (defect trends, root causes — requirements gaps, rushed testing, environment issues).
- Propose a concrete improvement plan: stronger acceptance criteria, automated tests and code-quality gates, a UAT checklist, release readiness reviews, and weekly quality reporting.
- Agree on measurable targets and follow up.
- Keep it professional and collaborative, never defensive.
In short: Read the requirements carefully and clarify assumptions in a README.
- Deliver a working, clean core first: a well-structured ASP.NET Core API with validation, error handling (ProblemDetails), persistence (EF Core with SQLite for easy setup), and a few meaningful tests.
- Then add polish: Docker/compose to run it, OpenAPI docs, seed data, and notes on trade-offs and what you'd do with more time (auth, pagination, CI).
- Commit in small, clear steps.
- Quality and clarity beat feature count.
In short: Give genuine reasons: Taiwan's strong technology and semiconductor ecosystem, the specific company's products, career growth, and quality of life.
- Be honest about language: "I work professionally in English and my team communication would be in English;
- I'm learning Mandarin (currently basic) and I'm comfortable working with bilingual colleagues and tools." State your work-permit or Gold Card status clearly.
- Only apply for roles whose language requirements you can meet.
In short: Agree overlap hours for synchronous meetings and rotate inconvenient slots fairly;
- use asynchronous communication well (clear written updates, design docs, recorded demos, well-written tickets);
- document decisions (ADRs, wiki);
- use follow-the-sun handovers with checklists for support;
- be explicit about time zones in deadlines;
- build relationships with video calls and occasional visits;
- and respect cultural differences in communication styles.
In short: Common base: strong project explanation, C#/.NET/SQL fundamentals, behavioural stories.
- Services company: emphasise breadth (C#, ASP.NET Core, EF, SQL, Azure basics), client communication, flexibility, and classic coding programs.
- Product company: practise DSA problems by pattern (timed), system design for your level, and values-based behavioural stories (e.g. Amazon LPs), and write code without IDE help.
- Schedule the harder one later if possible, and use one as practice for the other.
In short: Ask the recruiter politely for feedback (not always shared).
- Write down every question you were asked the same day and identify gaps.
- Create a focused plan (e.g. 4 weeks of DSA patterns or system design) and practise with mock interviews.
- Many companies allow re-applying after a cooling-off period (commonly around 6–12 months, depending on the company) — check the policy and re-apply stronger.
- Meanwhile, keep interviewing elsewhere for practice.
In short: Compare beyond the title: the actual responsibilities and level mapping (titles differ between companies — a "Senior Engineer" in one may equal "Engineer II" in another), learning opportunities, brand value for your career, team and manager, tech stack, stability, and growth path to the next level.
- Ask how levels map and what promotion timelines look like.
- Negotiate the level if your experience justifies it, with examples of scope you've handled.