Interview guides · Glints

Glints Software Engineer Interview Guide

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

The 60-second brief

As a Software Engineer at Glints, you are at the heart of a platform dedicated to building the professional future of Southeast Asia. You will be tasked with developing scalable, efficient, and user-centric solutions that bridge the gap between top-tier talent and high-growth organizations. Your work directly impacts how millions of users find their next career milestone, making the platform’s performance and reliability a top priority. This role is both technically demanding and strategically significant. You will often operate at the intersection of complex data ecosystems and high-traffic web applications, requiring a balance of architectural foresight and rapid, agile execution. Whether you are optimizing matching algorithms or enhancing core platform features, you are contributing to a mission-driven product that operates at regional scale.

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

Focus areas

Coding (Algorithmic Problem Solving)
Data Structures & Algorithms
Online Programming Tests

The Glints interview process

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

Recruiter Screen

Initial contact to assess your background and interest in the position.

What to demonstrate

Initial contact to assess your background and interest in the position
Depth in Coding (Algorithmic Problem Solving)

How to prepare

Be able to walk your CV end to end in two minutes, and say why this company specifically.
Have your salary expectations, notice period and location constraints ready, and ask for the rest of the loop in writing.

Technical Assessments

Includes a take-home assignment or a live coding session based on team requirements.

What to demonstrate

Includes a take-home assignment or a live coding session based on team requirements
Depth in Coding (Algorithmic Problem Solving)

How to prepare

Answer aloud and timed: Describe a challenging technical issue you faced recently and how you resolved it.
Answer aloud and timed: How do you ensure your code is maintainable and scalable?

Deep-Dive Technical Interviews

In-depth technical discussions with team members to evaluate skills.

What to demonstrate

In-depth technical discussions with team members to evaluate skills
Depth in Coding (Algorithmic Problem Solving)

How to prepare

Answer aloud and timed: What are the trade-offs between using a relational versus a non-relational database for this specific feature?
Answer aloud and timed: Tell me about a time you had a disagreement with a team member; how did you reach a resolution?

Manager Discussion

Conversation with a manager or lead to ensure cultural alignment.

What to demonstrate

Conversation with a manager or lead to ensure cultural alignment
Depth in Coding (Algorithmic Problem Solving)

How to prepare

Answer aloud and timed: How do you handle tight deadlines when technical debt is piling up?
Answer aloud and timed: Why are you interested in working at Glints specifically?

Where candidates lose points

Prioritize clarity

When solving problems, communicate your thought process out loud. It helps the interviewer understand your logic.

Review your resume

Be prepared to dive deep into the specific technologies and projects you have listed.

Ask for feedback

If you feel an interview didn't go well, take it as a learning opportunity; we value candidates who reflect on their performance.

Use the 60 minutes of your technical interview wisely

Dedicate time to understanding the requirements before jumping into implementation.

Questions & practice

Explain the time and space complexity of your solution.

Medium · Technical Fundamentals and Problem Solvi

Approach

Restate the input: its shape, its size, and what is guaranteed about it.
Name the brute-force solution and its complexity before improving on it.
Choose the data structure from the access pattern, not from familiarity.
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 a challenging technical issue you faced recently and how you resolved it.

Medium · Technical Fundamentals and Problem Solvi

Approach

Restate the input: its shape, its size, and what is guaranteed about it.
Name the brute-force solution and its complexity before improving on it.
Choose the data structure from the access pattern, not from familiarity.
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?

What are the trade-offs between using a relational versus a non-relational database for this specific feature?

Medium · Technical Fundamentals and Problem Solvi

Approach

Restate the input: its shape, its size, and what is guaranteed about it.
Name the brute-force solution and its complexity before improving on it.
Choose the data structure from the access pattern, not from familiarity.
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 handle a scenario where a database query is performing slowly under high load?

Medium · Technical Fundamentals and Problem Solvi

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?

Denormalise tenant onto revisions and backfill it live

Hard · denormalisation · online migration · backfill

resource_revision (revision_id, resource_id, version, actor_user_id, change_kind, patch, request_id, created_at) has 400M rows and no tenant column; tenant_id lives only on resource. Two reads need it: a tenant-scoped audit feed ordered by created_at DESC, and an offboarding purge. Both join back to resource today. Justify adding tenant_id to resource_revision against those two reads, name the anomaly the copy introduces and the constraint that prevents it, then give the ordered migration for a live table taking 1.2k writes/second — the lock each step takes, how the backfill is batched, and where each step stops being reversible. PostgreSQL 16.

Approach

Justify from the access path rather than from taste. Without the column, the audit feed either scans resource_revision by created_at and discards other tenants' rows, or resolves the tenant's resource_ids first and probes with them — both proportional to the tenant's whole history rather than to one page. With (tenant_id, created_at DESC, revision_id DESC) it is a seek that stops at 50 rows, and the purge becomes a ranged delete instead of a join.
Name the cost exactly: a second copy of a fact can disagree with the first. Make the disagreement unwritable rather than documented — add UNIQUE (resource_id, tenant_id) on resource so it can serve as a foreign-key target, then FOREIGN KEY (resource_id, tenant_id) REFERENCES resource (resource_id, tenant_id) on the revision table. A revision can then only ever carry its parent's tenant.
Step one, expand: ALTER TABLE resource_revision ADD COLUMN tenant_id BIGINT NULL, with no default, so it is a catalogue change and no rewrite. It still needs ACCESS EXCLUSIVE for an instant, and that instant queues behind the longest open transaction on the table while every later query queues behind it — set lock_timeout to 2s and retry rather than wait.
Step two, dual-write: deploy the writer that populates tenant_id on every new revision while reads still use the join. Reversible by redeploying the previous build, because nothing reads the column yet.

Follow-up

The backfill is half finished and a rollback is required. What state is the table in, and what does the previous build do with a half-populated column?
How do you verify the backfill actually finished, given rows are still being inserted while it runs?

How do you ensure your code is maintainable and scalable?

Medium · Technical Fundamentals and Problem Solvi

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?

Evolve the resource contract without breaking integrations you cannot upgrade

Hard · versioning · backward compatibility · deprecation

GET /v1/resources/{id} returns status from a four-value enum ('draft','active','archived','deleted'), a numeric version, and the body inline. Consumers are a browser app you deploy and roughly 300 server-side integrations, some untouched for two years, that switch exhaustively on status and parse ids as JSON numbers. You must add a 'pending_review' status, move bodies over 256 KB to a body_ref pointer, and expose per-field change history from resource_revision. Specify the compatibility policy, the wire changes, how both generations are served, and the evidence that lets you remove the old shape.

Approach

Write the policy first and date it: fields are added, never retyped or repurposed; consumers ignore unknown fields; an unknown enum value maps to a documented fallback; nothing is removed until telemetry shows no caller reads it. Then say the uncomfortable part out loud - v1 shipped without the unknown-value rule, so 300 running integrations have no fallback, and no server change can install one into code that is already deployed.
That single fact forces per-request negotiation rather than a server-side default. Keep one internal model and select a serialiser from an explicit version in the request, and default a caller that sends nothing to the oldest supported version. Defaulting to the newest is the change that breaks every integration that never asked for anything, on the day you ship.
Downgrade 'pending_review' for old callers to the nearest state they already handle, 'draft', and state the loss explicitly: those integrations cannot see review state and will treat the resource as editable. If that is unacceptable for one integration, the remedy is moving it to the new version, not a cleverer projection - there is no mapping that invents a state the client has no code for.
Make the body change additive. Old callers keep body inline; the new shape adds body_ref and a size field, and resources over the limit are served to old callers by resolving the pointer server-side or by refusing with a documented code, chosen once and published. Never repurpose body to carry the pointer: a client that renders it shows a storage key to a user, and that failure is silent, where a missing field would have been loud. While you are here, serialise BIGINT ids as strings in the new shape - a browser parsing JSON numbers gets IEEE-754 doubles, exact only to 2^53 - and treat that as its own breaking change requiring the same negotiation, not a quiet fix.

Follow-up

An old integration submits a status transition while the resource is really in 'pending_review'. What does the write path accept, and what does it reject?
Two years on you want to delete the v1 serialiser. What evidence makes that safe, and who must be contacted before it happens?

Edge instances grow 400 MB per hour until the nightly restart

Hard · memory leak · heap analysis · metric cardinality

Edge API instances start at 700 MB resident and grow about 400 MB/hour; a nightly rolling restart has hidden it for weeks. Growth continues unchanged when request rate halves overnight, p99 degrades in the last hours before an instance is recycled, and heap used immediately after a forced full GC rises monotonically. The service holds no product state. Name the discriminating measurement that separates the plausible causes, give the most likely cause, and give the fix and how you would verify it.

Approach

Separate resident memory from live heap first, because they fail differently. Resident size can grow from fragmentation, native buffers or thread stacks while the heap is flat; heap used after a full GC rising monotonically is the measurement that says objects are reachable and not being released. You already have it, so this is retention, not fragmentation, and that closes off half the candidate list.
Use the rate's independence from traffic as the discriminator. Growth that continues at half the request rate rules out per-request objects that are merely slow to collect and points at a structure that grows with distinct values observed rather than with call volume. Write the candidates that have that property: a metrics registry keyed on a high-cardinality label, an unevicted cache, an interner, a per-key lock map.
Take two heap snapshots an hour apart and diff by retained size, reading the dominator tree, not by allocation count or instance count. Expect one root holding a map with millions of entries, then follow the reference chain to the code that inserts and never removes. Allocation profilers point at churn, which is the wrong signal here.
The candidate that fits this service is an observability label carrying an identifier, such as a request path recorded before templating so that /v1/resources/48213 becomes its own metric series. That grows with distinct ids seen, is independent of rate, and explains the late p99 degradation, since GC cost rises with the size of the live set.

Follow-up

Post-GC heap is now flat but resident size still creeps. What are you looking at, and does it matter?
How would you have detected this before an OOM, given the nightly restart masked the trend?

Suggested practice checklist

Built from the rounds and topics Glints candidates report.

Day 1 — Map the Glints loop

Write out the reported sequence: Recruiter Screen, Technical Assessments, Deep-Dive Technical Interviews, Manager 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 4 reported rounds, with the weakest marked.

Day 2 — Work Coding (Algorithmic Problem Solving)

Spend the session on Coding (Algorithmic Problem Solving), which Glints candidates report being tested on.
Write one worked example in Coding (Algorithmic Problem Solving) and time yourself on it.

Deliverable: One timed worked example in Coding (Algorithmic Problem Solving).

Day 3 — Work Data Structures & Algorithms

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

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

Day 4 — Work Online Programming Tests

Spend the session on Online Programming Tests, which Glints candidates report being tested on.
Write one worked example in Online Programming Tests and time yourself on it.

Deliverable: One timed worked example in Online Programming Tests.

Day 5 — Answer out loud: Technical Fundamentals and Problem Solving

Answer aloud, timed: Explain the time and space complexity of your solution.
Answer aloud, timed: How would you handle a scenario where a database query is performing slowly under high load?

Deliverable: Spoken answers to 2 reported Technical Fundamentals and Problem Solving question(s), under time.

Day 6 — Answer out loud: Behavioral and Cultural Fit

Answer aloud, timed: Tell me about a time you had a disagreement with a team member; how did you reach a resolution?
Answer aloud, timed: How do you handle tight deadlines when technical debt is piling up?

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

Day 7 — Dry run for Glints

Run one full mock under time, then write down the two questions you most want to ask your interviewers.

Deliverable: A completed timed mock and two questions to ask.