GEP Software Engineer Interview Guide

The 60-second brief

As a Software Engineer at GEP, you are at the core of building enterprise-grade procurement and supply chain software. You will be responsible for designing, developing, and maintaining scalable solutions that help global organizations streamline their operations. Your work directly impacts the efficiency of complex business workflows, requiring a blend of robust backend logic and intuitive frontend architecture. This role is critical to the GEP product ecosystem, which demands high reliability and performance. You will often work in cross-functional teams, collaborating with Product Managers and UI/UX designers to translate business requirements into technical reality. Success in this role requires not only technical proficiency but also a deep interest in how software solves real-world business challenges at scale.

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

Focus areas

• .NET
• OOP/OOPS Concepts
• C#

The GEP interview process

GEP candidates report 3 rounds over 3-5 weeks. The stages below are what candidates describe, not a published process.

Online Assessment

Initial online assessment serves as a filter for candidates.

What to demonstrate

• Initial online assessment serves as a filter for candidates
• Depth in .NET

How to prepare

• Answer aloud and timed: Explain the MVC architecture in the context of your previous projects.
• Answer aloud and timed: How do you approach database schema design for a high-traffic application?

Technical Interviews

Multiple rounds of technical interviews focusing on live coding and project discussions.

What to demonstrate

• Multiple rounds of technical interviews focusing on live coding and project discussions
• Depth in .NET

How to prepare

• Answer aloud and timed: Describe the difference between SQL and NoSQL databases and when to use each.
• Answer aloud and timed: What is your experience with LINQ and Entity Framework?

Managerial/HR Discussion

Final discussion focused on team fit and salary expectations.

What to demonstrate

• Final discussion focused on team fit and salary expectations
• Depth in .NET

How to prepare

• Answer aloud and timed: How do you handle authentication and security in microservices?
• Answer aloud and timed: Write a function to reverse an array or string.

Where candidates lose points

Master your resume

Every line on your resume is fair game. If you list a project, be ready to explain the logic, the database structure, and the business impact.

Prepare questions for the interviewer

Always have 2–3 thoughtful questions about the team's current technical challenges or the company's product roadmap.

Focus on SQL

Many candidates neglect SQL in favor of coding, but it is a frequent point of failure. Practice complex joins and subqueries.

Clarify the requirement

If a question seems ambiguous, ask for clarification before starting. This shows you are a thoughtful engineer who values accuracy.

Questions & practice

Write a function to reverse an array or string.

Medium · Coding and Algorithms

Approach

1. Restate the input: its shape, its size, and what is guaranteed about it.
2. Name the brute-force solution and its complexity before improving on it.
3. Choose the data structure from the access pattern, not from familiarity.
4. State the target complexity and say which constraint rules the naive version out.

Follow-up

• How does this change if the input no longer fits in memory?
• What is the worst case, and how likely is it on real data?

Explain the logic behind your implementation of sorting algorithms (e.g., Bubble sort, Merge sort).

Medium · Coding and Algorithms

Approach

1. Restate the input: its shape, its size, and what is guaranteed about it.
2. Name the brute-force solution and its complexity before improving on it.
3. Choose the data structure from the access pattern, not from familiarity.
4. State the target complexity and say which constraint rules the naive version out.

Follow-up

• How does this change if the input no longer fits in memory?
• What is the worst case, and how likely is it on real data?

How would you check for a happy number or detect a loop in a linked list?

Medium · Coding and Algorithms

Approach

1. Restate the input: its shape, its size, and what is guaranteed about it.
2. Name the brute-force solution and its complexity before improving on it.
3. Choose the data structure from the access pattern, not from familiarity.
4. State the target complexity and say which constraint rules the naive version out.

Follow-up

• How does this change if the input no longer fits in memory?
• What is the worst case, and how likely is it on real data?

How do you approach database schema design for a high-traffic application?

Medium · Technical and Domain Knowledge

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?

Describe the difference between SQL and NoSQL databases and when to use each.

Medium · Technical and Domain Knowledge

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?

Describe your process for optimizing a slow-running SQL query.

Medium · Coding and Algorithms

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?

Explain the MVC architecture in the context of your previous projects.

Medium · Technical and Domain Knowledge

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?

Cache the tenant listing feed with a bounded staleness window

Easy · caching · cache invalidation · keyset pagination

GET /v1/resources returns one tenant's resources ordered by updated_at DESC, 20 per page, at 14k requests/second peak against a 120 ms p99. The table carries the index (tenant_id, status, updated_at DESC, resource_id DESC) and writes land on the primary at 1.2k/second. Design the read path: the pagination contract, the cache key and value, what a write invalidates, and the staleness a user can observe. State the request rate that actually reaches the database, and the one repopulation race that deleting on write does not close.

Approach

1. Settle the pagination contract first, because it decides what is cacheable. OFFSET makes the database produce and discard the skipped rows, so page 500 costs five hundred pages of work, and rows inserted between two fetches shift across the boundary and are skipped or repeated with nothing in the response to reveal it. The cursor is the row value of the last row returned: WHERE tenant_id = $1 AND status = $2 AND (updated_at, resource_id) < ($3, $4) ORDER BY updated_at DESC, resource_id DESC LIMIT 21. That is a row-value comparison, not updated_at < $3 AND resource_id < $4, which is a different and wrong predicate.
2. Confirm the index actually serves it: equality on the two leading columns, then a range on the pair that follows in exactly the index's sort order, so the plan is an index scan that touches 21 entries with no sort node. Requesting 21 to return 20 is how has_more is answered without a count. resource_id is not decoration - updated_at is not unique, and without the tie-break two rows sharing a timestamp at a page boundary are the skip that keyset pagination was adopted to remove.
3. Key the cache on every value the predicate reads: tenant_id, status, cursor and page size. A key that omits tenant_id is a cross-tenant disclosure, and no test running against a single tenant's data will show it.
4. Be honest that a write does not invalidate one key. An update moves its row to the head of the ordering, so it invalidates the first page and every cursor page whose range spans the row's old and new position, which is not enumerable. Cache the first page per (tenant_id, status) - that is where the traffic is - with a short TTL, invalidate it on write, and serve deep cursor pages uncached from a replica, since each is already a 21-row index scan and they are rare.

Follow-up

• The tenant writes and immediately lists. What does it see, and what is the smallest change that makes its own write visible without sending all 14k requests/second to the primary?
• A tenant has 4 million resources and a client walks every page nightly. What does that do to the cache hit rate, and should that traffic share this path at all?

Listing latency scales with page size, not with filters

Easy · n+1 · latency · query batching

The tenant listing endpoint reads resource filtered by tenant_id and status, ordered by updated_at DESC, and returns each row plus the owner's display name from app_user and the actor of that resource's latest resource_revision. p99 is 55 ms at 10 rows per page and 1.4 s at 200. Database telemetry shows 401 statements per request, each under 1 ms, and nothing in the slow-query log. Diagnose the cause and give the fix, stating the statement count per request and the p99 you expect afterwards.

Approach

1. Read the counters before forming a theory. 401 statements for 200 rows is one driver query plus two per row, and sub-millisecond execution with an empty slow-query log rules out a bad plan. The time is round trips, which is why it is invisible in every per-query metric and scales with rows returned rather than with filter selectivity.
2. Name the two per-row statements from their normalised text: a single-row app_user lookup by user_id, and a resource_revision lookup by resource_id ordered by version DESC LIMIT 1. Confirm by dropping those two response fields and watching the statement count fall to one. That locates the calls in the serialisation layer, not the repository.
3. Check that the arithmetic accounts for the whole gap. Measure one round trip to the replica in isolation; 400 trips at roughly 3 ms of network plus 0.2 ms of execution is about 1.3 s on top of a 55 ms baseline, which matches. If the multiplication had fallen short, the N+1 would only be part of the story and you would keep looking.
4. Batch both lookups. Collect owner_user_ids and resource_ids from the driver query, then issue WHERE tenant_id = $1 AND user_id = ANY($2) for the users, and PostgreSQL's SELECT DISTINCT ON (resource_id) ... WHERE resource_id = ANY($2) ORDER BY resource_id, version DESC for the latest revision, which the UNIQUE (resource_id, version) index serves directly. On an engine without DISTINCT ON, use a lateral join or a row_number window. Three statements per request at any page size.

Follow-up

• The page size is capped at 200 today. What breaks first if it is raised to 2,000, and is it still this bug?
• How do you stop the next N+1 from reaching production, given that no individual query is slow and the endpoint's tests pass?

Suggested practice checklist

Built from the rounds and topics GEP candidates report.

Day 1 — Map the GEP loop

• Write out the reported sequence: Online Assessment, Technical Interviews, Managerial/HR Discussion.
• 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 3 reported rounds, with the weakest marked.

Day 2 — Work .NET

• Spend the session on .NET, which GEP candidates report being tested on.
• Write one worked example in .NET and time yourself on it.

Deliverable: One timed worked example in .NET.

Day 3 — Work OOP/OOPS Concepts

• Spend the session on OOP/OOPS Concepts, which GEP candidates report being tested on.
• Write one worked example in OOP/OOPS Concepts and time yourself on it.

Deliverable: One timed worked example in OOP/OOPS Concepts.

Day 4 — Work C#

• Spend the session on C#, which GEP candidates report being tested on.
• Write one worked example in C# and time yourself on it.

Deliverable: One timed worked example in C#.

Day 5 — Answer out loud: Technical and Domain Knowledge

• Answer aloud, timed: Explain the MVC architecture in the context of your previous projects.
• Answer aloud, timed: How do you approach database schema design for a high-traffic application?

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

Day 6 — Answer out loud: Coding and Algorithms

• Answer aloud, timed: Write a function to reverse an array or string.
• Answer aloud, timed: Explain the logic behind your implementation of sorting algorithms (e.g., Bubble sort, Merge sort).

Deliverable: Spoken answers to 2 reported Coding and Algorithms question(s), under time.

Day 7 — Answer out loud: Behavioral and Project Experience

• Answer aloud, timed: Walk us through the most challenging technical hurdle you faced in your last project.
• Answer aloud, timed: How do you handle disagreements on technical approaches within a team?

Deliverable: Spoken answers to 2 reported Behavioral and Project Experience question(s), under time.

Behavioural preparation

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

What is your experience with LINQ and Entity Framework?

Medium · Technical and 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 do you handle authentication and security in microservices?

Medium · Technical and 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?

Walk us through the most challenging technical hurdle you faced in your last project.

Medium · Behavioral and Project Experience

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 disagreements on technical approaches within a team?

Medium · Behavioral and Project Experience

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?

Why are you interested in transitioning into a business consulting and software environment?

Medium · Behavioral and Project Experience

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 time you had to learn a new technology on the fly to meet a deadline.

Medium · Behavioral and Project Experience

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?