Commdel Software Engineer Interview Guide

The 60-second brief

Commdel is described as a company that delivers digital solutions to clients. The Software Engineer role listed for it covers building and maintaining application features, turning client requirements into technical tasks, joining code reviews and architecture discussions, and sometimes giving input on project timelines. The stack candidates mention is Java with Spring, C# and .NET with SQL Server, and Angular on the front end.

This guide is for candidates interviewing for a Software Engineer role at Commdel, most likely in Java, .NET or full-stack work. It covers the three reported stages, the eleven questions candidates report (language internals, Angular, SQL Server, OOP, live scenarios, project discussion, debugging and basic logic or school-level maths), and a plan for rehearsing them. It does not cover pay figures, because the only compensation data reported is thin and refers to a different, senior title.

Candidates report three stages over roughly 3-5 weeks: an HR Screen, one or more Technical Assessments, and Management/HR Rounds. Some reports describe the whole process moving faster, with staggered communication.

Focus areas

• HashMap internals
• Angular
• Java

Overview

The reported questions are fundamentals-first. They ask you to explain how things work inside your own stack: how a HashMap stores and finds entries, what the Java Collections framework offers, what directives are in Angular, what to expect from C# and SQL Server basics, and what the object-oriented principles mean in code. Candidates also report that a basic logic section and school-level (10th standard) mathematics show up, sometimes as an early screening filter. The preparation target is therefore mechanism, not trivia: be able to say what happens step by step.

The second half of the reported question set is about your own work: a live scenario you are asked to handle, your most interesting past project and your specific contribution, how you approach web development and database schema design, and how you debug or optimise code in production. Candidates describe these as the point where an inflated resume shows. Pick two projects you can discuss down to the library choices, the schema, and the one thing you would change.

The role description lists one major language such as Java or C#, SQL, and a modern web framework such as Angular, with cloud deployment and large-scale architecture as extras. Because the loop is not tied to one stack, work out which of your listed technologies you can defend at depth, and drop or demote the rest. Spend the most time on the HashMap, collections and OOP questions, since those apply whether your project stack is Java or .NET.

The final stage is reported as a management and HR conversation about the role, career trajectory and compensation. That calls for a different kind of preparation: a clear account of what you want next, a researched expectation you can state, and questions of your own about the role.

The Commdel interview process

Candidates describe three stages. The order and descriptions below are what candidates report, and individual loops can vary in how many technical conversations they include.

HR Screen

The first stage is an HR screen about your background and fit for the role. Candidates report it as a conversation rather than a technical test, though the 10th standard mathematics questions are described as an early screening filter in some loops. Treat it as the moment your resume has to match what you say aloud: every technology you list is fair to follow up on later.

What to demonstrate

• How your background lines up with a Software Engineer role at Commdel
• How clearly you can summarise your experience and the projects you list
• Whether your stated skills (Java, C#, SQL, Angular and so on) hold up when mentioned in conversation

How to prepare

• Write a short spoken summary of your career that ends with the stack you want to work in, and rehearse it until it is not read from a script
• For each technology on your resume, write one sentence about a task you did with it, so a quick question gets a concrete answer
• Refresh school-level maths (percentages, ratios, simple algebra, basic geometry and probability) and practise doing it by hand, in case it is used as an early filter
• Prepare two or three questions about the team and project domain to ask the recruiter

Technical Assessments

One or more technical interviews focused on hands-on competence and project discussions. Candidates report that the questions move from basic syntax and language-mechanism questions to project-based discussion, and that they are interactive: you are expected to explain how you reach an answer. The reported question set covers HashMap internals, Core Java and Collections, Angular directives, C# and SQL Server basics, OOP, live scenarios, schema design, production debugging and logic puzzles.

What to demonstrate

• Working knowledge of your main language and framework, including why a feature behaves the way it does
• Fundamentals such as linked lists and HashMaps, and relational database design and query optimisation
• Ability to explain the architecture of a past project and your own part in it
• Structured reasoning when a scenario or puzzle is unfamiliar

How to prepare

• Trace a HashMap put and get on paper (hash, bucket index, collision handling, resize) and then implement a small chained version in your own language
• Write one-paragraph answers to the Collections, OOP and Angular directives questions, each with a code example you can sketch from memory
• Build a small schema for a web feature, name the keys and indexes, and explain one slow query and how you would tune it
• Prepare two production debugging stories: one performance problem and one wrong-behaviour bug, each with what you measured and what you changed

Management/HR Rounds

Management or HR rounds that candidates describe as aligning expectations on the role, your career trajectory and compensation. Reports also suggest having project stories ready for these final conversations. Treat it as a two-way discussion: you should leave knowing what the work is and how it fits where you want to go.

What to demonstrate

• Whether your expectations about role scope and career path match what is on offer
• How you describe your project contributions to a non-technical listener
• Your approach to working with project management and the wider team

How to prepare

• Write a three-sentence answer on where you want your skills to be in a few years and how this role helps
• Research a compensation expectation from sources you trust and decide the range you will state before the conversation
• Rehearse your most interesting project as a story with a problem, your decisions, your contribution and the result, in language a manager can follow
• List what you want to confirm about the role (team, stack, how requirements reach engineers, how code review works)

Where candidates lose points

Answering the HashMap question with 'it stores key-value pairs with O(1) lookup' and stopping

Walk through the mechanism: hashCode, how the hash is spread and masked to a bucket index, collision handling, equals to confirm the key, resizing at a load factor, and the thread-safety caveat. Be ready to say what breaks when equals and hashCode disagree.

Listing Spring, Angular, .NET and SQL Server on the resume and being unable to explain the internals of any of them

Audit your resume before the HR screen. For each technology, keep only what you can explain in two layers (what it does and how it works underneath), and say plainly where your experience is lighter.

Describing your most interesting project in terms of what the team did, with no personal contribution or reasoning behind choices

Open with the problem, then name the decisions that were yours (library, schema, caching, a rollback) with the reason for each. Be ready to redraw the architecture and defend one choice you would now change.

Reaching for a fix in the live-scenario or production-debugging questions before asking what changed, what the symptom is and how it was observed

Ask clarifying questions first, then narrate a sequence: reproduce, check logs and metrics, narrow the layer (client, service, database), form one hypothesis at a time, and say how you would confirm the fix and prevent a repeat.

Treating the school-level mathematics and basic logic questions as beneath preparation, then making arithmetic slips under pressure

Spend one session on percentages, ratios, simple algebra, averages and basic probability by hand, and practise saying your steps out loud, so a slip is caught before it is stated as an answer.

Questions & practice

Internal working of a HashMap?

Medium · Technical Fundamentals and Language Prof

Approach

1. Describe the structure: a Node<K,V>[] table of buckets. put() calls key.hashCode(), spreads it with h ^ (h >>> 16), and picks the bucket with (n - 1) & hash. That works because capacity is always a power of two (default 16).
2. Walk through a collision. Entries in a bucket form a linked list, and since Java 8 new nodes go at the tail. A bucket turns into a red-black tree once it holds 8 nodes and the table has at least 64 slots; with fewer slots the map resizes instead. A tree shrinks back to a list at 6.
3. Explain resizing. When size exceeds capacity x load factor (0.75 by default), the table doubles. Each entry either keeps its index i or moves to i + oldCapacity, depending on one hash bit, so no full rehash is needed.
4. State the contract and the costs. Keys need consistent equals() and hashCode(). get and put are O(1) on average; the worst case is O(n) for a list bucket and O(log n) for a tree bucket. One null key is allowed and is stored in bucket 0.
5. Close on thread safety. HashMap is unsynchronized: concurrent puts can lose updates, and in Java 7 a concurrent resize could link a bucket into a cycle. ConcurrentHashMap is the fix.

Follow-up

• What happens if you mutate a key's fields after putting it in the map?
• How does ConcurrentHashMap in Java 8 avoid locking the whole table on a write?
• How would you build an LRU cache with LinkedHashMap?

Explain Core Java and the Collections framework.

Medium · Technical Fundamentals and Language Prof

Approach

1. Split the answer into two parts. For Core Java: JDK vs JRE vs JVM, bytecode with JIT compilation, the stack vs the heap, garbage collection, String immutability and the string pool, == vs equals(), and checked vs unchecked exceptions.
2. Lay out the Collections hierarchy. Iterable leads to Collection, which branches into List, Set and Queue/Deque. Map is a separate hierarchy. Give one implementation of each, with its ordering and null rules.
3. Compare the common pairs by cost. ArrayList has O(1) get and amortized O(1) append; OpenJDK grows it by about 1.5x. LinkedList has O(n) get and poor cache locality. HashSet (backed by a HashMap) is unordered with O(1) average operations; TreeSet (a red-black tree) is sorted with O(log n) operations; LinkedHashSet keeps insertion order. Prefer ArrayDeque over Stack.
4. Explain fail-fast iterators. Changing a collection's structure during iteration, other than through Iterator.remove(), throws ConcurrentModificationException. CopyOnWriteArrayList and the concurrent collections iterate over a snapshot or weakly consistent view instead.
5. Cover ordering and immutability. Comparable gives a natural order and Comparator an external one. Collections.unmodifiableList is a read-only view of a list that can still change underneath it. List.of is truly immutable and rejects nulls. Arrays.asList is fixed-size but its elements can still be set.

Follow-up

• When would you choose LinkedList over ArrayList, and does that case come up much in practice?
• What is the difference between HashMap, Hashtable and ConcurrentHashMap?
• Why must you override hashCode whenever you override equals?

What are directives in Angular?

Medium · Technical Fundamentals and Language Prof

Approach

1. Name the three kinds. A component is a directive with a template. Attribute directives (ngClass, ngStyle, ngModel) change how an existing element looks or behaves. Structural directives (*ngIf, *ngFor, *ngSwitchCase) add or remove DOM.
2. Explain the asterisk. *ngIf is shorthand that wraps the host element in an <ng-template>. The directive receives a TemplateRef and a ViewContainerRef and calls createEmbeddedView() or clear(). An element can carry only one structural directive, so nest an <ng-container> to combine them.
3. Write a custom attribute directive aloud: @Directive({ selector: '[appHighlight]' }) with an @Input for the colour, @HostListener('mouseenter') and ('mouseleave') to react to events, and @HostBinding or Renderer2 to change the element without touching the DOM directly.
4. Show you know current Angular. Version 17 added built-in control flow (@if, @for with a required track expression, @switch) as an alternative to *ngIf and *ngFor. Directives can be standalone, and hostDirectives (directive composition) attaches directives to a component.

Follow-up

• How does a directive differ from a pipe, and when would you write each?
• Why does *ngFor need trackBy (or @for need track), and what goes wrong without it?
• How would you write a structural directive that renders its content only for users with a given role?

Understanding of Object-Oriented Programming (OOP) principles.

Medium · Technical Fundamentals and Language Prof

Approach

1. Define the four pillars with one code example each, ideally from your own project. Encapsulation is private state behind methods that protect invariants. Abstraction is an interface that hides the implementation. Inheritance is an is-a relationship. Polymorphism is one call site running different implementations.
2. Separate the two kinds of polymorphism. Overloading is resolved at compile time from parameter types; overriding is resolved at runtime by dynamic dispatch on the object's actual type. Static methods are hidden, not overridden.
3. Show judgement on inheritance. Favour composition when the relationship is has-a or the behaviour varies independently. Cite Liskov substitution: a Square that extends Rectangle breaks callers that set width and height independently.
4. Connect to SOLID, and compare interfaces with abstract classes in Java or C#. Interfaces allow multiple inheritance of type and can have default methods. Abstract classes can hold state and constructors.

Follow-up

• How does Java resolve two interfaces that provide the same default method?
• Where in your last project did you replace inheritance with composition, and why?
• Is a class with all-public fields and getters and setters actually encapsulated?

Basic logical and analytical reasoning questions.

Medium · Logical Reasoning and Problem Solving

Approach

1. Identify the puzzle type first, because each has a standard method. For number series, check differences, second differences, ratios and alternating terms. For seating or ordering puzzles, build a grid and fix the most constrained item first. For syllogisms, draw Venn diagrams and accept only conclusions that hold in every diagram.
2. Write the constraints down instead of holding them in your head, eliminate options, and check the final answer against every constraint.
3. Practise a classic aloud: find the one heavier ball among 8 in two weighings. Weigh 3 against 3. If they balance, weigh the remaining 2. If not, take the heavier group of 3 and weigh 1 against 1; if those balance, the third ball is the heavy one.
4. Explain each step as you go. A clear elimination that ends in a small slip still shows the method, while a bare guess shows nothing. If a question stalls, move on and come back to it.

Follow-up

• How many balls can you handle in k weighings, and why?
• Can you explain why your answer is the only one that satisfies the constraints?
• How would you turn this puzzle into code?

10th standard mathematics assessments (often used as an initial screening filter).

Medium · Logical Reasoning and Problem Solving

Approach

1. Revise the usual school-level topics: percentages, ratio and proportion, profit and loss, simple and compound interest, averages, time and work, speed-distance-time, linear and quadratic equations, basic probability and mensuration.
2. Memorise the formulas that save time. Simple interest is P x R x T / 100. Compound amount is P(1 + r/n)^(nt). Two workers who finish a job in a and b days take ab/(a + b) days together. The quadratic roots are (-b ± √(b² - 4ac)) / 2a.
3. Watch the standard traps. A 20% rise followed by a 20% fall is a net 4% drop, from a + b + ab/100. Average speed over two equal distances is the harmonic mean 2xy/(x + y), not the arithmetic mean. Two dice sum to 7 with probability 6/36 = 1/6.
4. Practise mental arithmetic and estimation so you can eliminate answers quickly, and check units and plausibility before you commit. Candidates describe this assessment as an early screening filter, so rehearse a mixed set before the HR stage.

Follow-up

• A does a job in 10 days and B in 15. How long do they take together? (6 days)
• A train 200 m long passes a pole in 10 seconds. What is its speed in km/h? (72 km/h)
• What is the compound interest on 10,000 at 10% a year for 2 years, compounded annually? (2,100)

Basic questions related to C# and SQL Server.

Medium · Technical Fundamentals and Language Prof

Approach

1. For C#, cover value vs reference types (struct vs class) and the boxing cost, interface vs abstract class, const (compile-time) vs readonly (set at runtime), and using with IDisposable for connections. Note that IEnumerable runs in memory while IQueryable builds an expression that the EF provider translates to SQL. Both are deferred until enumerated.
2. For async/await, explain that a Task represents work in flight. Blocking on .Result or .Wait() can deadlock where a synchronization context exists, so go async all the way through.
3. For SQL Server indexes: a table has at most one clustered index, and its leaf level holds the data rows. Non-clustered indexes point back to the clustered key or the heap. An INCLUDE clause can make an index covering, which avoids key lookups.
4. Know the standard queries. Nth-highest salary uses DENSE_RANK() OVER (ORDER BY Salary DESC) in a CTE, filtered on the rank. Duplicates use GROUP BY ... HAVING COUNT(*) > 1. Contrast WHERE (filters rows before grouping) with HAVING (filters groups), and INNER with LEFT JOIN.
5. Cover safety and speed. Call SQL from C# through SqlCommand with SqlParameter, never string concatenation, to block injection. Keep predicates sargable: WHERE YEAR(OrderDate) = 2024 stops an index seek, but a range of OrderDate >= '2024-01-01' AND < '2025-01-01' allows it.

Follow-up

• What is the difference between DELETE, TRUNCATE and DROP, and which can be rolled back in SQL Server?
• How do ROW_NUMBER, RANK and DENSE_RANK differ when there are ties?
• What does WITH (NOLOCK) risk, and which isolation level would you use instead?

How do you approach web development tasks and database schema design?

Medium · Practical Application and Project Experi

Approach

1. Start from requirements and access patterns, not tables. List the entities and the main reads and writes, then the pages or endpoints that serve them.
2. Design the schema in steps. Give each entity a primary key, normalize to about third normal form, and use a junction table for many-to-many relations. For orders, order_items copies the unit price at purchase time instead of joining to the current product price.
3. Enforce integrity in the database with NOT NULL, UNIQUE, FOREIGN KEY and CHECK constraints. Index foreign-key columns and the columns your frequent WHERE and ORDER BY clauses use. Each index costs extra work on every write.
4. Cover the web layer: resource-oriented REST endpoints, server-side validation even when the client validates, parameterized queries or an ORM, and pagination. Keyset pagination stays fast on deep pages where a large OFFSET slows down.
5. Name where you would denormalize or cache for a read-heavy page, and how you keep the copy consistent.

Follow-up

• How would you add a column or split a table without downtime?
• What is the N+1 query problem with an ORM, and how do you fix it?
• Would you implement soft delete, and what does it do to your unique constraints?

How would you handle this specific live scenario or technical challenge?

Medium · Practical Application and Project Experi

Approach

1. Restate the scenario and ask the questions that change the answer: how many users or requests, whether data must be strongly consistent, what already exists, and what failure looks like to the user.
2. State your assumptions out loud, then give the simplest design that works, naming its parts: client, API, service logic, database, and any queue or cache, with why each one is there.
3. Walk the failure modes the scenario implies. Duplicate submissions call for an idempotency key backed by a unique constraint. Concurrent edits call for optimistic locking with a version column. A slow dependency calls for a timeout, retry with backoff, and a fallback.
4. Give the trade-off you are making (consistency vs latency, simplicity vs scale) and the metric you would watch to know it is working. If the scenario is outside your experience, reason from a nearby system you have built.

Follow-up

• What changes in your design if traffic grows tenfold?
• How would you release this change safely and roll it back if it misbehaves?
• What happens if the external service you depend on is down for an hour?

Describe your most interesting past project and your specific contribution.

Medium · Practical Application and Project Experi

Approach

1. Pick a project you can explain at code level and set it up in two sentences: who used it and what problem it solved.
2. Sketch the architecture (front end, API layer, database, integrations), then mark clearly which parts you built. Speak in the first person singular about your own work.
3. Go deep on one technical decision. Give the options you weighed (a framework, a schema shape, a caching choice), the one you picked, and why you rejected the alternative.
4. End with a result you can measure (latency, error rate, release time, user count) and one thing you would now do differently.
5. Avoid the mistake that sinks this answer: listing technologies on your resume that you cannot explain beyond their names. Rehearse a follow-up question on every layer you mention.

Follow-up

• What was the hardest bug in that project, and how did you find it?
• How was the project tested and deployed?
• If you rebuilt it today, which decision would you reverse?

Explain your process for debugging or optimizing code in a production environment.

Medium · Practical Application and Project Experi

Approach

1. Confirm and scope the symptom from data. Check the error rate, p95/p99 latency, which endpoints and which users are affected, and since when.
2. Ask what changed: a deploy, a config change, a traffic shift, data growth, or a dependency. If users are hurting, mitigate first with a rollback or feature flag, then investigate.
3. Narrow the cause with the right tool. Follow correlation IDs through the logs. For the JVM, use thread dumps (jstack), heap dumps and Java Flight Recorder. For .NET, use dotnet-trace and dotnet-dump. For SQL Server, use the actual execution plan and Query Store to find regressed queries.
4. For optimization: measure a baseline, find the real bottleneck (N+1 queries, a missing or unusable index, lock contention, excess allocation), change one thing at a time, and measure again under comparable load.
5. Close the loop: add a regression test, add an alert for the signal you lacked, and write up the cause and how it was found.

Follow-up

• Memory climbs steadily until the service restarts. How do you find the leak?
• How do you debug an issue you cannot reproduce outside production?
• How do you tell whether a slow query is slow because of its plan or because of blocking?

Suggested practice checklist

Each day targets a cluster of the reported questions and the stack candidates mention, from an audit of your resume through language internals, framework and database topics, scenarios, and a final run through all three rounds.

Day 1 — Map the loop and audit your resume

• Write out the three reported stages (HR Screen, Technical Assessments, Management/HR Rounds) and note what each asks of you
• List every technology on your resume and write one thing you built with it and one internal mechanism you can explain
• Mark the technologies you cannot defend; decide to study or remove each

Deliverable: A one-page loop map plus a resume audit table with a keep, study or remove mark against each technology.

Day 2 — HashMap internals and the Collections framework

• Trace put, get and resize on paper for a small table, including a collision and a null key
• Implement a minimal chained hash map (array of nodes, put, get, remove, resize at a load factor) in Java or your main language
• Write a comparison of HashMap, LinkedHashMap, TreeMap, ConcurrentHashMap, ArrayList and LinkedList with the deciding property for each, plus the equals and hashCode contract

Deliverable: A working hash map class, a traced example, and a one-page collections comparison.

Day 3 — OOP principles and basic data structures

• Write one short code example each for encapsulation, inheritance, polymorphism and abstraction in your main language
• Explain abstract class versus interface, composition versus inheritance and overriding versus overloading in your own words
• Implement a singly linked list with insert, delete and reverse, then add cycle detection and finding the middle node

Deliverable: A set of four OOP code examples with a short written explanation of the design distinctions, and a tested linked list file.

Day 4 — Angular directives, C# and SQL Server, and schema design

• Write a note on component, structural and attribute directives, and build one custom attribute directive
• Write the C# and SQL Server basics you would be comfortable answering: value versus reference types, joins, clustered versus non-clustered indexes, transactions
• Design a schema for a small web feature, naming primary and foreign keys, indexes and a query you would tune
• Say aloud how you approach a web development task from requirement to deployment

Deliverable: A directive example, a C# and SQL Server cheat sheet, a schema diagram with one tuned query, and a spoken outline of your web task approach.

Day 5 — Live scenarios and production debugging

• Take two scenarios (an endpoint that became slow, a bug reported only in production) and write the clarifying questions you would ask first
• Write a debugging sequence covering reproduction, logs and metrics, narrowing the layer, one hypothesis at a time, the fix and how you would confirm it
• Record yourself answering the production debugging question and listen for vague steps
• Work through the practice question on narrating an outage you owned

Deliverable: Two scenario outlines with clarifying questions, one written debugging runbook and a recording of your spoken answer.

Day 6 — Project story, logic and school-level maths

• Write your most interesting project as a story: the problem, the architecture, your own contribution, two decisions with reasons and one thing you would change
• Sketch the project architecture from memory and rehearse explaining it to a non-technical listener
• Solve a set of logic puzzles and school-level maths problems (percentages, ratios, algebra, probability) by hand, saying your steps aloud

Deliverable: A project story with an architecture sketch, and a worked sheet of logic and maths problems with your spoken reasoning notes.

Day 7 — Full run-through and the management conversation

• Answer aloud, in sequence: your career summary, a HashMap explanation, an Angular directives answer, a live scenario and your project story
• Prepare your career direction answer, your compensation expectation and your questions about the role for the final conversations
• Work through the practice questions on code review disagreement and unblocking a colleague, then list the two answers you most want to tighten

Deliverable: A recorded full run-through, a one-page note for the management conversation and a short list of answers to tighten.

Project stories and the management round

Candidates report that the HR screen covers background and fit, that the technical stage includes project discussions, and that the management and HR rounds cover role expectations, career trajectory and compensation. For this role that means project stories with your own contribution, an honest account of how you work with other developers and project managers, and a clear view of where you want to go next.

1. Describe your most interesting past project and your specific contribution.
2. How would you handle this specific live scenario or technical challenge?
3. Explain your process for debugging or optimizing code in a production environment.
4. Walk through a library, framework or schema decision you made on a project, why you chose it over the alternative, and what you would do differently now.
5. Describe a time you turned a business requirement into technical tasks and explained the plan to someone non-technical.
6. What do you want from your next role and where do you want your skills to be in a few years?

Narrate an outage you owned from page to postmortem

Hard · incident response · blast radius · postmortems

Pick an incident you personally drove, ideally one where writes were affected rather than reads. In six to eight minutes: state the symptom as it first appeared on a dashboard, the blast radius you established before you knew the cause, the mitigation you applied and when, the mechanism you eventually proved, and the follow-up that would prevent a repeat. Bring numbers: error rate, tenants affected, minutes to mitigate, minutes to resolve. If you cannot name what you measured, choose a different incident.

Approach

1. Open on the signal rather than the cause: which metric at which percentile moved, on which service, at what time, so the listener follows the same evidence you had rather than a conclusion you already reached.
2. Separate mitigation from diagnosis out loud. State what you did to stop the bleeding (flag off, shed traffic, drain a lease, roll back a deploy) and say plainly that you did it before the mechanism was known, because those are two jobs with different deadlines.
3. Establish blast radius in countable terms: how many tenants, how many writes, and crucially whether the effect was loss or only delay. An append-only revision table or a pending outbox row means the change survived and the projection was merely behind, which is a repair rather than a data-loss incident.
4. Prove the mechanism instead of asserting it. Name the trace span that grew, the plan that flipped to a sequential scan, the lease that expired, plus one alternative you ruled out and the signal that stayed flat while you ruled it out.

Follow-up

• What would you do differently in the first five minutes, given the same dashboard and no more information?
• Which follow-up action did you deliberately not take, and why was dropping it the right call?

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?

Unblock an engineer without taking the keyboard

Easy · mentoring · leases · at-least-once

A teammate has spent two days on a job handler that occasionally writes duplicate rows. They are certain the queue is delivering twice by mistake. You suspect a lease expiring under a slow handler, so the job is running concurrently with itself. Describe how you have unblocked someone in this position: what you asked before offering a hypothesis, what you showed them rather than told them, and what you left them owning. Then say what you would do if their theory turned out to be the right one.

Approach

1. Ask before diagnosing, and ask for things answerable from data they already have: the attempt count on the job rows that produced duplicates, the handler's observed duration against its lease expiry, and whether the duplicate rows share a natural key that a unique constraint could have caught.
2. Teach the shape rather than the answer. A lease cannot distinguish a dead worker from a slow one, so a handler that outruns its lease is running twice by design, and deploys deliver the other half by killing handlers mid-run on every rollout. Both of their candidate theories produce identical duplicate rows, which is why the evidence has to come from timings rather than from argument.
3. Hand over a checklist they execute: a natural key on every write the handler performs so the second copy collides rather than appends, the record of intent written before any external effect, a lease heartbeat while running, and the metric that shows it working.
4. Keep ownership with them deliberately. Pair on the first write, then step back; if you finish it yourself you have closed one ticket and left the same person stuck on the next redelivery.

Follow-up

• How would you distinguish a genuine double-delivery from a lease expiry using only the data already stored?
• Their handler calls an external endpoint before recording that it did. What do you tell them to change first?