Alcor Software Engineer Interview Guide

The 60-second brief

Candidates describe Alcor as a consulting-style employer that designs, builds and maintains enterprise solutions on the ServiceNow platform for clients. The work named in the reports spans HR service delivery (HRSD), IT operations management (ITOM) and general software development on the platform. In this role you turn business requirements into working configuration and custom scripts, test them, and hand them over in a form other developers and the client can maintain.

This guide is for engineers preparing for the Alcor Software Engineer loop, particularly those with ServiceNow experience in HRSD or ITOM. It covers the four reported rounds, the twelve questions candidates report (platform scripting, update sets, debugging, integrations, design trade-offs and behavioral prompts), and a plan for rehearsing them. It does not cover other Alcor roles.

Candidates report four rounds over roughly three to five weeks: Initial Screening, Technical Assessments, Engagement with Senior Team and Final Leadership Interviews. These stages are candidate-described, not a published process.

Focus areas

• ServiceNow Development
• ITOM (IT Operations Management)
• HRSD (Human Resources Service Delivery)

Overview

The role, as candidates and the listed requirements describe it, is platform engineering for clients. You clarify scope with functional consultants and project managers, configure the ServiceNow platform, write custom scripts, unit test your own work, and take part in peer reviews and technical design sessions. You are also expected to add to the team's shared knowledge of best practice. The listed must-haves are JavaScript, ServiceNow experience in HRSD or ITOM, and a working grasp of the software development lifecycle. Certifications, REST or SOAP integration experience and earlier client-facing work are listed as extras.

The reported questions follow that shape. Several are platform-knowledge questions: how Business Rules differ from Client Scripts, why Update Sets matter when several developers share an instance, what to weigh when designing a custom application. Others are working-method questions: debugging a script that slows the system, tuning work on large ITOM datasets, integrating an external API, keeping code maintainable through platform upgrades. The remainder are behavioral: ambiguous requirements, explaining a technical issue to a non-technical stakeholder, prioritizing competing tickets, and disagreeing with a colleague's technical decision.

Candidates' tips add two themes. First, favor out-of-the-box features before custom development, and be able to justify any customization. Second, explain your reasoning aloud, because the path to an answer matters as much as the answer. The evaluation areas candidates list are platform development (scripting standards, Business Rules, Script Includes, UI Policies, Workflows, REST and SOAP integration) and system architecture (maintainability, performance tuning, ACLs, upgrade-safe structure, handoff documentation).

For preparation, this means depth on a narrow stack rather than breadth across computer science. The reports list no algorithm puzzles, so spend most of your time on platform mechanics and on rehearsing decisions with trade-offs: why a server-side rule instead of a client script, why configuration instead of code, why a scheduled batch instead of an inline query. Then build a bank of first-person stories from real projects, since the later rounds are described as senior-team scenarios and leadership conversations.

The Alcor interview process

Candidates report these four stages in this order, over roughly three to five weeks. Treat the descriptions as what candidates say, and ask the recruiter to confirm format and interviewers for your own loop.

Initial Screening

Candidates describe the Initial Screening as the opener, where the conversation is about your background and your interest in the role. The requirements list JavaScript, ServiceNow work in HRSD or ITOM, and SDLC knowledge, so expect your history to be read against them. Approach it as a short, structured account of what you built, on which modules, and why this role appeals to you.

What to demonstrate

• Your background and how it lines up with the listed requirements
• Your interest in the position
• Which ServiceNow modules (HRSD or ITOM) you have worked in

How to prepare

• Write a two-minute career walk-through that names the ServiceNow modules you used, the scripts or integrations you built, and your own part in each.
• Prepare one specific reason for wanting a client-facing platform role, and a short list of questions about how projects are staffed and reviewed.
• Confirm in writing what the later rounds will look like, so you can prepare for the format.

Technical Assessments

Technical Assessments are described as a hands-on check of development skills through practical application. The reported platform and working-method questions are the natural material for this stage: how server-side and client-side logic differ, how to manage Update Sets with several developers, how to find the cause of a slow script. Approach it by practicing with real code and configuration, not by reciting definitions.

What to demonstrate

• Hands-on development skill applied to practical problems
• Working JavaScript and use of platform components
• How clearly you explain choices while you work

How to prepare

• Write small server-side and client-side scripts from memory, and state for each where it runs and what event triggers it.
• Rehearse a repeatable debugging sequence for slow scripts: reproduce, measure, isolate, change one thing, re-measure.
• Be ready to describe an Update Set workflow for a shared instance, including how you spot and resolve collisions before moving changes between instances.

Engagement with Senior Team

Engagement with Senior Team is described as working through real-world scenarios with senior colleagues. Scenario prompts candidates quote elsewhere include migrating a legacy process to a new module and finding why a dashboard loads slowly. Approach this stage by thinking aloud: state assumptions, name the options, pick one and say what it costs.

What to demonstrate

• How you handle realistic project scenarios
• How you reason about design and trade-offs in front of senior people
• How you communicate when the requirement is not fully defined

How to prepare

• Practice scenario answers in a fixed order: clarify the goal, list constraints, name two options, choose, then say how you would verify the result.
• Prepare a design checklist for a custom application: data model, access control, upgrade impact, performance, and who maintains it afterwards.
• Have a story ready about turning a vague requirement into something buildable.

Final Leadership Interviews

Final Leadership Interviews close the loop and are described as focused on leadership and fit. Because the role is client-facing and the requirements stress communication and working under deadlines, this is the stage for your behavioral stories. Approach it with a short, honest set of examples in which you made the decisions.

What to demonstrate

• Leadership and fit with the team
• How you describe your own decisions and results
• Communication with non-technical people

How to prepare

• Choose three stories from your bank: one on ambiguity, one on disagreement, one on explaining a technical issue to a non-technical stakeholder.
• Prepare an honest account of the out-of-the-box versus custom decision, with a real project where you made the call.
• Write down questions for the leaders you meet, for example how the team handles platform governance and review.

Where candidates lose points

Defining Business Rules and Client Scripts by name only, with no sense of where each runs or when it fires.

State that Business Rules run on the server around database operations (before, after, async, display) and Client Scripts run in the browser (onLoad, onChange, onSubmit, onCellEdit). Add that browser-side checks can be bypassed, so rules that must hold belong on the server.

Answering the custom-versus-out-of-the-box question with an absolute: always customize, or never customize.

Candidates' tips say to favor out-of-the-box features first. Give a decision test instead: does configuration meet the requirement, what does customizing cost at upgrade time, and who maintains it. Back it with a project where you applied that test.

Debugging a slow script by guessing at the cause and changing several things at once.

Reproduce it, measure where the time goes, isolate one suspect such as a query inside a loop, change one thing, and measure again. Say aloud what each step would rule out.

Walking through an API integration that covers only the successful call.

Cover authentication and where credentials are stored, field mapping, error handling, retries that cannot double-apply a change, limits on the other side's capacity, logging, and a way to test outside production. Say whether you would use REST or SOAP and why.

Telling project stories in the plural, so your own contribution cannot be identified.

Tell each story in first person singular: what you decided, what you wrote, what you measured. Be ready to go into detail on every project listed on your resume.

Questions & practice

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?

Archive a resource graph without breaking live references or recursing

Medium · graph traversal · topological order · tenant isolation

Resources reference other resources within a tenant; for the largest tenant the reference table holds up to 2,000,000 nodes and 8,000,000 edges. Archiving a resource must archive everything reachable from it that nothing outside the set still references, refuse when a live external referrer exists, and terminate when references form cycles, which they legitimately do. Produce the archive order and the refusal list, targeting O(V+E). Say what stops the traversal crossing a tenant boundary, and why recursion is the wrong control structure at this size.

Approach

1. Load the subgraph with the tenant predicate on both endpoints of the edge, not only on the side you started from. Scoping the left table alone is the classic cross-tenant leak: one mis-entered edge then pulls another tenant's resources into the traversal and, worse, into the archive.
2. Traverse iteratively with an explicit stack. A 2,000,000-node graph can hold a chain deep enough to exhaust a native stack in the low tens of thousands of frames, and that failure is a process crash rather than an error you can return.
3. Treat cycles as data rather than corruption: compute strongly connected components with Tarjan in O(V+E) using its own explicit stack, then condense. The condensation is a DAG, so a topological order over it gives the archive order, and every member of a component archives in one transaction because no order within a cycle is valid.
4. Decide refusals with reverse edges. A candidate is archivable only if every in-edge originates inside the candidate set, so build the transpose or count in-degrees restricted to the visited set, and emit each blocked resource with the id of the external referrer, which is the only part of the answer an operator can act on.

Follow-up

• The graph is read in one query and the archive writes a minute later. What can change in between, and how do you make the write safe?
• The candidate set is 400,000 resources. Is that one transaction, and if not, what does a half-finished archive look like to a reader?

Find overlapping job attempts and peak concurrency from lease records

Medium · sweep line · intervals · leases

A day of job_run history yields about 50,000,000 attempt records: (job_run_id, job_type, attempt, started_at, finished_at which is NULL when the worker died, lease_expires_at). Leases expire on a clock, so a job that outran its lease ran twice. Produce (a) every job_run_id whose attempts overlapped in wall-clock time and (b) the peak number of simultaneously running attempts per job_type with the minute it occurred. Target O(n log n). State how you treat a NULL finished_at and what clock skew does to your answer.

Approach

1. Define the interval before sorting anything: an attempt occupies [started_at, COALESCE(finished_at, lease_expires_at)). finished_at is observed and lease_expires_at is only a promise, so every attempt without a finish contributes an estimate and the whole result is a lower bound on overlap rather than an exact count.
2. For peak concurrency, sweep: emit 2n endpoints, sort by (timestamp, kind) with ends ordered before starts at equal timestamps, then walk the sequence maintaining a counter per job_type and record each type's maximum with its timestamp. O(n log n) dominated by the sort, O(n) space, or O(1) extra if the sort is external and the walk streams.
3. For overlap detection, do not compare attempts pairwise. A single global sort by (job_run_id, started_at) gives both the grouping and the order; within a group, keep the maximum end seen so far and report an overlap exactly when the next start is less than that running maximum, which is one linear pass after the sort.
4. Half-open intervals matter and are easy to get wrong: with closed intervals an attempt ending at the same millisecond another begins reads as concurrency two, and across 50,000,000 records that artefact swamps the real signal.

Follow-up

• A handler is not idempotent and you have found 400 overlapping jobs. Which of them actually caused damage, and what would you query to find out?
• Peak concurrency for one job_type is 4 against a configured cap of 4. Is the cap working, or is the data hiding attempts that never started?

Stop tag and share joins from fanning out a page

Medium · join fan-out · semi-joins · many-to-many

resource_tag is (resource_id, tag_id) with PK (resource_id, tag_id); resource_share is (resource_id, shared_with_user_id, permission). The tagged-and-shared listing inner-joins resource to both, filters tenant_id, tag_id = ANY($2) and shared_with_user_id = $3, orders by updated_at DESC and takes 50. Pages come back with fewer than 50 distinct resources and the total in the header is far too high. Explain the row multiplication, rewrite both the page query and the count query so each is correct, and name the index each one needs. PostgreSQL 16.

Approach

1. Do the arithmetic against the predicates that are actually there. An inner join emits one row per matching child row, and both joins are filtered: tag_id = ANY($2) admits only the requested tags, shared_with_user_id = $3 admits one user's share rows. So a resource holding three of the requested tags and shared with $3 once yields three rows, not one — the multiplier is its count of matching tags times its share rows for that single user, and that second factor is 1 unless the table admits duplicate (resource_id, shared_with_user_id) pairs. LIMIT 50 then limits rows rather than resources, and COUNT(*) counts pairs — the header is the product, not the population.
2. Reject DISTINCT as the fix. It deduplicates after the product has been built, so the planner must materialise and sort the fanned-out set before the LIMIT can apply, and it leaves any SUM or AVG in the same select list wrong.
3. Rewrite both filters as semi-joins, keeping resource as the only row source: AND EXISTS (SELECT 1 FROM resource_tag rt WHERE rt.resource_id = r.resource_id AND rt.tag_id = ANY($2)) and the same shape against resource_share. A semi-join stops at the first match per resource and preserves the driving index order, so ORDER BY updated_at DESC, resource_id DESC LIMIT 50 still stops after 50 rows.
4. Count with the same predicates and no join at all: SELECT count(*) FROM resource r WHERE r.tenant_id = $1 AND r.status = 'active' AND EXISTS (...) AND EXISTS (...). Nothing multiplies a resource, so the number is the population.

Follow-up

• The filter changes from 'any of these tags' to 'all of these tags'. Rewrite it and state what it costs relative to the ANY form.
• A resource can be shared with the same user twice under different permissions. Does your count change, and should it?

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

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

Explain the difference between Business Rules and Client Scripts in ServiceNow.

Medium · Technical & Domain Expertise

Approach

1. Start with where each one runs. A Business Rule is server-side and fires on a database operation on a table (insert, update, delete, query or display). A Client Script runs in the browser on a form (onLoad, onChange, onSubmit) or on a list cell edit (onCellEdit).
2. Explain the Business Rule timing options: before (change current in place, no current.update() needed), after (act on other records once the save is done), async (runs later in the background, so the user does not wait) and display (fills g_scratchpad so the form has server data when it loads).
3. Give the security point. Client Scripts only run in the form UI, so imports, REST calls, list edits and server scripts skip them. Rules that protect data integrity belong in Business Rules, ACLs or Data Policies. Client Scripts are for user experience: validation messages, defaults, showing fields.
4. Cover the client-side pitfalls. Do not run GlideRecord or synchronous getXMLWait calls in the browser. Fetch server data with an asynchronous GlideAjax call to a client-callable Script Include, or with a display rule and g_scratchpad. For simple show, hide, mandatory or read-only behaviour, use a UI Policy with no script.
5. Mention the server-side pitfall too: calling current.update() inside a before or after rule saves the record again and runs the rules again, which can recurse and duplicate audit entries.

Follow-up

• When would you use a display Business Rule with g_scratchpad instead of GlideAjax?
• What goes wrong if an after Business Rule calls current.update(), and how would you fix it?
• When is a UI Policy a better choice than an onChange Client Script?

Can you explain the importance of Update Sets and how you manage them in a multi-developer environment?

Medium · Technical & Domain Expertise

Approach

1. Explain what an update set is. It records configuration changes (customer updates stored as sys_update_xml) on one instance so they can be retrieved, previewed and committed on the next one, from dev to test to prod. It keeps only the latest version of each changed record, and it belongs to one application scope.
2. Say what it does not capture. Ordinary data records (users, groups, task records) are not tracked by default, so you move them separately, for example with XML export and import or an import set. Treat that as a separate deployment step.
3. For a team, describe the working rules: one update set per story, named with the story or ticket number. Every developer checks which update set is current before editing, and nobody works in Default. Mark the set Complete only when the story is finished, and use batch (parent and child) update sets to move related work in a known order.
4. Explain preview and collisions. On the target, preview reports problems such as a newer local version of a record or a missing reference. When two developers changed the same record in different sets, the one committed last wins, so coordinate on shared records and resolve every preview problem on purpose, never by skipping it blindly.
5. Have a rollback plan: a committed update set can be backed out. For scoped applications, mention source control integration or the application repository as a cleaner alternative to moving many loose update sets.

Follow-up

• Preview says the target has a newer version of a record than your update set. What do you do?
• How would you move reference data, such as assignment groups, along with the configuration?
• A committed update set broke something in production. How do you recover?

What are the key considerations when designing a custom application within the ServiceNow platform?

Medium · Technical & Domain Expertise

Approach

1. Choose the scope first. A scoped application gets its own namespace and protects its tables and scripts from other scopes through cross-scope access settings. It can also be deployed through source control or the application repository, which makes it more upgrade-safe than building in global.
2. Design the data model next. Extend Task when the record is work that needs assignment, approvals, SLAs or activity history, since those come with the parent table. Otherwise create a standalone table. Use reference fields rather than copied text, and check the client's custom-table entitlement before adding tables.
3. Plan security from the start: application roles, table and field ACLs, and the integration users that will reach the app through APIs. Test as a user without admin rights, because admin bypasses most of what you need to check.
4. Put the logic in a deliberate place. Use Flow Designer for process steps, Script Includes for reusable server logic, thin Business Rules that call them, and as little client script as possible. Keep values that change in system properties rather than hard-coded sys_ids.
5. Finish with how it will be operated and changed: Automated Test Framework tests for key flows, no edits to out-of-the-box records outside the app, documentation for handover, and expected data volumes so list filters and reports stay fast.

Follow-up

• How do you decide between extending Task and building a new base table?
• Another scoped application needs to read your tables. How do you allow that safely?
• How would you test the app before each platform upgrade?

How do you balance the need for custom development versus using out-of-the-box ServiceNow features?

Medium · Problem-Solving & Architecture

Approach

1. Start with a gap analysis. Map each requirement to what the platform already does through configuration (form and list layouts, UI Policies, assignment rules, SLAs, Flow Designer, the module's own features) and script only what is left.
2. Explain the cost of customization concretely. When an out-of-the-box record is modified, upgrades skip it and list it for manual review, so every customized record adds work at each upgrade. Custom code also has to be maintained by whoever supports the instance after handover.
3. Use clear criteria: whether the gap is a real business need or a habit carried over from an old tool, whether changing the process is cheaper than changing the platform, how many users and records depend on it, and who will own the code.
4. When customization is justified, keep it additive: extend tables, add new Business Rules and Script Includes, or build a scoped application instead of editing out-of-the-box scripts. Copy a record before changing behaviour so the original still upgrades. Document why the customization exists.
5. Give a short example from your own work where you pushed back on a request, explained the trade-off to the stakeholder in terms of upgrade effort, and either met the need with configuration or built a contained extension.

Follow-up

• The client insists on behaviour the platform does not support. How do you handle it?
• How would you review the skipped records after an upgrade?
• How do you explain upgrade cost to a non-technical stakeholder?

Walk me through how you would integrate an external API with a ServiceNow instance.

Medium · Problem-Solving & Architecture

Approach

1. Clarify the direction and the trigger first. Is the instance calling out, or is the external system calling in? Is it real-time on a record event, or a scheduled batch? What volume, and which system is the source of truth for each field?
2. For outbound calls, define a REST Message with its methods and variables and an authentication profile (basic or OAuth 2.0), and call it through sn_ws.RESTMessageV2 or a Flow Designer REST step. Do not call it synchronously in a before Business Rule, because the user's save then waits on the remote system. Use an async rule, an event or a flow instead. Route through a MID Server when the endpoint sits inside the client's network.
3. For inbound data, prefer the Table API or a Scripted REST API for event-style calls. For bulk loads, use an import set table with a transform map whose coalesce fields turn repeat loads into updates rather than duplicate inserts.
4. Design for failure: set HTTP timeouts, retry 429 and 5xx responses with backoff, never retry other 4xx errors blindly, store a correlation or external id on the record so a retry cannot create the same thing twice, and handle pagination and rate limits. Keep outbound HTTP logging on while testing.
5. Cover security and operations. Keep credentials in auth profiles or credential records, never in scripts. Use a dedicated integration user with the narrowest roles, plus ACLs on inbound endpoints. Add a way to see failures (an error table, alerts or a retry queue) so support can find failures and resend them.

Follow-up

• The external API is down for an hour during business hours. What happens to the records created in that window?
• How do you stop a retry after a timeout from creating a duplicate record on the other side?
• The endpoint is only reachable from inside the client's network. What changes?

What strategies do you use to ensure your code is maintainable and scalable for future updates?

Medium · Problem-Solving & Architecture

Approach

1. Structure code so logic lives in Script Includes (class-based, small single-purpose functions) and Business Rules stay thin. Use the condition field so a rule only runs when its fields change, instead of checking inside the script.
2. Avoid environment coupling: no hard-coded sys_ids for data records such as groups or users, because those differ between instances. Read configurable values from system properties, and keep names and comments consistent so the next developer can find things.
3. Write for data volume from the start: no queries inside loops, GlideAggregate for counts and sums, setLimit where only a few rows are needed, filters on indexed fields. Push bulk or slow work to events, scheduled jobs or async rules so user transactions stay fast.
4. Protect future upgrades: extend rather than edit out-of-the-box records, keep work in a scoped application where possible, and track changes per story in update sets or source control.
5. Back it with process: peer code review against a short checklist, Automated Test Framework tests for the main flows, and handover documentation that records why each customization exists, not just what it does.

Follow-up

• How would you refactor a several-hundred-line Business Rule that nobody wants to touch?
• How do you enforce coding standards across several developers on one instance?
• What changes in your approach when a table grows to millions of rows?

Describe your process for debugging a complex script that is causing system latency.

Medium · Technical & Domain Expertise

Approach

1. Scope the slowness before reading any code: which transactions, forms, lists or jobs are slow, for which users, and since when. Pull the transaction logs for response times and check recent update set commits and scheduled jobs around the time it started.
2. Narrow down to the script with session debugging (Debug Business Rule and Debug SQL), the slow query log and the Script Debugger or script tracer for server-side code. Use browser dev tools for client-side delays. The aim is to tell slow SQL apart from slow script logic.
3. Check the usual causes: GlideRecord queries inside loops (one query per row), getRowCount() on large result sets where a GlideAggregate COUNT would do, filters on columns with no index, repeated dot-walking, rules that re-trigger each other through current.update(), and synchronous GlideAjax or client-side GlideRecord calls.
4. Fix the cause, not the symptom. Batch queries with encoded queries or IN filters, add setLimit, use GlideAggregate, add a condition so the rule only fires when needed, move heavy work to an async rule, an event or a scheduled job, and ask for an index on columns that are filtered often.
5. Check the fix with the same measurement you started with, before and after, on data of production size in a sub-production instance. Then add a review check (for example, no queries inside loops) so the pattern does not come back.

Follow-up

• How do you tell whether the time is going on a database query or on script logic?
• The slowness only shows up in production with real data volumes. How do you reproduce it safely?
• How would you process a million records without blocking user transactions?

Suggested practice checklist

The plan starts with your own platform experience, then covers the reported platform, debugging, integration and design questions, then the behavioral prompts, and ends with a full run-through of all four rounds.

Day 1 — Map the four rounds and inventory your platform work

• Write the reported sequence (Initial Screening, Technical Assessments, Engagement with Senior Team, Final Leadership Interviews) and mark the stage you feel least ready for.
• List every ServiceNow project you could discuss, noting the module (HRSD or ITOM), the scripts and integrations you built, and what you personally did.
• Mark each listed requirement (JavaScript, HRSD or ITOM experience, SDLC, REST or SOAP) as strong, adequate or weak.

Deliverable: A one-page loop map and a project inventory with your own contribution and the weakest requirement marked.

Day 2 — Platform scripting and change management

• Write a server-side-versus-client-side comparison covering where each runs, what triggers it and what it should never be trusted to enforce, then answer the Business Rules versus Client Scripts question aloud.
• Write an Update Set workflow for several developers: naming, one set per feature, collision checks, preview before commit, and the order of moves between instances. Then answer the Update Sets question aloud.
• Write one Business Rule and one Client Script from memory for a simple requirement.

Deliverable: A comparison table, a written Update Set workflow, two working scripts and two spoken answers.

Day 3 — Debugging latency and tuning large datasets

• Write your debugging sequence for a slow script as numbered steps, each with what it rules out, and answer the latency question aloud.
• Prepare a real performance story for the ITOM large-dataset question with a baseline figure, the levers you tried, the result and the trade-offs.

Deliverable: A numbered debugging runbook, a written performance story with before and after figures, and one worked query exercise.

Day 4 — Design, integration and maintainability

• Write an integration outline for an external API: authentication, mapping, error handling, retries, logging and testing. Then answer the integration question aloud.
• Write a checklist for designing a custom application (data model, access control, upgrade impact, performance, ownership) and answer the design-considerations question aloud.
• Write your decision test for custom development versus out-of-the-box features, with one real example, and list the habits that keep code maintainable through upgrades.

Deliverable: An integration outline, a design checklist, a decision test with an example and three spoken answers.

Day 5 — Behavioral stories: ambiguity, explaining, disagreeing

• Write a story for the ambiguous-requirement question: what you asked, what you wrote down, the smallest slice you built and what happened.
• Write a story for explaining a technical issue to a non-technical stakeholder, leading with impact and the decision needed.
• Write a story for disagreeing with a colleague's technical decision, including how you reached evidence and the honest outcome.

Deliverable: Three first-person stories, each with the decision, the measurement or evidence and what you would do differently.

Day 6 — Scenarios and prioritization

• Answer the migration scenario aloud: how you would map data and convert scripts when moving a legacy process to a new module.
• Answer the slow-dashboard scenario aloud, using your debugging runbook, and the upgrade-safe structure question by naming concrete habits.
• Prepare the prioritization answer with a real example: ranking criteria, who you told, what slipped and how you protected testing and review.

Deliverable: Two recorded scenario answers and a written prioritization story with its ranking method.

Day 7 — Full run-through of the loop

• Give a two-minute career walk-through, then answer the latency, custom-versus-out-of-the-box and integration questions back to back, aloud and recorded.
• Deliver the stakeholder-explanation story and the disagreement story, then listen back and cut anything vague, any plural pronoun that hides your role, and any claim without a number.
• Prepare your questions for senior people and leaders, including project challenges and platform governance.

Deliverable: A recorded full run-through, a trimmed set of stories and a list of closing questions.

Stories for a client-facing platform role

The reported behavioral questions come from a client-facing role: handling vague requirements, explaining technical issues to non-technical people, prioritizing competing tickets and disagreeing with a colleague. Candidates' tips recommend the STAR method (Situation, Task, Action, Result) and detailed knowledge of your own resume. Prepare stories in first person singular, with a decision you made and a result you can state.

1. Pick a project on your resume and explain your individual contribution and the hardest technical challenge you overcame.

How do you handle performance optimization when working with large datasets in ITOM?

Medium · Technical & Domain Expertise

Approach

1. Answer with a real case, not a list of tips. Name the table or job involved, its approximate row count, and the baseline symptom (a slow report, a long scheduled job, a timeout) before describing any change.
2. Say how you found the cost: timing the script, checking which query dominated, and spotting queries run once per record inside a loop. A story that starts with measurement is more believable than one that starts with a fix.
3. Walk through the levers in the order you tried them: filter on indexed fields and fetch only the columns and records you need, aggregate in the database rather than looping through records in script, move heavy work into batched or scheduled processing, and archive data nobody reads.
4. State the trade-offs. An index speeds reads and slows writes. Batching lowers load but makes results less fresh. Archiving needs agreement from whoever uses the old data.
5. Close with proof: the before and after figures, and the check that the output was unchanged. The usual failing is claiming an improvement with no number.

Follow-up

• How did you show the improvement came from your change and not from lower load that day?
• What would you do if the table kept growing and the fix stopped working?
• How did you find the slow query in the first place?

Describe a time you had to design a solution for a vague or ambiguous requirement.

Medium · Problem-Solving & Architecture

Approach

1. Pick a case where the requirement arrived as a one-line ask and you made the first move. Give the situation in two sentences, then spend the time on how you made it concrete.
2. Show the questions you asked and who you asked: the person who would use the feature, the functional consultant or project manager, and whoever owned existing processes. Include whether something out-of-the-box already covered part of it.
3. Show that you wrote things down: a short list of assumptions, acceptance criteria, and what was out of scope, confirmed by the requester before you built much.
4. Describe building the smallest useful slice first and getting it in front of the user, so a wrong assumption cost days instead of weeks.
5. Avoid two failing stories: waiting for clarity that never comes, and building everything first and discovering the misunderstanding at the demo.

Follow-up

• What did you do when the stakeholder could not answer your questions?
• Which assumption turned out to be wrong, and how did you find out?
• How did you record the decision so the next developer could understand it?

Tell me about a time you had to explain a complex technical issue to a non-technical stakeholder.

Medium · Behavioral & Professionalism

Approach

1. Choose an issue with a business consequence, such as a missed delivery, a failed release or a platform limitation that blocked a request. State it in two sentences and name the stakeholder and what they needed to decide.
2. Show the translation. Lead with impact and the decision required, then explain the cause in plain terms or with one comparison, and leave out internal names and mechanisms they do not need.
3. Offer options with cost, time and risk in their terms, with your recommendation and reason, instead of a technical tour.
4. Show you checked understanding by asking them to restate it, then confirmed the decision in writing.
5. The failing here is a story where the stakeholder was simply confused, or where you simplified so far that the real risk disappeared.

Follow-up

• How did you know they had understood?
• What did you leave out on purpose, and why?
• What did you do when they pushed for the option you advised against?

How do you prioritize tasks when working on multiple high-priority development tickets simultaneously?

Medium · Behavioral & Professionalism

Approach

1. Give a concrete method, not a slogan. For each ticket, list who is blocked, what happens if it slips, the effort, and any dependency, then rank by impact and urgency instead of by who asked most loudly.
2. Show that you make the trade-off visible. Take the ranking and what would slip to the project manager or ticket owners and ask which of the high-priority items is truly first. Do not choose silently.
3. Use an example with outcomes: which ticket shipped first, which waited, how you told the people affected, and what happened.
4. Say how you protect quality while busy. Unit testing and peer review stay in, and a large ticket can be split into smaller parts that ship separately.
5. The weak answers are 'I work longer hours' and 'I do them in parallel', since both hide the cost of switching between tasks.

Follow-up

• What do you do when two stakeholders each insist their ticket is first?
• How do you handle a new urgent ticket that arrives while you are mid-task?
• How did you tell the person whose ticket you deferred?

Describe a situation where you disagreed with a technical decision made by a team member. How did you resolve

Medium · Behavioral & Professionalism

Describe a situation where you disagreed with a technical decision made by a team member. How did you resolve it?

Approach

1. Choose a disagreement about substance, such as custom script versus configuration, how to structure a migration, or how to manage changes between instances, where both sides had a reasonable case.
2. Start by restating the other person's position and what they were trying to protect. This shows you understood the disagreement before arguing it.
3. Describe how you moved toward evidence: a small prototype, a measurement, a check of the platform's documented behavior, or an assessment of upgrade impact. Agreeing on the criteria first often settles most of it.
4. Report the outcome honestly: you persuaded them, you were persuaded, you compromised, or a decision-maker chose and you committed fully. Mention the working relationship afterwards.
5. The failing story is one where you were right and the other person was obstinate. Another is a story that never names the technical issue.

Follow-up

• What did you do when the decision went against you?
• How do you raise a disagreement in a peer review versus a design session?
• Did the discussion ever change your own mind?