Amtex Systems Software Engineer Interview Guide

The 60-second brief

Candidates place Amtex Systems in consulting and enterprise software, with work that spans multiple products and client problem spaces, so a Software Engineer there moves across several client products. Reported day-to-day work includes taking features from request to production, tuning database queries, building web front ends, writing backend services and APIs, designing schemas, and troubleshooting production issues with SQL against live data. Engineers report collaborating with Project Leads, QA engineers and, at times, client stakeholders, with code review and agile routines as part of the week. On requirements, candidates describe one core language (JavaScript, Java or Python) plus solid SQL, web fundamentals and strong spoken English, usually with 1 to 4 years of experience; BI concepts, AWS or Azure and earlier client-facing services work are listed as a plus.

This guide is for engineers preparing for the Amtex Systems Software Engineer loop, roughly the 1-4 years of experience candidates describe for the role. It covers the four reported stages, worked guidance for all fifteen reported questions (JavaScript runtime and closures, a string-reversal coding task, frontend state, REST versus GraphQL, SQL joins, Star versus Snowflake schemas, query tuning, clustered indexes, production migrations, and five project and behavioural prompts), the mistakes that cost candidates on these question types, and a seven-day plan built around them.

Candidates report four stages over roughly 3-5 weeks: Telephonic Screening, Technical Evaluation, HR Discussion and, when the role is tied to a client project, a Client Interview. Some report fewer stages, or the technical and HR rounds compressed into a single half-day office visit.

Focus areas

• SQL
• Programming Fundamentals
• Asynchronous JavaScript

Overview

Candidates describe the role as client delivery work: one month you may be speeding up a slow report query, the next building a screen in a frontend framework or adding an endpoint to a backend service, often inside a codebase someone else started. The reported questions mirror that spread. They are not contest puzzles; candidates call the technical rounds easy to average and practical, and the weighting across nine reported loops lists SQL, programming fundamentals, asynchronous JavaScript, JavaScript and resume-based questions. So prepare the fundamentals until you can explain them aloud: what the event loop does with a resolved promise, how an anti-join behaves with NULLs, and why a clustered index changes how a range scan reads pages.

SQL deserves more time than its share of the role title suggests. Five of the fifteen reported questions are about databases, spanning a join for unmatched rows, Star versus Snowflake schemas, slow-query tuning, clustered versus non-clustered indexes and production migrations, and candidates report that database questions come up even for frontend-leaning engineers. Other reported examples include finding the second highest salary and designing tables for an e-commerce checkout, so practise writing queries by hand and explaining a schema on a whiteboard, not only reading them.

The JavaScript questions centre on the runtime: asynchronous code, closures and state management in the framework you use. Prepare to predict output order for snippets mixing timers and promises, and to write small functions such as a counter factory or a debounce from memory. If your main language is Java or Python, still learn the JavaScript runtime model, since candidates list asynchronous JavaScript among the most reported topics.

The rest of the loop runs on your resume. Candidates report that interviewers use it to steer the conversation, ask for the architecture and stack of the current project, the candidate's own part in it, the hardest bug and what they would rebuild differently, and that clear spoken English is assessed throughout. Prepare every technology you list to the depth of a follow-up question, and rehearse your project walkthrough aloud until it runs from business problem to architecture to your contribution without hesitation.

The Amtex Systems interview process

The stages below are what candidates describe, not a published process; the count varies with team, location and client, and the Client Interview appears only in some loops.

Telephonic Screening

Candidates describe the first stage as a phone call, sometimes a brief introductory call, covering their background, their availability and whether their technical profile broadly fits the opening. Use it to summarise yourself clearly in English. Have a short spoken introduction ready that names your current project, your main language, your SQL experience and the frameworks on your resume, and know your notice period and location preferences, because candidates report logistics coming up again in later stages.

What to demonstrate

• How your background and resume match the opening
• Availability, notice period and location fit
• High-level alignment with the role's language, SQL and web stack

How to prepare

• A short spoken introduction naming your current project, your main language (JavaScript, Java or Python), your SQL work and your frontend or backend framework
• A defensible one-line answer for every technology on your resume, since candidates report later rounds dig into each one
• Your notice period, preferred office or remote setup and a researched salary range, written down before the call

Technical Evaluation

Candidates report one or two technical rounds, held over Skype or in person at an office, covering programming fundamentals, database knowledge and a detailed discussion of the resume; some also report a basic aptitude test. Candidates rate the difficulty easy to average, with practical concepts rather than contest-style problems. The coding, JavaScript and SQL questions on this page are the types this stage's reported format covers: write correct code for small string and array problems without library shortcuts, explain the event loop and closures accurately, and write joins, aggregations and subqueries by hand. Candidates report the resume discussion as part of this stage, so be ready to go from a technology you list into how it works.

What to demonstrate

• Working code for basic string and array problems in your chosen language
• SQL joins, aggregations, subqueries and indexing knowledge
• JavaScript fundamentals: asynchronous code and closures
• Depth on the technologies and projects listed on your resume

How to prepare

• Hand-write string and array routines (reverse a string, reverse words, palindrome check, second largest value) without library helpers, and state their time and space cost
• Write an anti-join three ways, a second-highest-salary query and a GROUP BY with HAVING on paper, then run them against a small local table
• Rehearse an event-loop ordering snippet and a closure counter until you can explain every line aloud
• If your loop includes the aptitude test, do about 20 timed questions on percentages, ratios, time-and-work and number series, plus a few logical puzzles

HR Discussion

Candidates report that this round covers cultural fit, communication and logistics such as notice period, location and salary expectations, along with questions about the resume and the candidate's reasons for wanting to join. Settle the logistics in your own head beforehand so the conversation does not stall on them. Bring two or three behavioural stories told in clean, structured English, each with a specific situation, what you personally did and a result you can state plainly.

What to demonstrate

• Clarity and structure of spoken answers
• Cultural fit and motivation for joining
• Logistics: notice period, location and salary expectations

How to prepare

• A specific answer to why this company and why services or client work, tied to something real in your background
• Notice period, relocation stance and salary range decided before the round
• Three STAR stories rehearsed aloud: learning a technology under deadline, disagreeing with a Project Lead, and keeping code quality up under pressure

Client Interview

Candidates report this as an occasional final stage. When the role is attached to a particular client project, a conversation with the Project Lead or the client checks that the candidate matches that project's technology stack and workflow. It is a good moment to ask about the stack, the team structure and the project goals. Ask your HR contact which project and stack the role maps to, refresh those exact technologies, rehearse your project walkthrough in that stack's terms, and arrive with questions that show you have thought about joining that particular team.

What to demonstrate

• Fit with the specific project's technology stack
• Fit with the project's workflow

How to prepare

• Ask HR which client project and stack the role is for, then refresh those exact frameworks and tools
• A walkthrough of your current project that a non-specialist can follow, with the architecture flow drawn in a few boxes
• Questions for the Project Lead about the stack, team structure, release process and project goals

Where candidates lose points

Answering the asynchronous JavaScript question with "it runs things in parallel" or getting the order of timer and promise callbacks wrong.

Learn the single-threaded event loop with separate macrotask and microtask queues, and practise predicting output for snippets that mix setTimeout, Promise.resolve().then and async/await until you can explain why the promise callback prints before the timer.

Using NOT IN for the unmatched-records query, or filtering the right-hand table in WHERE so the anti-join returns no rows.

Default to LEFT JOIN ... WHERE right.pk IS NULL or NOT EXISTS, say aloud why NOT IN breaks when the subquery returns NULL, and keep conditions on the right-hand table (status, date) in the ON clause. Run each version against a small table that includes NULLs before the interview.

Calling reverse(), slicing or StringBuilder.reverse() on the reverse-a-string task, or building the result with O(n^2) concatenation.

Practise the two-pointer swap on a character array in your interview language, state O(n) time and space, and test empty, single-character and odd-length inputs aloud. Mention the Unicode surrogate-pair caveat without being asked.

Saying "add an index" to the slow-query question without measuring, or being unable to explain how a clustered index differs from a non-clustered one.

Answer in order: reproduce, read the execution plan, find the expensive node, fix it (index, sargable predicate, rewrite, statistics), re-measure. Pair it with the B+tree picture: one clustered index holds the rows, secondary indexes point back to them.

Listing technologies on the resume that you cannot defend, or describing your current project entirely as "we".

Candidates report that the conversation follows the resume, so cut or qualify anything you could not answer two follow-ups on. Rehearse the project walkthrough in the first person: business problem, architecture flow, your modules, your hardest bug, what you would change.

Questions & practice

Can you explain the concept of asynchronous JavaScript and how it is implemented?

Medium · Core Programming & Web Development

Approach

1. Start with the runtime model: JavaScript runs on one thread with one call stack. The browser or Node supplies timers, network and file I/O; when those finish, their callbacks are queued, and the event loop picks the next one only when the call stack is empty.
2. Separate the two queues. Macrotasks: setTimeout, setInterval, I/O, UI events. Microtasks: promise .then/.catch/.finally callbacks, await continuations, queueMicrotask. The whole microtask queue drains after each macrotask, so console.log('a'); setTimeout(() => console.log('b'), 0); Promise.resolve().then(() => console.log('c')); console.log('d') prints a, d, c, b.
3. Walk the implementation layers: callbacks (nesting and scattered error handling), promises with three states (pending, fulfilled, rejected) and chaining via .then, then async/await as syntax over promises, where await suspends the function and resumes it as a microtask.
4. Cover errors and concurrency: try/catch around await or a .catch on the chain, and no unhandled rejections. Awaiting inside a for loop runs requests one after another; Promise.all runs them together and rejects on the first failure; Promise.allSettled waits for all; Promise.race and Promise.any return the first settled and the first fulfilled.
5. Close with a real example from your code, such as loading a user and their orders in parallel with Promise.all, and add that asynchronous does not mean multithreaded: a long synchronous loop still freezes the page.

Follow-up

• Predict the output order of a snippet that mixes setTimeout, a resolved promise and an async function with an await.
• How would you run 100 fetch calls with at most 5 in flight at once?
• In Node, where do process.nextTick and setImmediate run relative to promise callbacks?

Explain the concept of closures in JavaScript with a practical example.

Medium · Core Programming & Web Development

Approach

1. Definition: a closure is a function together with the variables in scope where it was defined; the function keeps access to them after the outer function has returned, because it holds a reference to that environment, not a copy of the values.
2. Practical example: function makeCounter() { let count = 0; return { increment: () => ++count, get: () => count }; }. Two counters from two calls have separate count variables, and nothing outside can modify count directly, which is how closures give private state.
3. Show uses you have written: function factories, the module pattern, event handlers that remember an id, memoisation caches, and debounce or throttle, where the returned function closes over a timer id.
4. Explain the classic loop bug: for (var i = 0; i < 3; i++) setTimeout(() => console.log(i)) prints 3, 3, 3 because all callbacks share one function-scoped i; using let creates a fresh binding per iteration and prints 0, 1, 2 (an IIFE is the older fix).
5. Note the cost: a closure keeps everything it references reachable, so a long-lived event listener closing over a large object can leak memory until the listener is removed.

Follow-up

• Write a debounce function and point to the variable the closure keeps.
• What does the var loop print, and why does let change the result?
• How can a closure cause a memory leak in a single-page app, and how do you find it?

Diff a projection against the primary without per-row point reads

Hard · reconciliation · range hashing · throttling

The listing projection has drifted and some rows show a stale version. The primary holds 40,000,000 resource rows across 12,000 tenants while serving 1,200 writes and 14,000 reads per second. The obvious repair, reading each resource row and comparing its version against the projection, is correct and would eventually finish. Explain precisely why it is unacceptable here, then give a diff that finds the differing rows, state its complexity, and make it safe to run against a live primary. Replication lag is usually under 100 ms and is not bounded.

Approach

1. Quantify the naive cost rather than calling it slow: 40,000,000 point reads at even 0.5 ms each is over five hours serialised, and the only lever is concurrency, which is exactly what you cannot spend. The primary's pool is sized for the write path, and 40,000,000 random reads evict the buffer cache that sustains the 85 percent cache hit rate, so the audit degrades the system it is auditing.
2. Replace random access with one ordered pass per side. Both sides can be read in (tenant_id, resource_id) order, which is a sequential scan on each and a merge join in O(n) time and O(1) memory. For a dense diff that is the whole answer, and it reads the primary once instead of 40,000,000 times.
3. For the expected sparse case, compare range hashes instead of rows: partition the key space, compute per range an order-independent aggregate over hash(resource_id, version), compare aggregates, and descend only into ranges that differ. With d differing rows and branching factor B, at most d ranges mismatch per level, so the drill-down examines O(d log_B(n/d)) ranges and reads full rows only in mismatching leaves.
4. Aggregate with a sum modulo 2^64 or a multiset hash, never XOR. XOR is order-independent but self-cancelling, so two rows wrong in the same way, or a row duplicated on one side, leave the range aggregate matching and the range is declared clean.

Follow-up

• The diff reports 900 stale rows. How do you decide between patching those rows and rebuilding the projection from resource_revision?
• Same job, but the projection lives in a search index that cannot be scanned in key order. What changes?

Write a SQL query to join two tables and return only the unmatched records.

Medium · Databases & Data Warehousing

Approach

1. Clarify which side's unmatched rows are wanted: rows in A with no match in B, rows in B with no match in A, or both. Use concrete names, for example customers with no orders.
2. Anti-join with a LEFT JOIN: SELECT c.* FROM customers c LEFT JOIN orders o ON o.customer_id = c.id WHERE o.id IS NULL. Test a column from the right table that cannot be NULL in a real match, such as its primary key.
3. Equivalent form: WHERE NOT EXISTS (SELECT 1 FROM orders o WHERE o.customer_id = c.id). Warn against NOT IN (SELECT customer_id FROM orders): if that subquery returns a single NULL, NOT IN returns no rows at all.
4. Both directions: SELECT ... FROM a FULL OUTER JOIN b ON a.id = b.a_id WHERE a.id IS NULL OR b.a_id IS NULL. MySQL has no FULL OUTER JOIN, so UNION a LEFT JOIN with the reversed LEFT JOIN.
5. Edge cases: put any extra condition on the right table, such as o.status = 'paid' or a date range, in the ON clause. In an anti-join, a WHERE o.status = 'paid' alongside o.id IS NULL discards every NULL-extended row, so the query returns no rows at all. NULL join keys never match anything, and an index on orders.customer_id keeps the anti-join from scanning the whole orders table.

Follow-up

• Rewrite it for MySQL to return unmatched rows from both tables.
• Customers with no orders in the last 30 days: where does the date condition go, and why?
• Which index would you add, and how would you confirm the query uses it?

How do you optimize a SQL query that is taking too long to execute?

Medium · Databases & Data Warehousing

Approach

1. Measure before changing anything: confirm the slowness is the query rather than the network or app, then run EXPLAIN (EXPLAIN ANALYZE in PostgreSQL, the actual execution plan in SQL Server) and compare estimated and actual row counts.
2. Read the plan for the expensive node: a full scan of a large table, a nested loop over many rows, a sort or hash spilling to disk, or a key lookup repeated thousands of times.
3. Fix the cause. Add or adjust an index on the WHERE, JOIN and ORDER BY columns, with equality columns before range columns in a composite index and a covering index where it removes lookups. Make predicates sargable: no function wrapped around an indexed column, no wildcard at the start of a LIKE pattern, no implicit type conversion.
4. Rewrite where it helps: select only the needed columns instead of SELECT *, turn a correlated subquery into a join or a pre-aggregated subquery, filter before aggregating, and replace a large OFFSET with keyset pagination (WHERE id > last_id).
5. Check the environment and re-measure: stale statistics (run ANALYZE or update statistics), locks or blocking sessions, then re-run the plan to prove the change worked. State the trade-off: every index slows inserts and updates and takes storage.

Follow-up

• The query uses an index in development but scans the table in production. What could explain that?
• In what order would you put the columns of a composite index for WHERE status = ? AND created_at > ?, and why?
• How would you find which queries are slow in the first place?

Write a program to reverse a string without using built-in methods.

Medium · Core Programming & Web Development

Approach

1. Clarify first: which language, whether the input can be null or empty, and whether Unicode beyond ASCII matters. Then say that strings are immutable in JavaScript, Java and Python, so you will work on a character array or build a new string.
2. Two-pointer swap: copy the characters into an array, set i = 0 and j = length - 1, swap arr[i] and arr[j], move both inward until they meet, then join the array back. O(n) time, O(n) extra space for the array.
3. Alternative: loop from the last index down to 0 and append each character to a result. Note that repeated string concatenation is O(n^2) in Java, so use a char[] or a StringBuilder you fill yourself; do not call StringBuilder.reverse(), Array.prototype.reverse() or Python slicing, since those are the built-ins the question excludes.
4. Test aloud with empty string, one character, even and odd lengths, and spaces. Mention that reversing UTF-16 code units splits emoji and other surrogate pairs; a correct fix iterates by code point (for...of in JavaScript) or by grapheme.
5. A recursive version (reverse(s.substring(1)) + s[0]) is short but uses O(n) stack and copies substrings, so present the iterative one as your answer.

Follow-up

• Reverse the order of words in a sentence in place, keeping each word's characters in order.
• Use the same idea to check whether a string is a palindrome, ignoring case and punctuation.
• How does your function behave with an emoji or an accented character built from two code points?

What are the key differences between REST and GraphQL?

Medium · Core Programming & Web Development

Approach

1. Core model: REST exposes resources at many URLs and uses HTTP verbs and status codes (GET /orders/42); GraphQL exposes one endpoint and a typed schema, and the client sends a query naming exactly the fields it wants.
2. Fetching: REST tends to over-fetch (a fixed response shape) or under-fetch (several round trips to assemble one screen); GraphQL returns one response shaped by the query. On the server, naive GraphQL resolvers cause N+1 database calls, fixed with batching such as DataLoader.
3. Caching and errors: REST GETs cache naturally by URL in browsers, CDNs and proxies; GraphQL usually POSTs to one URL, so caching moves to the client (a normalised cache) or to persisted queries. REST signals failure with status codes; GraphQL often returns 200 with an errors array and partial data, so monitoring must read the body.
4. Evolution and safety: REST versions with /v2 or headers; GraphQL adds fields and marks old ones @deprecated without versioning. GraphQL needs query depth and complexity limits so a client cannot request an enormous nested query.
5. Give a recommendation: REST for simple CRUD, public APIs and heavy HTTP caching; GraphQL when several clients (web, mobile) need differently shaped data from many related entities. Mention which one your current project uses and why.

Follow-up

• Explain the N+1 problem in a GraphQL resolver and how batching fixes it.
• How would you cache GraphQL responses when every request is a POST to the same URL?
• How do you remove a field that old mobile clients still request?

What is the basic difference between a STAR schema and a SNOWFLAKE schema?

Medium · Databases & Data Warehousing

Approach

1. Common ground: both are dimensional models for a data warehouse, with a central fact table holding measures (quantity, amount) at a declared grain (one row per order line) plus foreign keys to dimension tables (date, product, customer, store).
2. Star schema: each dimension is one denormalised table, so product carries its category and department as columns, and every dimension is one join from the fact table.
3. Snowflake schema: dimensions are normalised into sub-tables (product links to category, which links to department), which removes repeated text but adds joins to every query that groups by those levels.
4. Trade-offs: star means simpler SQL for BI tools, fewer joins and usually faster queries, at the cost of redundancy and harder updates to a hierarchy; snowflake saves storage and keeps hierarchies consistent, at the cost of query complexity. Many teams default to star and snowflake only very large or shared dimensions.
5. Draw a small sales example on the whiteboard, and mention surrogate keys plus a slowly changing dimension (Type 2: a new row with valid-from and valid-to dates when a customer moves) to show you have used these models, not just memorised the definition.

Follow-up

• What is the grain of your fact table, and what goes wrong when two grains are mixed in one table?
• How would you keep a customer's history when their city changes?
• Given a sales dataset, which tables are facts and which are dimensions?

Explain the difference between clustered and non-clustered indexes.

Medium · Databases & Data Warehousing

Approach

1. Clustered index: the table's rows are stored in the order of the index key; in SQL Server and MySQL InnoDB the leaf pages of the clustered B+tree are the data rows. There can be only one per table, and it is usually the primary key.
2. Non-clustered index: a separate B+tree whose leaves hold the indexed columns plus a pointer to the row (a row id on a heap, or the clustering key in InnoDB and in clustered SQL Server tables). A table can have many, and a match that needs other columns costs an extra lookup into the table.
3. Consequences for reads: range scans and ORDER BY on the clustered key read adjacent pages, which is efficient; a non-clustered index that includes every column a query needs (a covering index, or INCLUDE columns in SQL Server) avoids the lookup entirely.
4. Consequences for writes: a random clustered key such as a GUID causes page splits and fragmentation on insert, while an ever-increasing key appends at the end; a wide clustered key is copied into every secondary index and makes them larger.
5. Mention PostgreSQL as the contrast: tables are heaps and every index is secondary; the CLUSTER command reorders rows once but the order is not maintained afterwards.

Follow-up

• Which column would you choose as the clustered key for an orders table, and why?
• What is a covering index, and when is it worth the extra write cost?
• Why can a GUID primary key slow down inserts?

How would you handle database migrations in a production environment?

Medium · Databases & Data Warehousing

Approach

1. Process: every schema change is a versioned migration script in source control, applied by a migration tool (Flyway, Liquibase, Alembic, Django or Rails migrations, EF Core) that records which versions ran, executed by the deployment pipeline rather than by hand, and tested first on a staging copy with production-sized data.
2. Backward compatibility: during a rolling deploy, old and new application versions run against the same schema, so each migration must work with both. Use expand and contract: add the new column or table, deploy code that writes to both, backfill, switch reads, and drop the old structure in a later release.
3. Locking and size: some ALTER TABLE operations rewrite or lock a big table, so use online options (CREATE INDEX CONCURRENTLY in PostgreSQL, online DDL in MySQL or SQL Server), add columns as nullable first, and backfill in small batches with commits between them.
4. Safety net: take a backup or snapshot before risky changes, keep each migration small and single-purpose, and decide in advance between a down migration and a fix-forward migration, because dropping a column cannot be undone without the data.
5. Give an example from your own work, such as splitting a name column into first and last name across two releases, and say what you checked after deploying.

Follow-up

• How would you rename a column with no downtime?
• A migration fails halfway through in production. What do you do?
• How do you keep migrations in order when two developers add one on separate branches?

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

1. 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.
2. 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.
3. 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.
4. 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

Each day targets a group of this guide's reported questions, ordering topics from fundamentals (JavaScript, coding, SQL, database design, web and API topics) to the project and behavioural stages.

Day 1 — JavaScript runtime: the event loop and closures

• Write five short snippets mixing setTimeout, Promise.resolve().then, async/await and synchronous logs; predict each output order on paper, then run them in a browser console or Node.
• Rewrite one callback-based function as a promise and then with async/await, and convert a sequential await loop into Promise.all; note what changes when one request fails.
• From memory, write a closure-based counter factory and a debounce function, then explain the var versus let loop bug aloud.

Deliverable: Five annotated output-order snippets, one function in three styles, and a working counter and debounce with a spoken explanation of each.

Day 2 — Coding fundamentals without built-ins, plus aptitude practice

• Write the string reversal twice in your interview language (two-pointer swap and backward build) with no library reverse, and state the time and space for each.
• Solve three neighbouring problems the same way: reverse the words in a sentence, check a palindrome ignoring punctuation, and find the second largest number in an array in one pass.
• Test every function aloud with empty input, one element, duplicates and a string containing an emoji.
• Do a timed set of about 20 aptitude questions on percentages, ratios, time-and-work and number series, plus a few logical puzzles, in case your loop includes the aptitude test.

Deliverable: Five hand-written functions with complexity notes, a list of the edge cases each one handles, and a scored timed aptitude set.

Day 3 — SQL by hand: joins, anti-joins and aggregates

• Create two small tables locally (customers and orders, with a NULL customer_id row) and write the unmatched-records query as a LEFT JOIN, NOT EXISTS and NOT IN; record which one breaks and why.
• Write the both-sides version with FULL OUTER JOIN and the MySQL equivalent with UNION.
• Write the second-highest salary query two ways (a subquery with MAX, and DENSE_RANK) plus a GROUP BY with HAVING, and check duplicate salaries and ties.

Deliverable: A tested SQL file covering every anti-join variant, the second-highest-salary query and an aggregate, with a comment on each NULL or tie case.

Day 4 — Database design, indexing and tuning

• Draw a sales Star schema (fact plus date, product, customer and store dimensions), then convert the product dimension to Snowflake form and list what each costs in joins and redundancy.
• Load a few hundred thousand rows into a local table, run EXPLAIN on a slow filtered query, add a composite index, and capture the plan before and after.
• Explain clustered versus non-clustered indexes with a B+tree sketch, including a covering index and why a GUID clustered key hurts inserts, then outline tables for an e-commerce checkout.

Deliverable: Two schema diagrams, before-and-after query plans with the index that fixed them, an index sketch and a checkout table outline.

Day 5 — Frontend state, APIs, page speed and production migrations

• For the framework on your resume, write out where each kind of state lives in your current project (local, shared, global, server cache) and one decision you would defend.
• Build a REST versus GraphQL comparison table covering fetching, caching, errors, versioning and the N+1 problem, ending with when you would pick each.
• Profile a slow page in browser DevTools (network waterfall, Lighthouse), then prepare an answer to optimizing a slow-loading web page: bundle splitting, lazy loading, image compression, caching headers, and fixing the slow API or SQL calls behind it.
• Outline an expand-and-contract migration that renames a column with no downtime, including the backfill and the release in which the old column is dropped.

Deliverable: A state map of your project, a REST versus GraphQL table, a profiled page with an optimization checklist and a step-by-step zero-downtime migration outline.

Day 6 — Project deep-dive and code quality

• Draw your current project's architecture in a few boxes and rehearse the walkthrough aloud in the first person: problem, flow, stack choices, your modules, hardest bug, what you would rebuild.
• Go through your resume line by line and write two likely follow-up questions under each technology; remove or qualify anything you cannot answer.
• Prepare the code-quality answer with one real example each for tests, code review and tooling.

Deliverable: An architecture diagram, a recorded walkthrough, an annotated resume and a code-quality answer backed by three examples.

Day 7 — Behavioural, HR and client stages

• Write and rehearse STAR stories for learning a technology under deadline and for disagreeing with a Project Lead, then explain one recently learned concept to a non-technical friend and note where they got lost.
• Settle your notice period, location stance and salary range, and write a specific answer to why this company and why client work.
• Write five questions for a Project Lead or client about the stack, team structure, release process and project goals, and confirm the schedule and format of each round with HR.

Deliverable: Two rehearsed STAR stories, a tested plain-language explanation, written logistics answers and a list of questions for the Client Interview.

Behavioural preparation

Candidates report that the HR round focuses on communication, fit, motivation and the resume, that the Client Interview checks fit with a specific project, and that spoken English is assessed throughout. For a client-services engineer that means stories showing you can pick up an unfamiliar stack quickly, handle disagreement with a Project Lead professionally, and explain technical work to people who do not code.

1. If you could rebuild your last project from scratch, what architectural decisions would you change?

How do you handle state management in the frontend framework you are most familiar with?

Medium · Core Programming & Web Development

Approach

1. Treat this as a technical question about your own framework, not a story. Open with the categories of state and where each belongs: local UI state inside a component, state shared by a few components lifted to their nearest common parent, app-wide state that changes rarely (theme, logged-in user) in a context or provider, and complex shared client state in a store.
2. Name the tools you have actually used and why: for example useState/useReducer and Context in React, Redux Toolkit or Zustand for a store, NgRx or services with observables in Angular, Pinia in Vue. Explain one decision from a real project, such as moving cart data into a store because several screens edited it.
3. Separate server state from client state: data fetched from an API is a cache with loading, error and staleness concerns, handled well by a query library (React Query, SWR, RTK Query) instead of being copied into a global store by hand.
4. Cover the rules that prevent bugs: keep state minimal and compute derived values instead of storing them, update immutably so change detection and re-renders work, and normalise lists by id so one record is not duplicated across the tree.
5. State the trade-off: a global store adds boilerplate and indirection, while Context re-renders every consumer on each change, so split contexts or use selectors when updates are frequent.

Follow-up

• Why might a component re-render too often when it reads from Context, and how would you fix it?
• Where would you keep form state for a multi-step form, and how do you handle validation?
• After a successful update call, how does the rest of the UI learn that its cached data is stale?

Walk me through the current project you are working on, detailing the tech stack and your specific role.

Medium · Project Deep-Dive & Behavioral

Approach

1. Open with the business problem in two sentences: who the users or client are and what the system does for them. Then trace the architecture end to end, for example browser to frontend framework to REST API to service layer to database, plus any queues, caches, third-party integrations and the cloud it runs on.
2. Name the stack and justify each choice you can defend: why that framework, why that database, why that hosting. Candidates report technology justification being covered, so mark anything you only used lightly as such rather than overclaiming it.
3. Spend most of the answer on your own role, in the first person: the modules or features you built, the queries you tuned, the tickets you owned, and how you worked with the Project Lead, QA and the client.
4. Prepare one hard problem in detail: the symptom, how you narrowed it down (logs, query plans, reproduction), the fix and how you confirmed it. Add one result you can state plainly, such as a page that went from slow to usable or a defect class that stopped recurring.
5. Finish with what you would change if you rebuilt it, which candidates report as a follow-up topic. The mistake that sinks this answer is saying "we" throughout, so nobody can tell what you did.

Follow-up

• Why did the project choose that database or framework over the alternatives?
• What was the hardest bug you fixed on it, and how did you find the cause?
• If you could rebuild it from scratch, which architectural decision would you change?

Tell me about a time you had to learn a new technology quickly to meet a project deadline.

Medium · Project Deep-Dive & Behavioral

Approach

1. Pick a real case with a concrete deadline and a technology you did not know, ideally one a client project required. Set up the situation and the stakes in two or three sentences.
2. Show your learning method, since that is the point of the question: official documentation and tutorials for the core model, a small throwaway spike to test the parts the feature needed, reading how the existing codebase already used it, and asking a colleague to review your first pull request.
3. Show how you protected the deadline: you scoped down to what the feature needed, flagged risk to the Project Lead early instead of at the end, and kept the unfamiliar code covered by tests.
4. State the outcome plainly (delivered on time, or what slipped and why) and what you now do differently when picking up something new.
5. Mistakes that sink it: a vague claim that you are a fast learner with no method, or a story where the shortcut you took later broke production and you do not acknowledge it.

Follow-up

• How did you check that you were using the technology correctly and not just making it work?
• What would you have done with half the time?
• What did you get wrong at first, and how did you find out?

How do you ensure the quality and maintainability of your code?

Medium · Project Deep-Dive & Behavioral

Approach

1. Answer with concrete practices and one example of each, not a list of virtues. Testing: unit tests for business logic, integration tests for database and API boundaries, and a test written to reproduce every bug before fixing it.
2. Review and automation: what you check when reviewing others' code (naming, edge cases, error handling, queries inside loops), and what you let tools enforce: linters and formatters (ESLint and Prettier, Checkstyle, Black), type checking (TypeScript, static analysis), and CI that blocks a merge when checks fail.
3. Design habits: small functions with one job, meaningful names, no copy-pasted logic, configuration kept out of code, and short comments or a README note that record why a decision was made, not what the code already says.
4. Tie it to a real moment: a bug a test caught before release, a review comment that changed your approach, or a refactor you made safe by adding tests first.
5. Acknowledge the trade-off under client deadlines: what you would not skip (tests on the risky path, review) and what you would defer and record as follow-up work.

Follow-up

• What do you deliberately not test, and why?
• How do you work in a legacy module that has no tests at all?
• Tell me about a review comment you disagreed with.

Describe a situation where you disagreed with a Project Lead's technical decision. How did you handle it?

Medium · Project Deep-Dive & Behavioral

Approach

1. Choose a technical disagreement with real stakes, such as a library choice, a schema design or an estimate, where you had a reason grounded in evidence rather than taste. Describe the Project Lead's position fairly before your own.
2. Show how you raised it: privately or in the right forum, with evidence (a quick benchmark, a prototype, a reported defect, the client's requirement) and with an alternative, not just an objection.
3. Show the resolution: either the lead changed course because of your evidence, or the lead kept the decision for reasons you had not weighed (client constraints, timeline) and you committed to it fully. Both are good stories if you describe them honestly.
4. Close with the result and the working relationship afterwards, and what you learned about raising concerns earlier or differently.
5. Mistakes that sink it: a story that makes the lead look foolish, going over the lead's head without first talking to them, or a disagreement with no resolution.

Follow-up

• What if you had been wrong?
• What would you have done if the lead had refused to discuss it?
• How would you handle the same disagreement if it were the client's decision?

Explain a complex technical concept you recently learned to someone without a technical background.

Medium · Project Deep-Dive & Behavioral

Approach

1. Pick a concept you really did learn recently and can explain accurately, such as database indexing, caching, asynchronous requests or API rate limiting. Name the listener you have in mind, for example a client stakeholder or a manager who does not code.
2. Lead with why it matters to that listener (speed, cost, reliability), then give one analogy and keep it technically honest: an index is like a book's index that lets you jump to the right page instead of reading every page, at the cost of updating the index whenever a page changes.
3. Avoid jargon or define it in passing, keep it short, and check understanding by asking what they would expect to happen in a related case.
4. Since candidates report that spoken English and clarity are assessed throughout, rehearse this aloud and time-box it, then be ready to switch to the full technical version on request.
5. Mistakes that sink it: an analogy that teaches something false, explaining at length without checking whether the listener follows, or choosing a concept you cannot explain technically when pushed.

Follow-up

• Now explain the same concept to an engineer, in full technical detail.
• Where does your analogy break down?
• How would you explain to a client why a feature they want will take longer than they expect?