Wipro Project Engineer Interview: Rehearse Projects, CS and Coding

Practise one fictional library API from project overview through transaction reasoning, applied CS follow-ups and a second-largest-distinct coding trace. Then score a 12-minute mock and repair the weakest lane.

KnowledgeGate Team

Exam prep & CS education

Updated 28 Jul 20266 min read

Candidates often prepare a project description, isolated CS definitions and coding questions as three unrelated tasks. The difficulty begins when an interviewer moves from what you built to the database decision behind it, then asks you to code a related idea aloud. Wipro runs its fresher hiring through Elite National Talent Hunt, Turbo and WILP, and whichever of those your Project Engineer invitation comes from, the technical conversation leans on the same three things: the project on your resume, the core subjects, and one language you can write in front of someone. So rehearse them as one chain: defend one project with measurable details, derive DBMS, OS and network answers from it, and solve one small coding problem.

1. Build one connected rehearsal, not three piles of notes

Use three lanes: project evidence, core CS reasoning and executable coding. Move naturally from “what I built” to “why it works” to “how I would implement one part”.

Test that connection in 12 minutes. Give a 90-second project overview, answer two follow-up questions, explain one CS concept through the project, solve one small coding prompt, and close on edge cases. Wipro’s written assessment, essay section included, is a separate problem with its own practice: the Wipro placement preparation guide covers that half.

The Wipro Preparation course is organised around the Elite NTH, Turbo and WILP structures, with topic-wise videos and section tests for the aptitude, English, essay and coding stages that come before this conversation. Which route you sit is decided by the drive and your eligibility, so take the stage order from your own invitation and careers.wipro.com rather than from any single candidate account.

2. Worked project defence: a library issue-and-return API

Use this fictional practice project throughout: a college library API built with Node.js, Express and PostgreSQL. Its sample data contains 1,200 books, 180 registered users and 4,800 issue records. It exposes POST /issues, POST /returns and GET /books?query=. Your ownership is precise: the issue transaction, validation and two integration tests.

Build the 90-second answer in four parts:

  1. Problem: Students need to find and issue an available book without corrupting its stock count.

  2. Design: Express handles the API. PostgreSQL stores users, books and issues with constraints and transactions.

  3. Ownership: You wrote POST /issues, its validation and transaction, plus successful-issue and unavailable-copy tests.

  4. Result: On the local 1,200-book dataset, a title index reduced median search time from 140 ms to 35 ms. Say it exactly that way, as a local measurement rather than a production benchmark.

For “Why PostgreSQL?”, connect constraints and transactions to the copy count. For “What did you personally write?”, name the endpoint, transaction and tests instead of saying “we built the backend”.

Architecture of the practice library API: a POST /issues request from the student client passes through Express validation into one PostgreSQL transaction that locks book 317 with SELECT ... FOR UPDATE, inserts the issue row and decrements available_copies. A lower panel shows book search dropping from a 140 ms to a 35 ms median after a title index, on 1,200 books, 180 users and 4,800 issue rows.

3. Defend one technical decision with a complete transaction trace

Start with book_id = 317 and available_copies = 1. Users 42 and 57 send requests almost together. Without locking, both may read 1, insert an issue and promise the final copy. That is the race condition.

The corrected trace is concrete:

  1. Transaction A locks row 317 and reads available_copies = 1.

  2. A inserts (user_id=42, book_id=317), changes the count to 0, and commits.

  3. Transaction B can now acquire the row lock. It reads 0, rolls back and returns “not available”.

Atomicity means the insert and stock update both succeed or neither does. Isolation prevents B from acting on A’s stale view. Row locking serialises requests for book 317, but not transactions locking unrelated book rows. Name the two integration cases you tested, and do not claim uncollected load-test results.

4. Turn the same project into DBMS, OS and network answers

For DBMS, issue(user_id, book_id, issued_at, returned_at) references user and book primary keys so an issue cannot point to a missing record. returned_at is nullable because an issued book has not yet been returned. The insert and stock decrement need one transaction because they form one logical action.

For OS, imagine two Node.js server processes handling multiple in-flight requests. A process has its own execution context and resources. Threads are execution units within a process, but Node.js does not create one new thread for every request. JavaScript callbacks run through the process’s event loop, while I/O is handled asynchronously.

For networks, trace POST /issues as an HTTPS request from client to server. A blind retry after a lost response could create a duplicate issue even though the first request succeeded. An idempotency key such as issue-42-317-20260719 lets the server recognise the repeated operation and return the stored result. For deeper revision across these subjects, use Technical Interview: OS, DBMS, CN & OOP Prep.

5. Worked coding prompt: second-largest distinct latency

Rehearse this prompt exactly: “Given API latencies [120, 80, 120, 200, 95, 80] in milliseconds, return the second-largest distinct value. Return null if fewer than two distinct values exist.” Use the signature static Integer secondLargestDistinct(int[] values).

Explain the invariant before writing syntax. largest holds the greatest distinct value seen so far. second holds the greatest distinct value below it. Both start as null, which also handles negative inputs correctly.

static Integer secondLargestDistinct(int[] values) {
    Integer largest = null;
    Integer second = null;

    for (int value : values) {
        if ((largest != null && value == largest) ||
            (second != null && value == second)) {
            continue;
        }
        if (largest == null || value > largest) {
            second = largest;
            largest = value;
        } else if (second == null || value > second) {
            second = value;
        }
    }
    return second;
}

Trace it aloud: 120 gives (120, null), then 80 gives (120, 80). Ignore the duplicate 120. After 200, the pair becomes (200, 120). Neither 95 nor the final 80 changes it. The answer is 120.

A trace table stepping through the latencies [120, 80, 120, 200, 95, 80] to reach the second-largest distinct value 120 in O(n) time and O(1) space.

The loop visits each value once, so time is O(n) and extra space is O(1). Check [7, 7] -> null and [-3, -8, -3] -> -8. Initialising both variables to zero would fail on the negative case. Sorting is valid, but costs O(n log n) time.

6. Common traps and the repair for each

  • Presenting team work as personal work: Name the endpoint, transaction and two tests you completed, then label the rest as team work.

  • Reciting definitions: A definition alone does not show reasoning. Attach each term to row 317, the concurrent users or the HTTPS retry, then state the general rule.

  • Coding silently: Restate “distinct”, test [7, 7], name the invariant, trace two values, then code. Use the negative case to expose the zero-initialisation bug.

7. Run a 12-minute pressure rehearsal and score the evidence

Use an exact timer: 0:00-1:30 for the project overview, 1:30-4:30 for transaction follow-ups, 4:30-7:00 for the DBMS, OS and network bridge, 7:00-11:00 for coding and trace, and 11:00-12:00 for edge cases and correction. If an answer overruns, finish the current sentence and record the missing point instead of restarting the mock.

Score each lane from 0 to 2: 0 = vague or incorrect, 1 = correct but unsupported, and 2 = correct with a project value, trace or test. Project 1, CS 1 and coding 0 totals 2/6. Next, repair one weakness per lane instead of memorising a new script.

Two weak lanes in one sitting usually trace back to a thin project account rather than weak CS, because the follow-ups and the subject bridge both feed off it. Repair the project answer first, then re-score. For the same three lanes against other recruiters, the Company-Specific Placement Courses hub carries the company-wise sets.

8. Short version: one project, four proofs, one next step

Finish with four proofs: a 90-second project account, one transaction trace, one applied CS bridge, and one coding problem tested on normal, duplicate and negative input.

Record the 12-minute rehearsal, score it out of 6, and repeat only the weakest lane. For structured help with the interview and resume stage, continue with the Interview & Resume Preparation Course.