Azilen Technologies Software Engineer Interview Guide

The 60-second brief

Candidates describe Azilen Technologies as a company that builds software applications for business clients. The Software Engineer role covers the development lifecycle on that client work: taking part in requirement gathering, writing and commenting code, reviewing teammates' code, and tracking milestones with project managers. Candidates also describe working alongside product managers, project leaders and sometimes senior leadership, and owning assigned modules. The languages listed for the role are Java, C# and Python, with SQL and object-oriented design as the common base; the topics candidates report being tested on are OOP, Python, SQL, the .NET Framework and ASP.NET MVC.

This guide is for candidates interviewing for a Software Engineer position at Azilen Technologies. It covers the six reported questions (OOP with a coding example, production debugging, state management across frameworks, scalable and maintainable code, SQL indexing, and the self-introduction), the database-design topics candidates mention, and the HR stage. It does not assume you know which of Java, C# or Python your loop will use, so the preparation is written to transfer across them.

Candidates report a multi-stage process that opens with a screening, moves to technical assessments and ends with leadership or HR discussions, taking roughly 15 days to a month. No stage-by-stage format is reported, so confirm it with your recruiter.

Focus areas

• Object-Oriented Programming (OOP)
• Python
• SQL

Overview

The reported questions are fundamentals questions rather than puzzles. Candidates are asked to explain OOP with a real-time coding example, to describe how they would debug a complex production issue, to compare state management across the frameworks they have used, to say how they keep code scalable and maintainable, and to explain why indexes matter for SQL performance. The reported example scenario is a database schema for an e-commerce order system. Preparation therefore means being able to produce a small, correct, runnable example on demand in your own primary language, and to explain the reasoning behind each design choice.

The listed depth areas are core language concepts (memory management, multithreading, asynchronous programming), database design (normalization, indexing strategies, transaction management) and broader topics such as design patterns, microservices architecture and API security. Pick the three or four that match your own experience and prepare each to the level of a mechanism, not a definition: for example, what an index physically is and what it costs on writes, or what a race condition looks like in the language you use daily.

The role description is client project delivery: requirements, code review, milestones with project managers, and ownership of assigned modules. That makes the self-introduction and the HR stage part of the preparation, not an afterthought. Candidates are told to treat the HR round with the same care as the technical one, to be honest about tools they have not used, and to be ready to discuss recent projects, the challenges in them and what they implemented. Prepare two or three questions about team structure and development practices, and, if you know the project, read about its industry domain beforehand.

Because the stack is stated as Java, C#, Python or SQL, plus .NET Framework and ASP.NET MVC among the reported topics, decide early which language you will answer in. Use the same one for the OOP example, the state-management comparison and the schema exercise, so your examples are consistent and you are not translating on the spot.

Where to focus your preparation

The only reported structure is a loose sequence of screening, technical assessments and leadership or HR discussions; the format can vary by project, so the single entry below is a preparation block rather than a confirmed round.

Preparation focus

Candidates report a process that begins with a screening, continues with technical assessments and ends with leadership or HR discussions, and that the format shifts with project needs. No round-by-round format with durations or question assignments is reported, so treat this as a preparation block. Ask the recruiter which stages apply to your project and whether you will write code. Then prepare the three layers candidates describe: core technical concepts (OOP, your primary language, SQL), problem solving out loud, and your professional story for the HR stage. The reported technical questions cover OOP, production debugging, state management, scalable and maintainable code and SQL indexing, so work those as spoken answers with a short code or query example each.

What to demonstrate

• Command of OOP and your primary language beyond definitions, shown through a working example
• SQL fundamentals: indexing, normalization and transactions, applied to a schema such as an e-commerce order system
• Clear step-by-step reasoning about a production problem or design choice, spoken aloud
• Communication and a consistent professional narrative for the HR stage

How to prepare

• Ask the recruiter for the stage sequence, whether coding is live, and which language and project the role uses
• Write one runnable OOP example in your primary language that shows encapsulation, inheritance, polymorphism and abstraction without forcing them
• Sketch an e-commerce order schema (customers, orders, order lines, products, payments), name the indexes you would add and why, and say which queries each one serves
• Rehearse the self-introduction and one project story out loud, including a tool you know less well and how you would learn it

Where candidates lose points

Defining encapsulation, inheritance, polymorphism and abstraction as textbook sentences, with no code

Prepare one small runnable example, such as a payment or notification flow behind an interface with two implementations, and point at the exact lines where each principle shows up. Be ready to say when you would choose composition over inheritance.

Answering the production debugging question with a guess at the fix instead of a sequence

Say the order out loud: confirm the symptom and its scope, find what changed (deploy, config, data, traffic), read logs and metrics, reproduce or isolate, fix or roll back, then add a test and monitoring. State that you stabilise before you find the root cause.

Saying 'add an index' for the SQL question without explaining what it is or what it costs

Explain that an index is a sorted structure (commonly a B-tree) that lets the engine seek instead of scanning, that column order in a composite index matters, that low-selectivity columns help little, and that every index slows inserts and updates. Show it with a query plan on your order schema.

Comparing state management across frameworks you have barely used, or naming tools only to sound broad

Compare the two or three you really worked with, on the same axes: where state lives (client, server session, shared store), how it is shared between components or requests, how changes are propagated, and how you test it. Say plainly where your experience stops.

Telling the self-introduction and HR stage as a list of employers, or treating the HR stage as a formality

Build a short story of decisions and outcomes, rehearse it aloud, and prepare a project you can discuss in depth, including its challenges. Keep two or three questions ready about team structure and development practices.

Questions & practice

Canonicalise a request body into a stable idempotency fingerprint

Medium · parsing · canonicalisation · hashing

idempotency_key.request_fingerprint is a SHA-256 over the method, path and canonicalised body, and a retry whose fingerprint differs must be rejected with 422 rather than served the stored response. Write the canonicaliser. Bodies are JSON up to 256 KB nested at most 32 levels; clients vary key order, whitespace and unicode escaping, and some send 64-bit ids as JSON numbers. Produce a deterministic byte string such that semantically identical bodies match and any semantic difference does not. State your complexity and name two normalisations you refuse to perform.

Approach

1. Parse once into a tree, then re-serialise under fixed rules: object keys sorted, array order preserved, one escaping convention, no insignificant whitespace. Parsing is O(n) and sorting keys is O(k log k) per object, so O(n log n) overall with O(depth) stack, and the 32-level cap is enforced during parsing because hostile nesting is how a canonicaliser becomes a stack overflow.
2. Sort keys by their UTF-8 bytes and say why the obvious implementation is wrong in some runtimes: a default string comparison that orders by UTF-16 code units places surrogate pairs, meaning code points from U+10000 up, below U+E000 to U+FFFF, which is not UTF-8 byte order, so two services written in different languages disagree on the same document.
3. Do not re-encode numbers through a double. IEEE-754 binary64 represents integers exactly only up to 2^53, so normalising a 19-digit id through a float changes it, and 1 against 1.0 cannot be reconciled without deciding whether they are the same value. Preserve the literal token, and require ids as strings at the API boundary if you want them comparable.
4. Reject duplicate keys rather than picking one. JSON permits them and parsers disagree, most keeping the last, so any choice you make ties the fingerprint to a parser detail that the code handling the request does not necessarily share.

Follow-up

• A client sends the same logical request with an extra field your API ignores. Same key, different fingerprint, so you return 422. Is that the right answer?
• Where does the fingerprint get computed relative to request decompression and the body-size limit?

Identify the heaviest tenants in a five-minute window under memory pressure

Medium · top-k · heavy hitters · streaming

The edge service handles about 3,000 requests per second across roughly 50,000 tenants, peaking near 9,000. Expose the 50 heaviest tenants by request count over the trailing five minutes so limits can be tightened before one tenant's backfill starves the fleet. You may not retain five minutes of raw records. Give the exact solution and its memory, then the bounded-memory approximation with its error stated as a formula, and say which you would ship and at what tenant cardinality that choice changes.

Approach

1. Do the exact version first, because it is affordable at this cardinality: a ring of 300 one-second counters per tenant, advanced lazily, is 1,200 bytes of counters per tenant and roughly 60 to 90 MB for 50,000 tenants with overhead. Carry a running total and subtract the bucket you overwrite so a window read is O(1) rather than 300 adds.
2. Extract the top 50 with a size-k min-heap over the tenant sums: O(d log k) for d tenants, against O(d log d) to sort them all. Maintaining the heap continuously instead of on query requires a tenant-to-heap-index map, because incrementing a count already inside the heap means sifting from a known position, and without that map you rebuild the heap on every request.
3. State the approximation precisely rather than gesturing at sketches. Misra-Gries with m counters retains every item whose true count exceeds N/(m+1), and each retained count underestimates the truth by at most N/(m+1). With m = 1,000 and N = 900,000 requests in the window the error is roughly 900 requests, which is fine for spotting a tenant sending 50,000 and useless for ranking two tenants 200 apart.
4. Say what breaks when the window slides: Misra-Gries and Space-Saving are insert-only and cannot be decremented as records age out. The workable construction is one summary per sub-window, say ten seconds, with 30 summaries merged at query time, and the merged error is the sum of the per-summary errors, so the bound degrades linearly in the number of sub-windows.

Follow-up

• The heaviest tenant is heavy because of one export job rather than user traffic. Should the limiter treat those as the same tenant?
• Two tenants sit tied at the boundary of the top 50. Does your answer flap, and does the flapping matter?

Find overlapping job attempts and peak concurrency from lease records

Medium · sweep line · intervals · leases

A day of job_run history yields about 50,000,000 attempt records: (job_run_id, job_type, attempt, started_at, finished_at which is NULL when the worker died, lease_expires_at). Leases expire on a clock, so a job that outran its lease ran twice. Produce (a) every job_run_id whose attempts overlapped in wall-clock time and (b) the peak number of simultaneously running attempts per job_type with the minute it occurred. Target O(n log n). State how you treat a NULL finished_at and what clock skew does to your answer.

Approach

1. Define the interval before sorting anything: an attempt occupies [started_at, COALESCE(finished_at, lease_expires_at)). finished_at is observed and lease_expires_at is only a promise, so every attempt without a finish contributes an estimate and the whole result is a lower bound on overlap rather than an exact count.
2. For peak concurrency, sweep: emit 2n endpoints, sort by (timestamp, kind) with ends ordered before starts at equal timestamps, then walk the sequence maintaining a counter per job_type and record each type's maximum with its timestamp. O(n log n) dominated by the sort, O(n) space, or O(1) extra if the sort is external and the walk streams.
3. For overlap detection, do not compare attempts pairwise. A single global sort by (job_run_id, started_at) gives both the grouping and the order; within a group, keep the maximum end seen so far and report an overlap exactly when the next start is less than that running maximum, which is one linear pass after the sort.
4. Half-open intervals matter and are easy to get wrong: with closed intervals an attempt ending at the same millisecond another begins reads as concurrency two, and across 50,000,000 records that artefact swamps the real signal.

Follow-up

• A handler is not idempotent and you have found 400 overlapping jobs. Which of them actually caused damage, and what would you query to find out?
• Peak concurrency for one job_type is 4 against a configured cap of 4. Is the cap working, or is the data hiding attempts that never started?

Explain the importance of indexing in SQL for query performance optimization.

Medium · Core Technical Proficiency

Approach

1. The core mechanism: without a usable index the engine scans every row, O(n). A B-tree index lets it seek in O(log n) and then read only the matching rows. The payoff is largest for selective predicates, joins on indexed keys, and ORDER BY or GROUP BY that can follow index order.
2. Clustered vs nonclustered: a clustered index defines the order the table rows are stored in, so there is one per table. SQL Server clusters on the primary key by default, and MySQL InnoDB always clusters on the primary key. A nonclustered index stores the key plus a pointer back to the row, so a non-covering lookup costs an extra read per row.
3. Composite and covering indexes: an index on (customer_id, created_at) serves WHERE customer_id = ? ORDER BY created_at DESC, but not a filter on created_at alone (leftmost-prefix rule). Put equality columns before range columns. Adding the selected columns (INCLUDE in SQL Server and PostgreSQL 11+) makes the index covering and removes the row lookups.
4. Know what makes an index unusable: wrapping the column in a function (WHERE YEAR(order_date) = 2024; rewrite it as a date range), a leading wildcard (LIKE '%abc'), implicit type conversion, and low-selectivity columns where a scan is cheaper. Check with EXPLAIN / EXPLAIN ANALYZE or the actual execution plan.
5. State the costs: every INSERT, UPDATE and DELETE must also maintain each index, indexes use storage and can fragment, and redundant indexes slow writes for no read gain. Index for the queries that actually run, and drop unused indexes.

Follow-up

• The query has an index on the filtered column, yet the plan shows a full scan. What are the possible reasons?
• How would you order the columns in a composite index for WHERE status = ? AND created_at > ? ORDER BY created_at?
• Which indexes would you add to an e-commerce orders table, and what would they cost on writes?

Denormalise tenant onto revisions and backfill it live

Hard · denormalisation · online migration · backfill

resource_revision (revision_id, resource_id, version, actor_user_id, change_kind, patch, request_id, created_at) has 400M rows and no tenant column; tenant_id lives only on resource. Two reads need it: a tenant-scoped audit feed ordered by created_at DESC, and an offboarding purge. Both join back to resource today. Justify adding tenant_id to resource_revision against those two reads, name the anomaly the copy introduces and the constraint that prevents it, then give the ordered migration for a live table taking 1.2k writes/second — the lock each step takes, how the backfill is batched, and where each step stops being reversible. PostgreSQL 16.

Approach

1. Justify from the access path rather than from taste. Without the column, the audit feed either scans resource_revision by created_at and discards other tenants' rows, or resolves the tenant's resource_ids first and probes with them — both proportional to the tenant's whole history rather than to one page. With (tenant_id, created_at DESC, revision_id DESC) it is a seek that stops at 50 rows, and the purge becomes a ranged delete instead of a join.
2. Name the cost exactly: a second copy of a fact can disagree with the first. Make the disagreement unwritable rather than documented — add UNIQUE (resource_id, tenant_id) on resource so it can serve as a foreign-key target, then FOREIGN KEY (resource_id, tenant_id) REFERENCES resource (resource_id, tenant_id) on the revision table. A revision can then only ever carry its parent's tenant.
3. Step one, expand: ALTER TABLE resource_revision ADD COLUMN tenant_id BIGINT NULL, with no default, so it is a catalogue change and no rewrite. It still needs ACCESS EXCLUSIVE for an instant, and that instant queues behind the longest open transaction on the table while every later query queues behind it — set lock_timeout to 2s and retry rather than wait.
4. Step two, dual-write: deploy the writer that populates tenant_id on every new revision while reads still use the join. Reversible by redeploying the previous build, because nothing reads the column yet.

Follow-up

• The backfill is half finished and a rollback is required. What state is the table in, and what does the previous build do with a half-populated column?
• How do you verify the backfill actually finished, given rows are still being inserted while it runs?

How would you explain OOPS concepts with a real-time coding example?

Medium · Core Technical Proficiency

Approach

1. Use one running example instead of four separate definitions. For instance, a checkout that accepts payments: an abstract PaymentMethod (an abstract class or interface in C# or Java, abc.ABC in Python) declares process(amount), and CardPayment and UpiPayment implement it.
2. Encapsulation: keep fields such as balance or card token private and change them only through methods that validate, e.g. a withdraw() that rejects non-positive amounts or overdrafts. In Python this is by convention: _name, or __name, which name-mangles to _ClassName__name.
3. Polymorphism: checkout calls payment.process(amount) without knowing the concrete type, so dispatch is decided at runtime (overriding). Overloading is resolved at compile time in Java and C#. Python has no signature overloading: a second def with the same name replaces the first.
4. Inheritance vs composition: inherit only for a true is-a relationship that keeps the base contract (Liskov; Square extending Rectangle breaks it). Otherwise compose, e.g. inject a FraudChecker rather than subclassing for it.
5. End by tying it to open/closed: a new payment type is a new class, and checkout code does not change. That is the maintainability payoff of the design.

Follow-up

• What is the difference between an abstract class and an interface in C# or Java, and when would you pick each?
• Where in your own project did inheritance cause a problem, and how would composition have fixed it?
• How does Python get polymorphism without declared interfaces (duck typing, abc.ABC, Protocol)?

What are the primary differences between managing state in the frameworks you have used?

Medium · Core Technical Proficiency

Approach

1. Organise the answer by where the state lives and how long it lasts: one request, one redirect, a user session, or persisted. Then by scope (one component, the whole client app, the server) and by who may change it.
2. Server side in ASP.NET MVC, HTTP is stateless. ViewData/ViewBag last only for the current request. TempData survives into the next request, typically across a redirect, and is cleared once read unless you call Keep() or Peek(). Session is server-side and keyed by a cookie. Cookies, query strings and hidden fields carry state on the client. MVC has no Web Forms ViewState.
3. Name the scaling trade-off. In-process session is lost on an app restart and breaks behind a load balancer unless sessions are sticky. A distributed store (SQL Server or Redis session state) fixes that at the cost of a network hop per request. Cookies are limited to roughly 4 KB and should never hold unprotected sensitive data.
4. If you have used a front-end framework, contrast it in the same terms. React has local useState, state lifted to a common parent, Context for rarely changing shared values, and Redux for a single store updated by pure reducers via dispatched actions. Angular commonly keeps shared state in injectable services, often with RxJS.
5. Finish with a rule you follow: keep state as local as possible, keep one source of truth per piece of data, and treat server data (fetched and cached) separately from UI state. Give one bug you hit from duplicated or stale state.

Follow-up

• How would you keep users logged in when the app runs on several servers behind a load balancer?
• When would you choose Redux over React Context, or a service over component state?
• What is the difference between TempData and ViewBag, and why does TempData sometimes disappear?

How do you ensure your code is both scalable and maintainable?

Medium · Core Technical Proficiency

Approach

1. Separate the two goals. Maintainable means the next developer can change it safely. Scalable means it keeps working as load or data grows. Give practices for each, not a list of buzzwords.
2. Maintainability: small classes with one responsibility, depending on interfaces and injected through DI (built into ASP.NET Core; constructor injection in Java or Python). Add unit tests around business rules plus integration tests at the database and API edges, consistent naming and linting, CI that runs the tests, and code review.
3. Scalability: keep application servers stateless so they scale horizontally, and push state to the database or a cache. Remove N+1 queries (eager loading via Include in Entity Framework, selectinload/joinedload in SQLAlchemy). Index the filter and join columns, paginate large results, use async I/O for network calls, and move slow work onto a queue.
4. Measure before optimising: profile, read query plans and load-test to find the actual bottleneck. Name the trade-off you accept. A cache adds invalidation and staleness, and extra abstraction layers cost readability.
5. Back it with one concrete example from your own work, such as a slow report fixed by an index plus pagination, or a growing module split behind an interface. Say what you measured before and after.

Follow-up

• How would you find the bottleneck if an endpoint slowed down after the data grew tenfold?
• What is an N+1 query, and how do you spot and fix one in the ORM you use?
• Tell me about a refactor you made for maintainability. How did you keep it from breaking behaviour?

Can you walk me through your approach to debugging a complex issue in a production environment?

Medium · Core Technical Proficiency

Approach

1. Contain it first. Measure the scope (which users, endpoints, error rate) and mitigate before root-causing: roll back, turn off a feature flag, or scale out. Then build a timeline of what changed: deploys, config, schema migrations, data volume, traffic, upstream dependencies.
2. Gather evidence before theorising. Pull logs by correlation or request ID, error-rate and latency metrics, and traces to see which hop is slow or failing. Sanity-check the dashboards themselves: a missing metric can look like an outage.
3. Reproduce it outside production with production-shaped inputs (the failing payload, a copy of the relevant data, the same config). If it will not reproduce, add targeted, sampled logging around the suspect path. Never pause a live process with a breakpoint or log personal data.
4. Narrow it down by bisection: compare the last good and first bad versions (git bisect), toggle flags, or route traffic to one instance. Test one hypothesis at a time. Typical production-only causes are race conditions, connection-pool exhaustion, timeouts, memory leaks (look at heap dumps and GC logs) and data the tests never had.
5. Fix it with a regression test that fails before the fix, deploy, and confirm the metric recovers. Then write a short blameless post-incident note covering the root cause, why it was not caught, and the alert or test that will catch it next time.

Follow-up

• The bug occurs only in production and never in staging. What differences would you check first?
• How would you find a memory leak in a running .NET, Java or Python service?
• How would you show that your fix, and not a coincidental traffic drop, resolved the issue?

Suggested practice checklist

The seven days run from confirming the format, through the reported OOP, debugging, state, scalability and SQL questions, to the self-introduction and a full mock.

Day 1 — Pin down the format and your language

• Email the recruiter to ask which stages apply to your project, whether you will write code, and which of Java, C# or Python the team uses.
• Write a one-page inventory of your stack (language, SQL, any .NET Framework or ASP.NET MVC experience) marking each item as strong, working or weak.
• Choose the single language you will use for every example this week.

Deliverable: A recruiter reply (or a list of open questions) and a one-page stack inventory with your chosen language.

Day 2 — OOP with a real-time coding example

• Write a runnable example (for instance an order payment flow with an interface, two implementations and an abstract base) that shows all four OOP principles.
• Add short notes on when you would use composition instead of inheritance and what the SOLID principles change in the example.
• Say the explanation aloud twice, pointing at specific lines of your code.

Deliverable: A runnable OOP example plus a spoken explanation recorded once and checked for gaps.

Day 3 — Production debugging and state management

• Write the debugging sequence as a numbered runbook (scope, recent changes, logs and metrics, isolate, stabilise, fix, prevent) and apply it to a real incident from your past.
• Make a comparison table of how state is managed in two frameworks you have used: where state lives, how it is shared, how it changes, how you test it.
• Answer both questions aloud, then list what you could not explain well.

Deliverable: A one-page incident runbook, a two-framework state table and a list of weak points.

Day 4 — SQL indexing and the order schema

• Design the e-commerce order schema in third normal form and write the three queries it must serve fastest.
• Create the schema in a local database, load sample rows, and compare query plans with and without your indexes, noting the write cost.

Deliverable: A schema with indexes, before and after query plans, and a short spoken answer on why indexing matters.

Day 5 — Scalable and maintainable code

• Take one module you wrote and list what makes it maintainable (naming, tests, separation of concerns, review) and what would stop it scaling (shared state, blocking calls, unbounded queries).
• Rework one function from it to remove a concrete weakness, and be ready to explain the trade-off.

Deliverable: A before and after code change with a written trade-off, and two practice coding solutions explained aloud.

Day 6 — Self-introduction and HR preparation

• Write and rehearse the answer to 'Tell me about yourself and your professional journey thus far', then cut it to the decisions and outcomes.
• Prepare one project story you can discuss in depth, including its challenges and a tool you had to learn quickly.
• Write two or three questions about team structure and development practices.

Deliverable: A rehearsed self-introduction, one project story and a list of questions to ask.

Day 7 — Full mock

• Run a mock in which you answer the OOP, debugging, state, scalability, SQL and self-introduction questions aloud in one sitting.
• Review the recording for jargon without explanation, missing edge cases and unsupported claims.
• Fix the two weakest answers and run them again.

Deliverable: A completed mock, a list of the weakest answers, and their rewritten versions.

Self-introduction and HR preparation

The reported behavioral question is the self-introduction, and candidates are told to prepare for the HR round as carefully as the technical ones. For a delivery-focused Software Engineer role, that means a clear professional story, honesty about what you do and do not know, and examples of working with reviewers and project managers.

1. Describe a recent project, the hardest problem in it, and what you implemented.
2. Tell me about a tool or technology you did not know and how you got productive with it.
3. Describe a time you disagreed with a reviewer or a project manager and how it was resolved.
4. How do you explain a technical problem to someone who is not an engineer?

Tell me about yourself and your professional journey thus far.

Medium · Behavioral and Cultural Fit

Approach

1. Treat it as a short pitch, not a CV recital: current role and main stack first (for this role, whichever of Java, C#, Python and SQL you actually use), then the two or three steps that got you there, then why this role. Keep each step to a decision you made, not a job title.
2. Pick one project and give its shape: the problem, the module you owned, one concrete technical decision (a schema change, a bottleneck you found, a review habit) and the result. Use a number only if you can defend it, and separate what you did from what the team did.
3. Cover the delivery side that the role description stresses: requirements you helped clarify, code you reviewed or had reviewed, and how you reported progress to a project manager. One sentence each is enough.
4. Be honest about edges. Mention a tool or area you are still growing in and what you are doing about it; this is more useful than a flat list of technologies you cannot discuss in depth.
5. The mistake that sinks it is a chronological list of employers and keywords with no decision, outcome or personal share. Everything you say will be a thread someone can pull, so only say what you can explain.

Follow-up

• Which project on your CV was most yours, and what would you change if you ran it again?
• You listed a technology you used only briefly; how deep does your knowledge go, and how would you close the gap?
• Tell me about a time you disagreed with a reviewer or project manager and how it was resolved.

Argue against a design, lose, and commit anyway

Medium · disagreement · service boundaries · decision records

Describe a design you argued against and lost. State the failure you predicted as a named mechanism, not a feeling about complexity: two services that would need one transaction, a projection with no rebuild path, a write path with no idempotency key. Say what evidence you brought, what the decision maker weighed instead, and what you did after the decision was made: what you instrumented, what you wrote down, and whether the prediction came true. Five minutes.

Approach

1. State the prediction in falsifiable form up front: the mechanism, the condition that triggers it, and the observable outcome. A prediction that cannot be checked also cannot be credited to you later.
2. Show the evidence you had at the time and label each piece honestly as measured, analogous, or intuition. Keeping the intuition is fine; disguising it as data is the thing that erodes your standing in the next argument.
3. Represent the opposing case at full strength, including the constraint you did not control: a fixed date, a team boundary, or the fact that the decision was cheap to reverse and yours was not.
4. Make disagree-and-commit concrete. Name the artefact you left behind so the prediction could be settled without you: the alert and its threshold, the counter on the dashboard, the decision note that recorded the trade-off and the condition that would revisit it.

Follow-up

• What threshold on that alert would have proved you right, and did anyone ever look at it?
• If the same proposal arrived tomorrow with the same deadline, would you argue it the same way?

Turn a code review disagreement into a decision

Easy · code review · optimistic concurrency · communication

A colleague's change updates a row with UPDATE resource SET version = version + 1 WHERE resource_id = $1 AND version = $2 and treats an affected-row count of zero as a successful no-op. You read that as a silently lost update; they think returning 200 is friendlier to clients than returning a conflict. Describe how you have handled a review disagreement of this shape: what goes in the comment, when you leave the thread, and who decides. Then write the comment you would leave here, in under 80 words.

Approach

1. Sort the disagreement before writing anything. A silently discarded write is a correctness claim about data; the choice between 409 and 412 is taste. Only the first justifies blocking a merge, and saying which one you are doing is most of the value of the comment.
2. Make the claim reproducible in the comment itself with an interleaving rather than a principle: A reads version 7, B reads version 7, B commits version 8, A's predicate matches zero rows, A is told it succeeded and A's edit is gone.
3. Offer the alternative with its cost attached: return 409 carrying the current version and the revision that won, so the client can re-read and re-apply. Note that automatic retry is not the fix, because a retry re-reads the winner's state and reapplies an intent formed against data that no longer exists.
4. Apply an escalation rule you can state: two round trips on the thread, then a call, and the service's owner decides rather than the reviewer. A reviewer who cannot be overruled is a bottleneck with extra steps.

Follow-up

• Where would you put the test that fails if someone reintroduces the swallowed zero rowcount?
• The author says clients cannot handle a 409. How do you check whether that is true?