Infosys Project Interview: Defend Architecture, Trade-offs and Ownership

In an Infosys project discussion, a candidate can name React, Node.js and PostgreSQL, yet collapse when asked why the design fits, what fails under concurrency, or what they built. Use one defence method: claim, reason, evidence and limit. Treat the case as illustrative. Replace its numbers with real project evidence, never borrowed results.

Infosys project interview: frame the project in 90 seconds

Use 90 seconds to give the interviewer a map:

1. Problem and users, 15 seconds: what the system does and for whom.

2. Operating constraints, 20 seconds: team, timeline, scale and correctness.

3. Component flow, 25 seconds: client, API, database and background work.

4. Personal ownership, 20 seconds: modules, decisions and tests.

5. Outcome and one limitation, 10 seconds: what worked and what did not.

The budget is 15 + 20 + 25 + 20 + 10 = 90 seconds. It gives follow-up questions a structure to test.

The rehearsal system is a campus application tracker for 4,000 students and 120 recruiters. Its assumed peak is 300 concurrent users, 25 reads per second and 4 writes per second. It supports job discovery, one application per student-job pair, slot booking and email. Use Infosys Interview Process: What to Prepare at Each Stage to map route and stage variation, and the Infosys Superset Preparation Course for company-specific practice. Match the exact role label in your invitation when you choose rehearsal depth:

• Systems Engineer: lead with end-to-end flow, validation and the failure you diagnosed.

• Digital Specialist Engineer: add one database, scaling or concurrency trade-off backed by a trace.

• Specialist Programmer: go to code level: invariant, transaction boundary, complexity and tests.

Project architecture defence: move from constraints to components

Choose a React client and one Node.js/Express modular monolith with applications, slots and notifications modules. PostgreSQL is the system of record. An outbox_jobs table and worker handle post-commit email.

The synchronous path changes application or booking state and records notification intent in one transaction. The asynchronous path sends email after commit. Mail failure cannot undo a booking, while the outbox preserves the intent.

The core model is:

• Student(student_id)

• Company(company_id)

• Job(job_id, company_id)

• Application(application_id, student_id, job_id, status, created_at), with UNIQUE(student_id, job_id)

• InterviewSlot(slot_id, job_id, capacity, booked_count)

• SlotBooking(booking_id, slot_id, student_id), with UNIQUE(slot_id, student_id)

Four people, six weeks and 25 + 4 = 29 peak requests per second do not justify microservices. Relational constraints protect the invariants. The outbox isolates email failure without losing retry work.

Worked example: defend correctness when 40 users chase 12 slots

Suppose 40 different users concurrently target one slot where capacity = 12 and booked_count = 0.

1. Each transaction runs UPDATE InterviewSlot SET booked_count = booked_count + 1 WHERE slot_id = ? AND booked_count < capacity.

2. Row serialization lets only the first 12 update it, moving the count from 0 to 12.

3. The remaining 40 - 12 = 28 affect zero rows and return HTTP 409.

4. The transaction then inserts SlotBooking. If its uniqueness constraint fails, the counter increment also rolls back.

Now send 20 simultaneous POST /applications calls with (student_id = 1042, job_id = 87). PostgreSQL permits one insert and rejects 20 - 1 = 19 on UNIQUE(student_id, job_id). The winner gets HTTP 201 and duplicates get HTTP 409, without a check-then-insert race.

State the invariants, not just the technology: booked count never exceeds 12, student 1042 cannot apply twice to job 87, and email can be retried from outbox_jobs without undoing a confirmed booking.

Architecture trade-offs: why not microservices, MongoDB or all-sync email

At 25 reads plus 4 writes per second, retain the monolith. At a hypothetical 10x load, 25 x 10 = 250 reads and 4 x 10 = 40 writes per second. First profile queries, add (student_id, created_at DESC), and scale stateless API instances. Extract only for a proven boundary.

With 80,000 Application rows but only 20 for student 1042, the index can seek to that student's ordered rows instead of scanning all 80,000. Use EXPLAIN ANALYZE and a repeatable load test, not invented latency gains.

Project ownership: replace "we built" with an auditable contribution map

In this four-person, six-week sample, the candidate owns applications and slots, eight endpoints, three migrations, 18 integration tests and 14 merged pull requests. Replace every sample number with your records.

"We selected the modular monolith" gives team context. "I designed the two uniqueness constraints, wrote the atomic capacity update and added the concurrency tests" proves individual scope. Prepare the file, decision, review feedback and test behind each claim.

Use the Interview & Resume Preparation Course for structured resume and mock-interview practice around that contribution map.

Infosys project interview follow-ups: branch from every claim

Practise claim, reason, evidence, limit: "I chose PostgreSQL because booking and application uniqueness are invariants. The two unique constraints and concurrency tests are the evidence. The limit is that email remains eventually consistent."

Branch from it: What if the database fails? Why not MongoDB? What happens at 10x? Which code did you write? How did you test the race? Use three exact checks:

• 20 duplicate application requests produce 1 stored row and 19 conflicts.

• 40 booking requests against capacity 12 produce 12 bookings and 28 conflicts.

• A forced email-worker failure leaves 1 pending outbox job. A retry sends it without creating a second booking.

The Wipro Project Engineer Interview: Project, CS, Code Drill gives a broader rehearsal that connects one project to CS fundamentals and coding. For an Infosys project discussion, keep the next loop on architecture choices, concurrent-state correctness and personal ownership.

Project interview mistakes that destroy credibility

Four traps are easy to spot and fix:

• Reciting the stack without constraints: connect the monolith to four people, six weeks and 29 peak requests per second.

• Claiming microservices without a boundary: name the module that needs separate scaling or deployment, or retain the monolith.

• Using "I" for team work: separate the team's architecture decision from the two modules and test artefacts you personally owned.

• Quoting performance gains without a reproducible test: show EXPLAIN ANALYZE, the 80,000-row setup and the repeatable load test, then admit what was not measured.

If you inherited the architecture, say what you inherited, what you changed and why. If you do not know the production-scale answer, name the next measurement or experiment instead of inventing certainty.

Keep the units precise. A peak of 300 concurrent users is not 300 requests per second. In this case, 25 reads plus 4 writes equals 29 requests per second. HTTP 409 is a handled conflict, not a server crash.

The short version: one claim, one reason, one proof, one limit

• Claim: state the architecture choice.

• Reason: tie it to a requirement or constraint.

• Proof: show a personal artefact or test.

• Limit: admit one weakness and name the next scaling trigger.

For the central test, 40 booking requests compete for capacity 12, producing 12 successes and 40 - 12 = 28 handled conflicts. Readers comparing broader preparation paths can explore Company-Specific Placement Courses. Then draw your own component flow, replace every illustrative number with real project evidence, and practise the five follow-up branches aloud.