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. ##### Tip Candidates should demonstrate a strong interest in the human side of technology. At Glints, technical excellence is expected, but the ability to translate business needs into robust code is what truly sets successful engineers apart.
Recruiter Screen
reportedInitial 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
reportedIncludes 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
reportedIn-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
reportedConversation 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?
PracHub editorial advice for the preparation topics above.
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.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Explain the time and space complexity of your solution.
Explain the time and space complexity of your solution.
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.
Describe a challenging technical issue you faced recently and how you resolved it.
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?
What are the trade-offs between using a relational versus a non-relational database for this specific feature?
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?
How would you handle a scenario where a database query is performing slowly under high load?
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
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?
How do you ensure your code is maintainable and scalable?
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
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
bodyinline; the new shape addsbody_refand 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 repurposebodyto 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
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?
Built from the rounds and topics Glints candidates report.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Map 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.
02Work 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).
03Work 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.
04Work 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.
05Answer 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.
06Answer 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.
07Dry 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.
Expand any day for tasks and deliverables. Your progress is saved on this device.
Behavioural rounds judge the decision you made and what it cost.
Tell me about a time you had a disagreement with a team member; how did you reach a resolution?
Tell me about a time you had a disagreement with a team member; how did you reach a resolution?
Approach
- Pick a story where you made the decision, not one where you watched it.
- State the situation in two sentences and spend the rest on the reasoning.
- Give the blast radius: what could have broken, and what you measured.
- 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 tight deadlines when technical debt is piling up?
How do you handle tight deadlines when technical debt is piling up?
Approach
- Pick a story where you made the decision, not one where you watched it.
- State the situation in two sentences and spend the rest on the reasoning.
- Give the blast radius: what could have broken, and what you measured.
- 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 working at Glints specifically?
Why are you interested in working at Glints specifically?
Approach
- Pick a story where you made the decision, not one where you watched it.
- State the situation in two sentences and spend the rest on the reasoning.
- Give the blast radius: what could have broken, and what you measured.
- 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 situation where you had to learn a new technology quickly to complete a project.
Describe a situation where you had to learn a new technology quickly to complete a project.
Approach
- Pick a story where you made the decision, not one where you watched it.
- State the situation in two sentences and spend the rest on the reasoning.
- Give the blast radius: what could have broken, and what you measured.
- 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 balance the need for perfection with the need for speed in a product-focused environment?
How do you balance the need for perfection with the need for speed in a product-focused environment?
Approach
- Pick a story where you made the decision, not one where you watched it.
- State the situation in two sentences and spend the rest on the reasoning.
- Give the blast radius: what could have broken, and what you measured.
- 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?
- 01
Tell me about a time you had a disagreement with a team member; how did you reach a resolution?
- 02
How do you handle tight deadlines when technical debt is piling up?
- 03
Why are you interested in working at Glints specifically?
- 04
Describe a situation where you had to learn a new technology quickly to complete a project.
How long does the entire interview process usually take?
The timeline varies, but generally spans 2 to 4 weeks from the initial screen to the final decision. We strive to keep you updated at every stage.
Glints Software Engineer candidate reports ↗Is live coding always required?
For many roles, yes, you should expect some form of live coding or a technical assignment to demonstrate your problem-solving skills in real-time.
Glints Software Engineer candidate reports ↗What if I don't know the answer to a technical question?
Be honest about your knowledge gaps. We are more interested in your problem-solving process and how you approach learning new concepts than in you having every answer memorized.
Glints Software Engineer candidate reports ↗Can I ask questions about the team's culture?
Absolutely. We encourage you to ask your interviewers about their daily work, how the team handles technical challenges, and how they foster collaboration.
Glints Software Engineer candidate reports ↗What topics does Glints test in interviews?
Glints interviews most often cover Problem Solving, Coding (Algorithmic Problem Solving), SQL (Technical SQL Assessment), SQL, and Mobile Engineering. The exact emphasis depends on the specific role you apply for.
Glints Software Engineer candidate reports ↗Sources & methodology 3 sources ↗
No official company page is cited. Rounds and questions come from candidate reports and PracHub editorial material; each source shows the date it was read.
- 01Glints Software Engineer candidate reports ↗
Company-reported rounds, questions and FAQ.
Candidate reports · Accessed 2026-09-22 - 02PracHub Software Engineer practice ↗
PracHub practice material, not company-reported.
PracHub page · Accessed 2026-09-22 - 03PracHub preparation framework ↗
PracHub preparation guidance.
PracHub page · Accessed 2026-09-22
Explore related engineering environments and compare the preparation focus.
Cognition Software Engineer Interview Guide
What Cognition asks Software Engineer candidates, from reported rounds and questions.
Vercel Software Engineer Interview Guide
Debugging practice for Vercel software engineer prep built on a reproduction you trust, narrowing to the smallest failing input, and changing one variable per run so the result stays attributable.
Together Ai Software Engineer Interview Guide
Failure-handling practice for Together Ai software engineer candidates: requests whose outcome a timeout leaves unknown, where a retry is safe, and deduplicating at the receiver instead of assuming exactly-once delivery.
Spotify Software Engineer Interview Guide
Timed practice for Spotify software engineer candidates who lose time to the clock: short problems taken end to end, then reviewed against a written rubric rather than a passing test run.