ISHIR Software Engineer Interview Guide

The 60-second brief

A Software Engineer at ISHIR plays a pivotal role in designing, developing, and deploying high-impact software solutions for a diverse global client base. As a mid-sized, service-driven IT consulting and software development firm, ISHIR relies on its engineering team to build robust applications that solve complex business challenges. Engineers here do not just write code; they actively participate in modernizing legacy systems, migrating applications to cloud environments, and implementing cutting-edge technologies like AI-native full-stack development. The impact of this position is substantial, as your work directly influences client satisfaction, system reliability, and business growth. You will operate in a dynamic environment where you might transition from backend development to frontend design, ensuring seamless integration across the entire product lifecycle.

This guide is scoped to a Software Engineer candidate at ISHIR.

Focus areas

• .NET (C#/.NET ecosystem)
• Full-Stack Development
• Technical Interview Problem Solving

The ISHIR interview process

ISHIR candidates report 5 rounds over 4-6 weeks. The stages below are what candidates describe, not a published process.

Telephonic Screening

Initial call by an HR representative focusing on current role, project responsibilities, and job alignment.

What to demonstrate

• Initial call by an HR representative focusing on current role, project responsibilities, and job alignment
• Depth in .NET (C#/.NET ecosystem)

How to prepare

• Answer aloud and timed: Explain the complete lifecycle of a web application from the browser request to the database and back.
• Answer aloud and timed: How do you manage state and data binding in frontend frameworks like AngularJS?

Technical Evaluations

Series of technical evaluations including panel interviews with team leads and discussions with department heads.

What to demonstrate

• Series of technical evaluations including panel interviews with team leads and discussions with department heads
• Depth in .NET (C#/.NET ecosystem)

How to prepare

• Answer aloud and timed: What are the key differences between various dependency injection lifetimes in.NET?
• Answer aloud and timed: Describe your experience with hosting and deploying applications on IIS.

Psychometric Test

Evaluation of situational judgment and written communication through a psychometric or personality test.

What to demonstrate

• Evaluation of situational judgment and written communication through a psychometric or personality test
• Depth in .NET (C#/.NET ecosystem)

How to prepare

• Answer aloud and timed: How do you utilize Team Foundation Server (TFS) or Git for version control and CI/CD pipelines?
• Answer aloud and timed: How would you design a cloud-hosted backend using AWS services to handle sudden traffic spikes?

Leadership Discussions

Final discussions with executive stakeholders, such as the COO or CEO.

What to demonstrate

• Final discussions with executive stakeholders, such as the COO or CEO
• Depth in .NET (C#/.NET ecosystem)

How to prepare

• Answer aloud and timed: Explain how you would structure a database schema for a multi-tenant client application.
• Answer aloud and timed: What strategies do you use to optimize database queries and reduce API latency?

Salary Negotiation

Discussion regarding salary and benefits with HR.

What to demonstrate

• Discussion regarding salary and benefits with HR
• Depth in .NET (C#/.NET ecosystem)

How to prepare

• Answer aloud and timed: Describe a scenario where you had to troubleshoot a deployment issue on a cloud server.
• Answer aloud and timed: How many hours can you comfortably sit and focus on work in the office during critical delivery phases?

Where candidates lose points

Master the entire stack

Do not limit your preparation to just backend development. Even if you are hired primarily for backend work, be ready to discuss frontend integration, database optimization, and deployment tools like IIS.

Prepare for the psychometric test

Treat the personality and situational assessment seriously. It is designed to evaluate your communication skills, ethics, and cultural alignment, and it plays a significant role in the overall decision-making process.

Do not dismiss the psychometric or personality test

It includes scenario-based questions and a short essay designed to evaluate your written communication and professional ethics.

Questions & practice

Collapse a redelivered event batch into per-aggregate high-water marks

Easy · hashing · at-least-once · aggregation

You drain a batch of up to 5,000,000 events, each (aggregate_id BIGINT, aggregate_version INT, event_type, payload). The log guarantees order within one aggregate only; the batch merges 64 partitions, and a relay failover has redelivered a range, so an older version for an aggregate can appear after a newer one. Given a map of last_applied_version per aggregate, produce the events worth applying, at most one per (aggregate_id, version), plus the count discarded. Target O(n) time. State the memory for 2,000,000 distinct aggregates and what you do when it does not fit.

Approach

1. One pass, one hash map from aggregate_id to the highest version kept, and a discard counter. An event whose version is at or below last_applied_version for its aggregate is dropped without further work, which is the whole reason the event carries its version rather than a delta. O(n) expected time, O(d) space in distinct aggregates.
2. Keep the maximum, never the last occurrence. The redelivered range means the final appearance of an aggregate in the batch can be an older version than one seen earlier in the same batch, so last-wins applies stale state over newer state and the projection regresses with no error anywhere.
3. Cost the memory instead of calling it large: an 8-byte key plus a 4-byte version is 12 bytes of payload, and an open-addressed table held at a 0.7 load factor costs roughly 17 bytes per entry before per-slot metadata, so 2,000,000 aggregates is tens of megabytes in a native layout and several times that in a runtime that boxes both key and value.
4. If the distinct set exceeds memory, partition on hash(aggregate_id) mod P and reduce each partition independently. Every event for one aggregate hashes to the same partition, so the per-partition result is exact and the merge is concatenation rather than a second reduction.

Follow-up

• The payload is a patch rather than a snapshot, so applying only the highest version loses the intermediate changes. What changes in your reduction?
• How do you detect that version 7 arrived while version 6 was never delivered, and what should the consumer do about the gap?

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?

Track a rolling failure rate per destination for circuit decisions

Easy · sliding window · ring buffer · circuit breaker

The egress service delivers about 1,500 webhooks per second across roughly 40,000 destinations, each call bounded by a 10 second timeout. Maintain, per destination, the failure rate over the trailing 60 seconds so a caller can ask before dispatch whether the circuit should open. Attempts arrive as (destination_id, finished_at_ms, outcome). Requirement: amortised O(1) per attempt, with total memory bounded by the destination count rather than by traffic. Give the structure, its exact memory, and the rule that stops a destination with three attempts from opening a circuit.

Approach

1. Name the exact-deque version and then reject it as the default. Holding timestamps and advancing a tail pointer past anything older than now minus 60 seconds is a correct two-pointer window at amortised O(1) per attempt, but its memory tracks in-window traffic, so one destination in a retry storm holds hundreds of thousands of entries while thousands of quiet destinations hold none.
2. Use a ring of 60 one-second buckets per destination, each bucket a pair of counters for attempts and failures. On an attempt, advance the ring by the elapsed whole seconds, zeroing at most min(elapsed, 60) buckets, then increment the head. That is amortised O(1) with a fixed footprint per destination.
3. State the footprint: 60 buckets times two 4-byte counters is 480 bytes of payload per destination, so 40,000 destinations is roughly 20 to 25 MB with per-entry overhead, bounded by the catalogue rather than by the rate. The cost is granularity, since the oldest bucket ages out in whole seconds, which is far tighter than the decision needs.
4. Require a minimum sample before the circuit may open. A destination with three attempts and three failures reads as 100 percent and is not evidence; a floor of roughly 20 attempts in the window makes the ratio meaningful, and below that floor use a run of consecutive failures as the trigger instead.

Follow-up

• The fleet is 30 instances and each sees roughly a thirtieth of a destination's traffic. Where does the rate actually live, and what does a per-instance answer get wrong?
• A destination answers in 9.5 seconds and succeeds. It is not failing but it is consuming your per-destination concurrency. What signal should open the circuit here?

Explain how you would structure a database schema for a multi-tenant client application.

Medium · System Architecture & Cloud

Approach

1. Name the grain you start from and join outward from it.
2. Check whether any join is one-to-many before aggregating, or the sums inflate.
3. Say which index the query would use, and what makes it unusable.
4. Handle the rows that do not match: that is usually the actual question.

Follow-up

• How does the query change if that join becomes one-to-many?
• What happens to this when the table is ten times larger?

Stop tag and share joins from fanning out a page

Medium · join fan-out · semi-joins · many-to-many

resource_tag is (resource_id, tag_id) with PK (resource_id, tag_id); resource_share is (resource_id, shared_with_user_id, permission). The tagged-and-shared listing inner-joins resource to both, filters tenant_id, tag_id = ANY($2) and shared_with_user_id = $3, orders by updated_at DESC and takes 50. Pages come back with fewer than 50 distinct resources and the total in the header is far too high. Explain the row multiplication, rewrite both the page query and the count query so each is correct, and name the index each one needs. PostgreSQL 16.

Approach

1. Do the arithmetic against the predicates that are actually there. An inner join emits one row per matching child row, and both joins are filtered: tag_id = ANY($2) admits only the requested tags, shared_with_user_id = $3 admits one user's share rows. So a resource holding three of the requested tags and shared with $3 once yields three rows, not one — the multiplier is its count of matching tags times its share rows for that single user, and that second factor is 1 unless the table admits duplicate (resource_id, shared_with_user_id) pairs. LIMIT 50 then limits rows rather than resources, and COUNT(*) counts pairs — the header is the product, not the population.
2. Reject DISTINCT as the fix. It deduplicates after the product has been built, so the planner must materialise and sort the fanned-out set before the LIMIT can apply, and it leaves any SUM or AVG in the same select list wrong.
3. Rewrite both filters as semi-joins, keeping resource as the only row source: AND EXISTS (SELECT 1 FROM resource_tag rt WHERE rt.resource_id = r.resource_id AND rt.tag_id = ANY($2)) and the same shape against resource_share. A semi-join stops at the first match per resource and preserves the driving index order, so ORDER BY updated_at DESC, resource_id DESC LIMIT 50 still stops after 50 rows.
4. Count with the same predicates and no join at all: SELECT count(*) FROM resource r WHERE r.tenant_id = $1 AND r.status = 'active' AND EXISTS (...) AND EXISTS (...). Nothing multiplies a resource, so the number is the population.

Follow-up

• The filter changes from 'any of these tags' to 'all of these tags'. Rewrite it and state what it costs relative to the ANY form.
• A resource can be shared with the same user twice under different permissions. Does your count change, and should it?

Explain the complete lifecycle of a web application from the browser request to the database and back.

Medium · Technical & Domain Knowledge

Approach

1. Clarify what is being asked and what a complete answer contains.
2. State your assumptions explicitly before working the problem.
3. Say what you would check first and why it is the highest-information step.
4. Work from the requirement backwards to the design.

Follow-up

• What assumption would you test first?
• How would you know your answer was wrong?

How do you manage state and data binding in frontend frameworks like AngularJS?

Medium · Technical & Domain Knowledge

Approach

1. Clarify what is being asked and what a complete answer contains.
2. State your assumptions explicitly before working the problem.
3. Say what you would check first and why it is the highest-information step.
4. Work from the requirement backwards to the design.

Follow-up

• What assumption would you test first?
• How would you know your answer was wrong?

What are the key differences between various dependency injection lifetimes in.NET?

Medium · Technical & Domain Knowledge

Approach

1. Clarify what is being asked and what a complete answer contains.
2. State your assumptions explicitly before working the problem.
3. Say what you would check first and why it is the highest-information step.
4. Work from the requirement backwards to the design.

Follow-up

• What assumption would you test first?
• How would you know your answer was wrong?

How do you utilize Team Foundation Server (TFS) or Git for version control and CI/CD pipelines?

Medium · Technical & Domain Knowledge

Approach

1. Clarify what is being asked and what a complete answer contains.
2. State your assumptions explicitly before working the problem.
3. Say what you would check first and why it is the highest-information step.
4. Work from the requirement backwards to the design.

Follow-up

• What assumption would you test first?
• How would you know your answer was wrong?

How would you design a cloud-hosted backend using AWS services to handle sudden traffic spikes?

Medium · System Architecture & Cloud

Approach

1. Fix the scope first: who calls this, how often, and what they do when it fails.
2. Name the read and write paths separately; they rarely have the same bottleneck.
3. Choose a partition key and say what query it makes expensive.
4. State the consistency you need, and where you are willing to be stale.

Follow-up

• What breaks first when traffic grows ten times?
• How does this behave when that dependency is down for an hour?

What strategies do you use to optimize database queries and reduce API latency?

Medium · System Architecture & Cloud

Approach

1. Say who the caller is and what they do when the call fails halfway.
2. Define the identity of a request so a retry cannot double-apply it.
3. Separate accepted, pending, failed and confirmed; they are different facts.
4. Design the error taxonomy before the success shape; callers branch on it.

Follow-up

• What happens if the caller retries after a timeout?
• How does a client discover it is on an old version of this contract?

Describe a scenario where you had to troubleshoot a deployment issue on a cloud server.

Medium · System Architecture & Cloud

Approach

1. Establish what changed and when, before forming any theory.
2. Pick a bisection that eliminates candidates whichever way it turns out.
3. Check the instrumentation before believing the symptom.
4. Separate the trigger from the cause; the deploy is rarely the bug.

Follow-up

• What would you look at first, and what would it rule out?
• How would you tell a cause from a coincidence here?

Suggested practice checklist

Built from the rounds and topics ISHIR candidates report.

Day 1 — Map the ISHIR loop

• Write out the reported sequence: Telephonic Screening, Technical Evaluations, Psychometric Test, Leadership Discussions, Salary Negotiation.
• For each round, write one sentence on what it is judging, from the description above, and mark the one you are least ready for.

Deliverable: A one-page map of the 5 reported rounds, with the weakest marked.

Day 2 — Work .NET (C#/.NET ecosystem)

• Spend the session on .NET (C#/.NET ecosystem), which ISHIR candidates report being tested on.
• Write one worked example in .NET (C#/.NET ecosystem) and time yourself on it.

Deliverable: One timed worked example in .NET (C#/.NET ecosystem).

Day 3 — Work Full-Stack Development

• Spend the session on Full-Stack Development, which ISHIR candidates report being tested on.
• Write one worked example in Full-Stack Development and time yourself on it.

Deliverable: One timed worked example in Full-Stack Development.

Day 4 — Work Technical Interview Problem Solving

• Spend the session on Technical Interview Problem Solving, which ISHIR candidates report being tested on.
• Write one worked example in Technical Interview Problem Solving and time yourself on it.

Deliverable: One timed worked example in Technical Interview Problem Solving.

Day 5 — Answer out loud: Technical & Domain Knowledge

• Answer aloud, timed: Explain the complete lifecycle of a web application from the browser request to the database and back.
• Answer aloud, timed: How do you manage state and data binding in frontend frameworks like AngularJS?

Deliverable: Spoken answers to 2 reported Technical & Domain Knowledge question(s), under time.

Day 6 — Answer out loud: System Architecture & Cloud

• Answer aloud, timed: How would you design a cloud-hosted backend using AWS services to handle sudden traffic spikes?
• Answer aloud, timed: Explain how you would structure a database schema for a multi-tenant client application.

Deliverable: Spoken answers to 2 reported System Architecture & Cloud question(s), under time.

Day 7 — Answer out loud: Behavioral, Situational & Logical

• Answer aloud, timed: How many hours can you comfortably sit and focus on work in the office during critical delivery phases?
• Answer aloud, timed: Describe a situation where you had to work with a technology you had never used before. How did you adapt?

Deliverable: Spoken answers to 2 reported Behavioral, Situational & Logical question(s), under time.

Behavioural preparation

Behavioural rounds judge the decision you made and what it cost.

Describe your experience with hosting and deploying applications on IIS.

Medium · Technical & Domain Knowledge

Approach

1. Pick a story where you made the decision, not one where you watched it.
2. State the situation in two sentences and spend the rest on the reasoning.
3. Give the blast radius: what could have broken, and what you measured.
4. Name the disagreement and how you resolved it with evidence.

Follow-up

• What would you do differently if you ran that again?
• How did you know your change caused the improvement?

How many hours can you comfortably sit and focus on work in the office during critical delivery phases?

Medium · Behavioral, Situational & Logical

Approach

1. Pick a story where you made the decision, not one where you watched it.
2. State the situation in two sentences and spend the rest on the reasoning.
3. Give the blast radius: what could have broken, and what you measured.
4. Name the disagreement and how you resolved it with evidence.

Follow-up

• What would you do differently if you ran that again?
• How did you know your change caused the improvement?

Describe a situation where you had to work with a technology you had never used before. How did you adapt?

Medium · Behavioral, Situational & Logical

Approach

1. Pick a story where you made the decision, not one where you watched it.
2. State the situation in two sentences and spend the rest on the reasoning.
3. Give the blast radius: what could have broken, and what you measured.
4. Name the disagreement and how you resolved it with evidence.

Follow-up

• What would you do differently if you ran that again?
• How did you know your change caused the improvement?

How do you handle a situation where a client’s requirements change drastically mid-sprint?

Medium · Behavioral, Situational & Logical

Approach

1. Pick a story where you made the decision, not one where you watched it.
2. State the situation in two sentences and spend the rest on the reasoning.
3. Give the blast radius: what could have broken, and what you measured.
4. Name the disagreement and how you resolved it with evidence.

Follow-up

• What would you do differently if you ran that again?
• How did you know your change caused the improvement?

Tell me about a time you had a technical disagreement with a teammate. How did you resolve it?

Medium · Behavioral, Situational & Logical

Approach

1. Pick a story where you made the decision, not one where you watched it.
2. State the situation in two sentences and spend the rest on the reasoning.
3. Give the blast radius: what could have broken, and what you measured.
4. Name the disagreement and how you resolved it with evidence.

Follow-up

• What would you do differently if you ran that again?
• How did you know your change caused the improvement?