cswork / libraryOpen practice workspace

Interview guides · Visa2Fly

Visa2Fly Software Engineer Interview Guide

Visa2Fly Software Engineer interview guide: reported rounds, questions and how candidates describe the process.

The 60-second brief

As a Software Engineer at Visa2Fly, you are at the heart of simplifying the complex world of global travel. You will be building and maintaining the robust digital infrastructure that allows users to navigate visa requirements, documentation, and travel logistics seamlessly. Your work directly impacts how thousands of travelers interact with international borders, making travel more accessible and friction-free. The role demands a strong grasp of core computer science principles and a dedication to writing clean, scalable Java code. You will collaborate with cross-functional teams to translate travel-tech requirements into high-performance backend services. This position is critical to Visa2Fly because the reliability of your code determines the success of critical user journeys, from application submissions to real-time status updates.

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

Focus areas

  • Java Core
  • Data Structures & Algorithms (DSA)
  • JVM vs JDK vs JRE (Conceptual Differences)

The Visa2Fly interview process

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

Initial Interview

Candidates often secure their initial interview by reaching out to recruiters directly.

What to demonstrate

  • Candidates often secure their initial interview by reaching out to recruiters directly
  • Depth in Java Core

How to prepare

  • Answer aloud and timed: Solve an easy-level problem involving array manipulation or string processing.
  • Answer aloud and timed: Explain the time and space complexity of your chosen approach.

Technical Round 1

First round focusing on technical competence and core engineering concepts.

What to demonstrate

  • First round focusing on technical competence and core engineering concepts
  • Depth in Java Core

How to prepare

  • Answer aloud and timed: Optimize a brute-force solution to improve performance.
  • Answer aloud and timed: Explain the difference between JDK, JRE, and JVM.

Technical Round 2

Second round that dives deeper into technical skills with hands-on coding tasks.

What to demonstrate

  • Second round that dives deeper into technical skills with hands-on coding tasks
  • Depth in Java Core

How to prepare

  • Answer aloud and timed: How do abstraction and interfaces differ in their use cases?
  • Answer aloud and timed: Describe the lifecycle and importance of threads in Java.

Where candidates lose points

Think Aloud

During coding rounds, walk the interviewer through your thought process; they are interested in how you approach a problem, not just the final code.

Know the Basics

Don't skip the "easy" theory questions; interviewers use these to gauge your depth of knowledge and attention to detail.

Be Proactive

If you are in the process of applying, reaching out to recruiters can help you stand out and get a better understanding of the current team needs.

Practice Mock Interviews

Simulate the 70-minute technical round format to get comfortable with the pacing and pressure.

Questions & practice

Solve an easy-level problem involving array manipulation or string processing.

Medium · Data Structures 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 time and space complexity of your chosen approach.

Medium · Data Structures 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?

Optimize a brute-force solution to improve performance.

Medium · Data Structures 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?

Describe the lifecycle and importance of threads in Java.

Medium · Core Java Fundamentals

Approach

  1. Say what the runtime actually does before reasoning about the code.
  2. Name what is shared across threads and what owns each piece of state.
  3. Identify the window where an invariant is briefly untrue.
  4. Distinguish a value from a reference to it, and say which one you handed out.

Follow-up

  • What happens if two callers reach this at the same time?
  • Where could this allocate more than you expect?

Explain the basics of SQL queries.

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

Replace offset paging on the resource feed with keyset

Easy · keyset pagination · composite index · sort order

resource holds resource_id, tenant_id, owner_user_id, title, body_ref, version, status ('draft','active','archived','deleted'), created_at, updated_at, deleted_at, with an index on (tenant_id, status, updated_at DESC, resource_id DESC). The listing endpoint returns active resources for one tenant, newest update first, 50 per page, today with LIMIT 50 OFFSET n. Tenants reach page 400 and rows are created while they read. Write the keyset query, define what the cursor carries and how it is encoded, and say which part of the index each predicate uses. Assume PostgreSQL 16.

Approach

  1. Name the two failures separately. OFFSET 20000 makes the server produce and discard 20,000 rows, so page cost grows with depth rather than with page size. Independently, any write that changes how many rows sort above the offset moves the window between two fetches, and the direction decides which anomaly you get: an insert lands at the head of updated_at DESC and pushes already-returned rows down past the boundary, so they are returned a second time; a delete above the offset, or a row whose updated_at is bumped above the cursor, pulls rows up and one is never returned at all. Nothing in the response reveals either.
  2. Write the seek: WHERE tenant_id = $1 AND status = 'active' AND (updated_at, resource_id) < ($2, $3) ORDER BY updated_at DESC, resource_id DESC LIMIT 50. The row-value comparison is one index range rather than a disjunction, and both columns are NOT NULL, which is what makes that comparison well defined.
  3. Map each predicate onto the index: tenant_id and status are equality on the leading columns, (updated_at, resource_id) is the range, and the ORDER BY matches the index order so no Sort node appears and the scan stops after 50 rows. The DESC in the definition only matters for mixed directions — a plain ascending btree on the same columns is read backwards for this query.
  4. Put both sort columns in the cursor and nothing the client can tamper with into another tenant: base64 of (updated_at, resource_id), validated server-side, with tenant_id taken from the principal.

Follow-up

  • The client asks for 'jump to page 400'. What do you offer instead, and what does the honest version cost?
  • Sort order becomes user-selectable across four columns. How many indexes is that, and which would you refuse to add?

Explain the difference between JDK, JRE, and JVM.

Medium · Core Java Fundamentals

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 abstraction and interfaces differ in their use cases?

Medium · Core Java Fundamentals

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 is the difference between an abstract class and an interface?

Medium · Core Java Fundamentals

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?

p99 jumped on one listing filter while p50 stayed flat

Medium · query planning · composite index · percentiles

After a release that added an owner_user_id filter to the resource listing, p99 rose from 90 ms to 1.9 s while p50 stayed at 40 ms. Traffic and row counts are unchanged. resource carries the index (tenant_id, status, updated_at DESC, resource_id DESC). The new query filters tenant_id and owner_user_id, orders by updated_at DESC, resource_id DESC, and takes 20 rows. On PostgreSQL, explain the shape of the regression, prove it from a query plan, and give the index you would add.

Approach

  1. Start from the shape. A flat p50 with a moved p99 means a subset of requests changed cost, not all of them, so the first job is naming the subset. Bucket the endpoint's latency by the tenant's row count; the natural hypothesis is that large tenants are a small share of requests and all of the tail.
  2. Get the plan for the new query on a large tenant with EXPLAIN (ANALYZE, BUFFERS). Expect an index scan over the tenant's range, a filter discarding most of it, then a Sort feeding the Limit, possibly reporting Sort Method: external merge Disk. Read actual rows on the scan node, not estimated.
  3. Explain why the existing index cannot serve it. A composite B-tree is seekable only as a left prefix, and with no equality predicate on status the scan cannot treat updated_at as an ordering, because rows in the tenant's range are ordered by status first. Everything matching must be read and sorted before LIMIT 20 can apply, so a tenant with 400,000 rows pays 400,000 rows to return 20.
  4. Add (tenant_id, owner_user_id, updated_at DESC, resource_id DESC). Equality on the first two columns leaves the index ordered by updated_at within that pair, so the plan becomes an index scan that stops after 20 rows with no Sort node. PostgreSQL can scan a B-tree backwards, so the DESC markers matter only if the two sort columns ever disagree in direction; keeping them explicit documents the order the keyset cursor depends on.

Follow-up

  • The endpoint paginates with OFFSET. What does page 500 cost with your index, and what does the keyset version cost?
  • How would you have caught this before release, given that a 10,000-row seed database produces the same plan shape at an unnoticeable cost?

Suggested practice checklist

Built from the rounds and topics Visa2Fly candidates report.

Day 1 — Map the Visa2Fly loop

  • Write out the reported sequence: Initial Interview, Technical Round 1, Technical Round 2.
  • 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 Java Core

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

Deliverable: One timed worked example in Java Core.

Day 3 — Work Data Structures & Algorithms (DSA)

  • Spend the session on Data Structures & Algorithms (DSA), which Visa2Fly candidates report being tested on.
  • Write one worked example in Data Structures & Algorithms (DSA) and time yourself on it.

Deliverable: One timed worked example in Data Structures & Algorithms (DSA).

Day 4 — Work JVM vs JDK vs JRE (Conceptual Differences)

  • Spend the session on JVM vs JDK vs JRE (Conceptual Differences), which Visa2Fly candidates report being tested on.
  • Write one worked example in JVM vs JDK vs JRE (Conceptual Differences) and time yourself on it.

Deliverable: One timed worked example in JVM vs JDK vs JRE (Conceptual Differences).

Day 5 — Answer out loud: Data Structures and Algorithms

  • Answer aloud, timed: Solve an easy-level problem involving array manipulation or string processing.
  • Answer aloud, timed: Explain the time and space complexity of your chosen approach.

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

Day 6 — Answer out loud: Core Java Fundamentals

  • Answer aloud, timed: Explain the difference between JDK, JRE, and JVM.
  • Answer aloud, timed: How do abstraction and interfaces differ in their use cases?

Deliverable: Spoken answers to 2 reported Core Java Fundamentals question(s), under time.

Day 7 — Answer out loud: Database and System Knowledge

  • Answer aloud, timed: Explain the basics of SQL queries.
  • Answer aloud, timed: How do you handle data consistency in a backend environment?

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

Behavioural preparation

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

How do you handle data consistency in a backend environment?

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

Tell callers you do not own that their integration breaks

Medium · deprecation · compatibility · stakeholders

A field in a write endpoint's response must change shape. You own the endpoint; you do not own the four internal callers or the outbound webhook consumers who read it. Describe a deprecation you were responsible for: what you shipped first, how you established who was actually reading the field, the window you gave and what set its length, what you did about the consumer who never moved, and how you decided removal was safe. Name the signal you used, not the announcement you sent.

Approach

  1. Establish the reader set empirically rather than from a wiki of owners: per-field usage counters keyed by principal, or access logs attributed to a consumer. State the blind spot of whichever you pick, since a consumer that reads the field only on a monthly job will not appear in a week of logs.
  2. Ship additive first. Populate the new field alongside the old one so no reader is forced to move, which is also what keeps a rolling deploy safe, because old and new instances answer the same requests at the same time and a rollback must still find the old shape present.
  3. Set the window from the slowest legitimate consumer's release cadence, not from your calendar, and decide separately what to do for a consumer with no release process at all, such as an external webhook endpoint you can only email.
  4. Convert silence into evidence before you rely on it: a short, low-traffic removal window that makes a still-dependent consumer fail visibly and loudly while you are watching, rather than at three in the morning after you have moved on.

Follow-up

  • How would you detect a consumer that reads the field only during a monthly export?
  • One caller refuses to move and has a commercial relationship behind it. What changes in your plan and what does not?

Unblock an engineer without taking the keyboard

Easy · mentoring · leases · at-least-once

A teammate has spent two days on a job handler that occasionally writes duplicate rows. They are certain the queue is delivering twice by mistake. You suspect a lease expiring under a slow handler, so the job is running concurrently with itself. Describe how you have unblocked someone in this position: what you asked before offering a hypothesis, what you showed them rather than told them, and what you left them owning. Then say what you would do if their theory turned out to be the right one.

Approach

  1. Ask before diagnosing, and ask for things answerable from data they already have: the attempt count on the job rows that produced duplicates, the handler's observed duration against its lease expiry, and whether the duplicate rows share a natural key that a unique constraint could have caught.
  2. Teach the shape rather than the answer. A lease cannot distinguish a dead worker from a slow one, so a handler that outruns its lease is running twice by design, and deploys deliver the other half by killing handlers mid-run on every rollout. Both of their candidate theories produce identical duplicate rows, which is why the evidence has to come from timings rather than from argument.
  3. Hand over a checklist they execute: a natural key on every write the handler performs so the second copy collides rather than appends, the record of intent written before any external effect, a lease heartbeat while running, and the metric that shows it working.
  4. Keep ownership with them deliberately. Pair on the first write, then step back; if you finish it yourself you have closed one ticket and left the same person stuck on the next redelivery.

Follow-up

  • How would you distinguish a genuine double-delivery from a lease expiry using only the data already stored?
  • Their handler calls an external endpoint before recording that it did. What do you tell them to change first?