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 makes the role highly versatile and intellectually stimulating, offering exposure to multiple domains, architectures, and tech stacks. For candidates who thrive on variety, technical agility, and direct ownership of deliverables, the position at offers an exceptional platform. You will work alongside experienced technical leaders and client-facing teams, making it a highly collaborative and career-accelerating environment. Software Engineer ISHIR
Telephonic Screening
reportedInitial 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
reportedSeries 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
reportedEvaluation 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
reportedFinal 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
reportedDiscussion 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?
PracHub editorial advice for the preparation topics above.
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.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Collapse a redelivered event batch into per-aggregate high-water marks
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
- 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.
- 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.
- 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.
- 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
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
- 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.
- 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.
- 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.
- 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
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
- 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.
- 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.
- 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.
- 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.
Explain how you would structure a database schema for a multi-tenant client application.
Approach
- Name the grain you start from and join outward from it.
- Check whether any join is one-to-many before aggregating, or the sums inflate.
- Say which index the query would use, and what makes it unusable.
- 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
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
- 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.
- 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.
- 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.
- 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.
Explain the complete lifecycle of a web application from the browser request to the database and back.
Approach
- Clarify what is being asked and what a complete answer contains.
- State your assumptions explicitly before working the problem.
- Say what you would check first and why it is the highest-information step.
- 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?
How do you manage state and data binding in frontend frameworks like AngularJS?
Approach
- Clarify what is being asked and what a complete answer contains.
- State your assumptions explicitly before working the problem.
- Say what you would check first and why it is the highest-information step.
- 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?
What are the key differences between various dependency injection lifetimes in.NET?
Approach
- Clarify what is being asked and what a complete answer contains.
- State your assumptions explicitly before working the problem.
- Say what you would check first and why it is the highest-information step.
- 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?
How do you utilize Team Foundation Server (TFS) or Git for version control and CI/CD pipelines?
Approach
- Clarify what is being asked and what a complete answer contains.
- State your assumptions explicitly before working the problem.
- Say what you would check first and why it is the highest-information step.
- 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?
How would you design a cloud-hosted backend using AWS services to handle sudden traffic spikes?
Approach
- Fix the scope first: who calls this, how often, and what they do when it fails.
- Name the read and write paths separately; they rarely have the same bottleneck.
- Choose a partition key and say what query it makes expensive.
- 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?
What strategies do you use to optimize database queries and reduce API latency?
Approach
- Say who the caller is and what they do when the call fails halfway.
- Define the identity of a request so a retry cannot double-apply it.
- Separate accepted, pending, failed and confirmed; they are different facts.
- 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.
Describe a scenario where you had to troubleshoot a deployment issue on a cloud server.
Approach
- Establish what changed and when, before forming any theory.
- Pick a bisection that eliminates candidates whichever way it turns out.
- Check the instrumentation before believing the symptom.
- 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?
Built from the rounds and topics ISHIR candidates report.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Map 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.
02Work .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).
03Work 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.
04Work 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.
05Answer 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.
06Answer 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.
07Answer 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.
Expand any day for tasks and deliverables. Your progress is saved on this device.
Behavioural rounds judge the decision you made and what it cost.
Describe your experience with hosting and deploying applications on IIS.
Describe your experience with hosting and deploying applications on IIS.
Approach
- Pick a story where you made the decision, not one where you watched it.
- State the situation in two sentences and spend the rest on the reasoning.
- Give the blast radius: what could have broken, and what you measured.
- 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?
How many hours can you comfortably sit and focus on work in the office during critical delivery phases?
Approach
- Pick a story where you made the decision, not one where you watched it.
- State the situation in two sentences and spend the rest on the reasoning.
- Give the blast radius: what could have broken, and what you measured.
- 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?
Describe a situation where you had to work with a technology you had never used before. How did you adapt?
Approach
- Pick a story where you made the decision, not one where you watched it.
- State the situation in two sentences and spend the rest on the reasoning.
- Give the blast radius: what could have broken, and what you measured.
- 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?
How do you handle a situation where a client’s requirements change drastically mid-sprint?
Approach
- Pick a story where you made the decision, not one where you watched it.
- State the situation in two sentences and spend the rest on the reasoning.
- Give the blast radius: what could have broken, and what you measured.
- 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?
Tell me about a time you had a technical disagreement with a teammate. How did you resolve it?
Approach
- Pick a story where you made the decision, not one where you watched it.
- State the situation in two sentences and spend the rest on the reasoning.
- Give the blast radius: what could have broken, and what you measured.
- 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?
- 01
Describe your experience with hosting and deploying applications on IIS.
- 02
How many hours can you comfortably sit and focus on work in the office during critical delivery phases?
- 03
Describe a situation where you had to work with a technology you had never used before. How did you adapt?
- 04
How do you handle a situation where a client’s requirements change drastically mid-sprint?
How difficult is the Software Engineer interview at ISHIR?
The interview difficulty is generally rated as average to challenging. While the technical questions focus heavily on core concepts and practical application, the multi-round process—including psychometric tests and executive rounds—requires thorough preparation and stamina.
ISHIR Software Engineer candidate reports ↗What is the typical timeline for the hiring process?
The entire process, from the initial HR screening to the final offer letter, usually takes about two weeks. However, the technical rounds are often grouped together to minimize delays. Salary negotiation is a highly emphasized part of the final HR round. Be prepared with clear market data and a firm understanding of your expectations before this stage.
ISHIR Software Engineer candidate reports ↗What is the work culture like for Software Engineers at ISHIR?
ISHIR operates on a service-based model, meaning the work is dynamic and highly client-focused. Engineers get the opportunity to work on diverse projects and technologies, making it a great place to build versatile skills quickly.
ISHIR Software Engineer candidate reports ↗Is there a coding test during the interview process?
While there may not always be a formal, automated coding platform test, you should expect to write code, explain algorithms, or walk through architecture diagrams during the live technical panel rounds.
ISHIR Software Engineer candidate reports ↗What topics does ISHIR test in interviews?
ISHIR interviews most often cover Backend Development, Test Case Design, Frontend Development, Regression Testing, and Integration Testing. The exact emphasis depends on the specific role you apply for.
ISHIR Software Engineer candidate reports ↗Sources & methodology 3 sources ↗
No official company page is cited. Rounds and questions come from candidate reports and PracHub editorial material; each source shows the date it was read.
- 01ISHIR Software Engineer candidate reports ↗
Company-reported rounds, questions and FAQ.
Candidate reports · Accessed 2026-09-22 - 02PracHub Software Engineer practice ↗
PracHub practice material, not company-reported.
PracHub page · Accessed 2026-09-22 - 03PracHub preparation framework ↗
PracHub preparation guidance.
PracHub page · Accessed 2026-09-22
Explore related engineering environments and compare the preparation focus.
Vercel Software Engineer Interview Guide
Debugging practice for Vercel software engineer prep built on a reproduction you trust, narrowing to the smallest failing input, and changing one variable per run so the result stays attributable.
WorldWide Technology Holding Software Engineer Interview Guide
What WorldWide Technology Holding asks Software Engineer candidates, from reported rounds and questions.
XYZ Software Engineer Interview Guide
What XYZ asks Software Engineer candidates, from reported rounds and questions.
Yoh Software Engineer Interview Guide
What Yoh asks Software Engineer candidates, from reported rounds and questions.