The role as candidates describe it covers the full software lifecycle inside an enterprise: turning business requirements and user stories into code, building web applications and services, wiring them to existing databases and older systems, and testing and reviewing the result. That shapes preparation. The reported questions are about how you design a service, tune a query, test and ship it, and work with other roles. Reports do not mention an algorithm round or a take-home, so the weight falls on experience you can explain with specifics.
The stack matters because questions are phrased around it. Expect to discuss .NET or Spring Boot application structure, dependency injection and secure REST endpoints, SQL Server or Oracle query tuning and data integration, unit, integration and performance testing, and Git-based version control with CI/CD. Candidates also report JavaScript, HTML and CSS with Angular or React, and a topic breakdown that includes ArcGIS Enterprise, ArcGIS web services and general geospatial knowledge. Docker, infrastructure as code and distributed transactions appear as less common extras. Know your strongest language and database deeply, and be honest about the rest.
The reported questions fall into three groups. The technical and domain group covers web application design, relational databases, testing strategy and code standards. The system design group covers a scalable service that integrates with legacy systems and external databases, build versus buying a commercial product, troubleshooting performance problems in a mixed technology environment, and version control with CI/CD. The behavioral group covers translating ambiguous business requirements, juggling priorities, advocating for a process improvement and handling challenged code reviews. The question about frontend experience is filed with the behavioral questions, but it is an experience story, so answer it with a real project.
Plan for the domain as well as the code. Candidates report a recruiter conversation about interest in the energy sector and the hybrid work model, a technical stage that touches system monitoring and scripting, and a panel of cross-functional team members asking about stress and prioritization. If you have never used ArcGIS, learn the vocabulary of layers, map and feature services, and spatial references well enough to ask sensible questions, and say plainly what you have and have not used.
Screening Call
reportedCandidates report that the Screening Call is a conversation with a recruiter about your background, your interest in the energy sector and the hybrid work model. It is a fit and logistics conversation rather than a technical exam, so the preparation is a clear account of your experience and honest, specific reasons for wanting this kind of work. Have your location, availability and work-arrangement preferences ready, and use the call to learn who conducts the technical stage and what it covers.
What to demonstrate
- How your background lines up with the role's C#, .NET Core, Java, JavaScript and SQL requirements
- The reasons you give for the energy sector and for this role
- Logistics such as location and the hybrid work arrangement
How to prepare
- Prepare a short spoken summary of your career that names the languages, databases and delivery practices from the requirements you have really used.
- Write two or three concrete reasons for working on software behind electric transmission, based on something you have read or built, not on generic enthusiasm.
- List your questions on hybrid expectations, location, and which stages and interviewers follow, and ask for the next steps in writing.
Technical Interview
reportedCandidates report that the Technical Interview is with the Hiring Manager or a Senior Engineer and works through your resume and technical skills, including system monitoring and scripting. Expect depth on whatever you list: the question types reported for the technical side are web application design with .NET or Spring Boot, relational database experience and query optimization, testing strategy, code standards and security, and design and troubleshooting questions about integration, build versus buy, performance problems and CI/CD. Answer from projects you can describe in detail, state trade-offs, and say how you checked that your solution worked.
What to demonstrate
- Depth in the languages, frameworks and databases on your resume
- Design judgement on integration, testing and delivery questions
- Practical grasp of system monitoring and scripting
- How clearly you explain technical decisions and trade-offs
How to prepare
- Re-read each resume line and prepare one specific story per technology, covering what you built, what went wrong and what you would change.
- Practise out loud the answers on designing a web application in .NET or Spring Boot, tuning a slow SQL Server or Oracle query, and structuring unit, integration and performance tests.
- Prepare monitoring and scripting material: which signals you watch (errors, latency, resource use, logs), an alert you acted on, and a script you wrote to automate a check or a repetitive task.
- Rehearse the legacy-integration design and the CI/CD pipeline walkthrough with a sketch you can redraw from memory.
Panel Interview
reportedCandidates report that the Panel Interview is the final stage, with cross-functional team members asking behavioral and situational questions, including how you handle stress and prioritize tasks. The audience is mixed, so explain technical choices in terms that a business analyst or database administrator can follow. Prepare stories on ambiguous requirements, competing deadlines, process improvement and review feedback, plus a situational answer for a serious bug found shortly before a release.
What to demonstrate
- Collaboration across roles such as analysts, database administrators and developers
- How you prioritize under pressure and respond to stress
- Communication of technical decisions to a mixed audience
How to prepare
- Write four STAR stories in first person, one each for ambiguous requirements, competing priorities, a process improvement you championed and a challenged code review, and give each a measurable or checkable result.
- Prepare a situational answer for a bug found just before a scheduled release: how you assess severity, who you tell, and the options of fix, rollback or delay.
- Practise explaining one technical decision to a non-engineer without jargon, then once more with the technical detail for an engineer.
PracHub editorial advice for the preparation topics above.
Answering the SQL Server or Oracle question with a list of tools instead of a tuning story
Prepare one concrete case: the slow query, the execution plan you read, the scan or lookup you found, the index or rewrite you made, and the before-and-after numbers. Add one data integration example, such as staging, merging and reconciling rows.
Designing the legacy-integration service as if it were a greenfield system
Start by asking what systems and databases exist, who owns the data and what happens when a dependency is down. Then describe an adapter layer, retries with idempotency, monitoring, and a plan for moving traffic gradually.
Saying 'I write unit tests' when asked about testing strategy
Separate unit tests, integration tests against a real database and API, performance tests and regression suites. Say what each one catches, what you mock, and how tests run in the pipeline before a release.
Telling panel stories in the first-person plural so your own contribution is invisible
Name your decision, the stakeholders by role, the alternatives you weighed and the result. Rehearse each story until it is short enough to leave room for follow-up questions.
Ignoring the ArcGIS and geospatial topics candidates report, or bluffing about them
Learn the basics of ArcGIS Enterprise, map and feature services, layers and spatial references. If you have not used them, say so and explain a related system you have integrated and how you would learn this one.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Diff a projection against the primary without per-row point reads
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
- 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.
- 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.
- 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.
- 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?
Canonicalise a request body into a stable idempotency fingerprint
idempotency_key.request_fingerprint is a SHA-256 over the method, path and canonicalised body, and a retry whose fingerprint differs must be rejected with 422 rather than served the stored response. Write the canonicaliser. Bodies are JSON up to 256 KB nested at most 32 levels; clients vary key order, whitespace and unicode escaping, and some send 64-bit ids as JSON numbers. Produce a deterministic byte string such that semantically identical bodies match and any semantic difference does not. State your complexity and name two normalisations you refuse to perform.
Approach
- Parse once into a tree, then re-serialise under fixed rules: object keys sorted, array order preserved, one escaping convention, no insignificant whitespace. Parsing is O(n) and sorting keys is O(k log k) per object, so O(n log n) overall with O(depth) stack, and the 32-level cap is enforced during parsing because hostile nesting is how a canonicaliser becomes a stack overflow.
- Sort keys by their UTF-8 bytes and say why the obvious implementation is wrong in some runtimes: a default string comparison that orders by UTF-16 code units places surrogate pairs, meaning code points from U+10000 up, below U+E000 to U+FFFF, which is not UTF-8 byte order, so two services written in different languages disagree on the same document.
- Do not re-encode numbers through a double. IEEE-754 binary64 represents integers exactly only up to 2^53, so normalising a 19-digit id through a float changes it, and 1 against 1.0 cannot be reconciled without deciding whether they are the same value. Preserve the literal token, and require ids as strings at the API boundary if you want them comparable.
- Reject duplicate keys rather than picking one. JSON permits them and parsers disagree, most keeping the last, so any choice you make ties the fingerprint to a parser detail that the code handling the request does not necessarily share.
Follow-up
- A client sends the same logical request with an extra field your API ignores. Same key, different fingerprint, so you return 422. Is that the right answer?
- Where does the fingerprint get computed relative to request decompression and the body-size limit?
Collapse a redelivered event batch into per-aggregate high-water marks
You drain a batch of up to 5,000,000 events, each (aggregate_id BIGINT, aggregate_version INT, event_type, payload). The log guarantees order within one aggregate only; the batch merges 64 partitions, and a relay failover has redelivered a range, so an older version for an aggregate can appear after a newer one. Given a map of last_applied_version per aggregate, produce the events worth applying, at most one per (aggregate_id, version), plus the count discarded. Target O(n) time. State the memory for 2,000,000 distinct aggregates and what you do when it does not fit.
Approach
- One pass, one hash map from aggregate_id to the highest version kept, and a discard counter. An event whose version is at or below last_applied_version for its aggregate is dropped without further work, which is the whole reason the event carries its version rather than a delta. O(n) expected time, O(d) space in distinct aggregates.
- Keep the maximum, never the last occurrence. The redelivered range means the final appearance of an aggregate in the batch can be an older version than one seen earlier in the same batch, so last-wins applies stale state over newer state and the projection regresses with no error anywhere.
- Cost the memory instead of calling it large: an 8-byte key plus a 4-byte version is 12 bytes of payload, and an open-addressed table held at a 0.7 load factor costs roughly 17 bytes per entry before per-slot metadata, so 2,000,000 aggregates is tens of megabytes in a native layout and several times that in a runtime that boxes both key and value.
- If the distinct set exceeds memory, partition on hash(aggregate_id) mod P and reduce each partition independently. Every event for one aggregate hashes to the same partition, so the per-partition result is exact and the merge is concatenation rather than a second reduction.
Follow-up
- The payload is a patch rather than a snapshot, so applying only the highest version loses the intermediate changes. What changes in your reduction?
- How do you detect that version 7 arrived while version 6 was never delivered, and what should the consumer do about the gap?
Can you explain your experience with relational databases such as Oracle or SQL Server, particularly regarding
Can you explain your experience with relational databases such as Oracle or SQL Server, particularly regarding query optimization and data integration?
Approach
- Start from the execution plan, not guesses. In SQL Server, use the actual plan plus SET STATISTICS IO, TIME ON. In Oracle, use EXPLAIN PLAN or DBMS_XPLAN.DISPLAY_CURSOR. Look for scans where you expected seeks, key lookups, and large gaps between estimated and actual rows, which usually mean stale statistics.
- Index for the predicate. In a composite index, put the equality columns first and the range column last. In SQL Server, add INCLUDE columns to make the index covering and remove key lookups. Keep predicates sargable: wrapping the column in a function (YEAR(order_date) = 2024) or forcing an implicit type conversion blocks a seek, so rewrite the predicate as a range on the raw column.
- Use bind parameters for both safety and plan reuse. They prevent SQL injection and avoid Oracle hard parses. Know SQL Server parameter sniffing: the cached plan is built for the first values it sees. Fixes include OPTION (RECOMPILE), OPTIMIZE FOR, or splitting very skewed cases.
- For data integration, describe stage-then-merge. Bulk-load into a staging table (SqlBulkCopy, BULK INSERT, SQL*Loader or external tables), validate and deduplicate there, then MERGE or upsert on the business key so a rerun is idempotent. Commit in batches so one huge transaction does not bloat the log or escalate to table locks.
- Give one concrete example from your own work: the slow query, what the plan showed, the change you made, and the before and after numbers.
Follow-up
- The plan shows an index seek followed by millions of key lookups. What do you change?
- A query is fast in SSMS but slow when the application runs it. What could explain the difference?
- How do you make a nightly load safe to rerun after it fails halfway through?
Replace offset paging on the resource feed with keyset
resource holds resource_id, tenant_id, owner_user_id, title, body_ref, version, status ('draft','active','archived','deleted'), created_at, updated_at, deleted_at, with an index on (tenant_id, status, updated_at DESC, resource_id DESC). The listing endpoint returns active resources for one tenant, newest update first, 50 per page, today with LIMIT 50 OFFSET n. Tenants reach page 400 and rows are created while they read. Write the keyset query, define what the cursor carries and how it is encoded, and say which part of the index each predicate uses. Assume PostgreSQL 16.
Approach
- Name the two failures separately. OFFSET 20000 makes the server produce and discard 20,000 rows, so page cost grows with depth rather than with page size. Independently, any write that changes how many rows sort above the offset moves the window between two fetches, and the direction decides which anomaly you get: an insert lands at the head of updated_at DESC and pushes already-returned rows down past the boundary, so they are returned a second time; a delete above the offset, or a row whose updated_at is bumped above the cursor, pulls rows up and one is never returned at all. Nothing in the response reveals either.
- Write the seek: WHERE tenant_id = $1 AND status = 'active' AND (updated_at, resource_id) < ($2, $3) ORDER BY updated_at DESC, resource_id DESC LIMIT 50. The row-value comparison is one index range rather than a disjunction, and both columns are NOT NULL, which is what makes that comparison well defined.
- Map each predicate onto the index: tenant_id and status are equality on the leading columns, (updated_at, resource_id) is the range, and the ORDER BY matches the index order so no Sort node appears and the scan stops after 50 rows. The DESC in the definition only matters for mixed directions — a plain ascending btree on the same columns is read backwards for this query.
- Put both sort columns in the cursor and nothing the client can tamper with into another tenant: base64 of (updated_at, resource_id), validated server-side, with tenant_id taken from the principal.
Follow-up
- The client asks for 'jump to page 400'. What do you offer instead, and what does the honest version cost?
- Sort order becomes user-selectable across four columns. How many indexes is that, and which would you refuse to add?
How do you approach designing and implementing custom web applications or services using frameworks like.NET o
How do you approach designing and implementing custom web applications or services using frameworks like.NET or Spring Boot?
Approach
- Lay out the layers: thin controllers that only map HTTP to calls, a service layer that holds the business rules, and a repository or data-access layer (EF Core in .NET, Spring Data JPA in Spring Boot). Keep request and response DTOs separate from database entities so a schema change does not break the API contract.
- Explain dependency injection and lifetimes. ASP.NET Core's built-in container has Singleton, Scoped and Transient; a DbContext is Scoped per request and is not thread-safe, so never inject it into a singleton. Spring beans are singletons by default and constructor injection keeps them testable.
- Handle cross-cutting concerns in one place: input validation (Data Annotations or FluentValidation, Bean Validation with @Valid), central error handling (exception-handling middleware returning ProblemDetails, or @ControllerAdvice with @ExceptionHandler), authentication through OIDC or JWT, and per-environment config (appsettings.{Environment}.json or Spring profiles).
- Name the data-access traps: lazy loading causes N+1 queries, so use explicit Include or fetch joins, or project to DTOs. Put transaction boundaries on service methods. In Spring, @Transactional is proxy-based, so a call from one method to another in the same class skips it.
- Close with how you test it: unit tests for services with mocked repositories, and integration tests through WebApplicationFactory or @SpringBootTest against a real database.
Follow-up
- How would you version this API so existing clients keep working while you change a response shape?
- What goes wrong if a DbContext or another request-scoped dependency ends up inside a singleton service?
- How would you run a long report or export without tying up request threads?
What strategies do you use when conducting unit, integration, and performance testing for enterprise software
What strategies do you use when conducting unit, integration, and performance testing for enterprise software solutions?
Approach
- Frame it as a pyramid: many fast unit tests on business logic (xUnit, NUnit or JUnit 5 with Moq or Mockito), fewer integration tests against real dependencies, and a small set of end-to-end tests on the critical user flows.
- Unit tests check behaviour through public methods, not implementation details. Put the clock, file system and outside services behind interfaces so tests can control them. Use Arrange-Act-Assert and cover boundaries such as empty input, nulls, the maximum value and invalid states.
- Integration tests run against a real database engine, for example in a container with Testcontainers. EF Core's in-memory provider does not enforce relational constraints or translate queries the way SQL Server does, so it can pass code that fails in production. Test the HTTP layer through WebApplicationFactory or MockMvc, and reset data between tests.
- For performance testing, set the target first, for example p95 latency at a given request rate. Then run a ramped load test (JMeter, k6 or Gatling) in an environment shaped like production. Watch percentiles rather than averages, along with database and CPU saturation, and warm up the JIT before you measure.
- Wire it into CI so unit and integration tests block a merge. Treat coverage as a signal, not a target, and quarantine and fix flaky tests instead of retrying them until they pass.
Follow-up
- How do you test code that depends on the current time or on a third-party service?
- Why might tests pass on an in-memory database and the same code fail against SQL Server or Oracle?
- Your load test shows p99 latency climbing while the average stays flat. What do you look at?
How do you ensure that your code adheres to internal standards, security best practices, and maintainable desi
How do you ensure that your code adheres to internal standards, security best practices, and maintainable design patterns?
Approach
- Automate standards rather than relying on memory. Use .editorconfig with Roslyn analyzers or StyleCop for C#, Checkstyle, PMD or SpotBugs for Java, and ESLint for JavaScript, all run in CI so a violation fails the build. Add a quality gate such as SonarQube on new code.
- Walk through security controls mapped to the OWASP Top 10: parameterized queries with bind parameters against SQL injection, context-aware output encoding against XSS, anti-forgery tokens where auth is cookie-based, authorization checked on the server for every resource, and secrets kept in a vault or environment config, never in source control.
- Cover the supply chain: dependency scanning (Dependabot, OWASP Dependency-Check, npm audit) and static analysis in the pipeline, with a rule for how fast high-severity findings get fixed.
- For maintainability, use small classes with one job, dependency injection so code can be tested, consistent error handling, and structured logging that never writes passwords or personal data. Pick patterns to solve a stated problem, not for their own sake.
- Back it with review: branch protection that requires an approving review and passing checks, and a short checklist for reviewers covering input validation and authorization. Give one real example of an issue a check or review caught.
Follow-up
- How would you add a new analyzer rule to a large legacy codebase without thousands of existing violations blocking every merge?
- Where should a production database connection string live, and how does the application read it?
- Which design pattern have you seen overused, and what did you replace it with?
How would you design a scalable web service or application that integrates with legacy systems and external da
How would you design a scalable web service or application that integrates with legacy systems and external databases?
Approach
- Clarify before drawing anything: who calls the service and at what volume, the latency target, which system is the source of truth, and how the legacy system can be reached (SOAP or REST, file drops, direct database access). Also ask whether the new service only reads from it or also writes.
- Keep the API tier stateless behind a load balancer so it scales horizontally. Put an adapter or anti-corruption layer around each legacy system so its data model and quirks stay out of the new domain code. Prefer the legacy system's supported interface over writing straight into its tables.
- Make every outbound call resilient: explicit timeouts, retries with exponential backoff and jitter only for idempotent operations, a circuit breaker (Polly in .NET, Resilience4j in Java), and connection-pool limits sized so the new service cannot overload an older database.
- Decouple writes with a message queue. Use the transactional outbox pattern so the local database update and the outgoing message cannot diverge, which a dual write allows. Serve reads from a cache (cache-aside with a TTL) or a replica fed by change data capture wherever some staleness is acceptable.
- Add observability across the boundary: a correlation ID passed through every hop, plus latency, error-rate and saturation metrics for each dependency, so a slow legacy call shows up as such.
Follow-up
- The legacy system only accepts a nightly batch file. How does the design change?
- How do you keep the new database and the legacy system consistent without a distributed transaction?
- What does a user see while the legacy system is down, and which requests still succeed?
What factors do you consider when evaluating whether to build a custom solution versus implementing a commerci
What factors do you consider when evaluating whether to build a custom solution versus implementing a commercial off-the-shelf product?
Approach
- Start with fit: list the must-have requirements and mark each one as covered out of the box, by configuration, or only by custom code. Also ask whether the capability sets the business apart or is a commodity. Commodity capabilities favour buying.
- Compare total cost of ownership over several years, not the first-year price. For buying, that means licences (per user or per core), implementation, integration, hosting, training and upgrades. For building, it means development plus ongoing maintenance, security patching, on-call support and the cost of keeping people who know the code.
- Check integration and data: documented APIs, bulk export, support for your identity provider (SAML or OIDC), and who owns the data. A commercial platform, such as a GIS product like ArcGIS Enterprise set against a custom mapping service, still needs integration work with existing databases and applications.
- Weigh the risks on both sides. Buying brings vendor lock-in and dependence on the vendor's health and roadmap, and heavy customization makes every upgrade expensive. Building brings delivery-time risk and limits on team capacity. Security and compliance requirements apply to both.
- Decide with evidence: a weighted scoring matrix agreed with stakeholders and a proof of concept run on real use cases. Mention the hybrid option of buying the core and building extensions only through the vendor's supported extension points.
Follow-up
- The product covers most needs, but one key workflow needs deep customization. What do you recommend?
- How would you plan an exit if the vendor raises prices sharply or drops the product?
- Whom do you involve in the decision, and how do you handle disagreement between them?
Can you walk through your process for maintaining version control, CI/CD pipelines, and automated deployments?
Can you walk through your process for maintaining version control, CI/CD pipelines, and automated deployments?
Approach
- Pick a branching model and justify it: trunk-based development with short-lived feature branches for frequent releases, or a release-branch model when releases are scheduled. Protect main with required reviews and passing status checks, keep pull requests small, and tag releases with semantic versions.
- CI runs on every push: build, unit and integration tests, static analysis and dependency scanning. It produces one immutable, versioned artifact (a package or container image) that gets promoted through test, staging and production. Build once and deploy that same artifact everywhere.
- Keep environment differences out of the artifact. Inject configuration at deploy time and fetch secrets from a vault or the pipeline's secret store. Never commit credentials.
- Version database changes with migrations (Flyway, Liquibase or EF Core migrations) applied by the pipeline. Write them expand-then-contract, so the old and new code both work against the schema and an application rollback does not need a schema rollback.
- Make deployment safe: rolling, blue-green or canary releases with health checks, automatic rollback when checks fail, and a manual approval gate before production where change control requires it.
Follow-up
- You need to rename or drop a column that live code still reads. How do you ship it without downtime?
- A release breaks production. How do you roll back, and what happens to data the new version already wrote?
- How do you ship an urgent hotfix while main already contains unreleased work?
How do you approach troubleshooting complex performance bottlenecks or production issues in a hybrid technolog
How do you approach troubleshooting complex performance bottlenecks or production issues in a hybrid technology environment?
Approach
- Scope and stabilise first: who is affected, since when, and what changed (deploys, config, infrastructure, data volume, certificates). If users are hurting, mitigate before finding the root cause, with a rollback, a feature-flag switch or added capacity.
- Find the slow tier with evidence. Use a correlation ID or distributed trace to split time across client, network, application server and database. In a hybrid setup, check the link between cloud and on-premises systems: a chatty ORM making many round trips across a VPN can turn small per-call latency into seconds.
- Read the right signals: rate, errors and duration (RED) for services; utilization, saturation and errors (USE) for hosts and pools; p95 and p99 rather than averages. Write small scripts (PowerShell, bash or Python) to pull and correlate logs across machines instead of reading each one by hand.
- Go deeper where the evidence points. For the database: SQL Server Query Store, DMVs and wait stats, blocking chains through blocking_session_id, or Oracle AWR and ASH reports. For the application: thread dumps (jstack), dotnet-counters or dotnet-trace, GC pauses, thread-pool starvation and connection-pool exhaustion.
- Confirm the hypothesis by reproducing it or changing one variable at a time. After the fix, check the same metric that showed the problem, then write a blameless postmortem and add the alert or dashboard that would have caught it sooner.
Follow-up
- Latency rises only for users at one site. Where do you look first?
- CPU is low but requests are queueing. What could cause that?
- How do you tell whether the deploy that happened just before the incident actually caused it?
Seven days built from the three reported rounds: the screening pitch, then application design, databases, testing and delivery, integration and troubleshooting, frontend and ArcGIS, and finally the panel stories. Practice-library drills appear where they fit; they are PracHub practice, not reported ATC questions.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Map the loop and your stack
- Write the three reported rounds on one page (Screening Call, Technical Interview, Panel Interview) and note what each covers.
- List the requirement stack (C#, .NET Core, Java, JavaScript, HTML, CSS, SQL Server or Oracle, GitHub, Angular or React, ArcGIS) and mark what you have used in real projects and what you have not.
- Write a short spoken career summary and your reasons for the energy sector, then say them aloud.
Deliverable: A one-page loop map, a stack gap list, and a written career summary with reasons for the energy sector.
02Application design and code standards
- Outline a layered web API in .NET Core or Spring Boot: controller, service, repository, dependency injection, validation, error handling and authentication.
- Write a checklist for a secure REST endpoint covering input validation, authorization, error responses and logging.
- List how you keep code to standards: linters or analyzers, review checklist, static analysis and dependency scanning.
Deliverable: A layered design outline, a secure-endpoint checklist, and a code-quality checklist, each spoken aloud once.
Practice prompt ↗Practice prompt ↗03Relational databases and query tuning
- Take a slow query on SQL Server or Oracle (or a practice database), read its execution plan, change an index or the query, and record the before-and-after result.
- Work the PracHub practice drill on replacing offset paging with keyset paging.
- Write talking points on data integration: staging tables, merge logic, reconciliation of mismatched rows and handling failures.
Deliverable: A written before-and-after tuning case, a solved keyset paging drill, and a spoken answer on database experience.
Practice prompt ↗Practice prompt ↗04Testing and delivery pipeline
- Write a test strategy sheet separating unit, integration, performance and regression tests, with what each catches and what is mocked.
- Sketch a GitHub-based pipeline: build, test, scan, package (a Docker image if you use one), deploy and roll back.
- Write your branching approach and how you resolve merge conflicts and run reviews.
Deliverable: A one-page test strategy and a pipeline diagram you can redraw from memory.
Practice prompt ↗Practice prompt ↗05Legacy integration, build versus buy, troubleshooting
- Design a scalable web service that integrates with a legacy system and an external database: adapters, retries, idempotency, monitoring and a migration path.
- Write a build versus commercial product decision table covering fit, cost of change, support, integration effort and exit options.
- Write out a troubleshooting sequence for a slow or failing production service in a mixed environment, and write a short script that checks a health endpoint or scans logs.
- Optional: do the PracHub drills on diffing a projection against the primary and on collapsing redelivered event batches.
Deliverable: A design sketch, a decision table, a troubleshooting runbook and a working monitoring script.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗06Frontend and ArcGIS preparation
- Write the frontend project story: stack, state and data flow decision, one performance, accessibility or leak fix, and how you checked it.
- Read about ArcGIS Enterprise, map and feature services, layers and spatial references, and write ten terms with your own definitions.
- Write three questions you would ask about GIS work in the role and what you have used that is similar.
Deliverable: A frontend project story, a ten-term GIS glossary and three questions about the GIS work.
Practice prompt ↗07Panel rehearsal
- Write four STAR stories for ambiguous requirements, competing priorities, a process improvement and a challenged code review.
- Say each story aloud to a friend or a recording, then cut anything that is not your own decision.
- Prepare a situational answer for a serious bug found shortly before a release, and a plain-language explanation of one technical choice.
Deliverable: Four rehearsed STAR stories, a release-bug answer and a plain-language technical explanation.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
The behavioral side of the loop is reported most clearly in the Panel Interview, where cross-functional team members ask behavioral and situational questions about stress and task prioritization. The reported questions also cover turning ambiguous business requirements into specifications, advocating for a process improvement and handling challenged code reviews. Prepare stories where you made the call, with specifics about what you did and how you checked the result.
Describe your experience working with frontend technologies like JavaScript, HTML, CSS, and modern frameworks
Describe your experience working with frontend technologies like JavaScript, HTML, CSS, and modern frameworks such as Angular or React.
Approach
- Choose one frontend project you built and name its stack exactly: JavaScript or TypeScript, HTML, CSS, and Angular or React. If you have used only one framework, say so and explain how you would transfer, rather than listing tools you only touched.
- Cover one decision you owned: how the components were structured, where state lived (component, shared service or store, URL), and how asynchronous data loading handled loading, error and empty states.
- Add one quality result with evidence, such as an accessibility fix, a render or bundle-size improvement, or a memory leak from listeners or subscriptions that were never released, found with browser developer tools and confirmed gone afterwards.
- Tie the frontend to the backend: how it called the API, handled authentication and escaped user input against XSS. If you have built map or geospatial interfaces, say so, because ArcGIS web services are among the topics candidates report.
- The mistake that sinks this answer is reciting a technology list with no story. Spend most of the time on one project, your role in it and what you learned.
Follow-up
- How do you manage state and data flow in a large single-page application, and when do you add a store?
- How would you find and fix a memory leak in a component that subscribes to events?
- If you had to choose between Angular and React for an internal business tool, how would you decide?
Tell me about a time when you had to collaborate with cross-functional stakeholders to translate ambiguous bus
Tell me about a time when you had to collaborate with cross-functional stakeholders to translate ambiguous business requirements into technical specifications.
Approach
- Open with a situation in two sentences: a vague request from the business, such as a report that should be faster or an integration with another system, and the roles involved (analyst, database administrator, product owner). Do not retell the whole project.
- Spend the middle on how you removed the ambiguity: the questions you asked, concrete examples and user stories with acceptance criteria, a mock-up or small prototype, and a written list of assumptions that stakeholders confirmed.
- Show the artifact you produced, such as a technical specification, an API contract or a data-mapping sheet, and how you handled a requirement that changed afterwards.
- Close with the result: what shipped, how it differed from the first request, what rework you avoided, and what you would clarify earlier next time.
- The mistake that sinks it is saying you built what you were told, or saying 'we aligned' without showing what you personally did to pin down the requirement.
Follow-up
- What did you do when two stakeholders wanted conflicting things?
- How did you know the specification was right before you built it?
- Which question do you wish you had asked earlier?
How do you manage competing priorities and tight deadlines in a fast-paced development environment?
How do you manage competing priorities and tight deadlines in a fast-paced development environment?
Approach
- Pick a real collision: two deliverables with different owners and dates, and say what was at stake in each. A deadline that merely felt busy does not make a story.
- Show your method for choosing: business impact, how fixed each date was, dependencies on other people, and cost of delay. Name who you consulted, and describe negotiating scope or sequencing, not simply working longer hours.
- Describe the communication: you told each stakeholder what would move and why, offered options, and confirmed the decision in writing.
- Say what you protected under pressure, such as tests, code review or a rollback plan, and what you deferred on purpose. This also covers the situational version of a serious bug found right before a release.
- The mistake that sinks it is 'I just work harder' or a generic list of tools. Show a trade-off you made and its consequence.
Follow-up
- What would you do if both requests came from your manager?
- What did you cut or defer, and what happened to it afterwards?
- How do you handle stress when the deadline cannot move?
Describe a situation where you identified a technical process improvement and successfully advocated for its a
Describe a situation where you identified a technical process improvement and successfully advocated for its adoption within your team.
Approach
- Choose a process improvement in engineering practice, such as automated tests in the build, a branching convention, a pull request checklist, a deployment script or a query review step. Describe the pain first, with evidence you gathered, like failed deployments, recurring defects or time lost.
- Explain how you built support: a small pilot on one project, a comparison of cost against benefit, and answers to objections from teammates who saw extra work.
- Make adoption easy: templates, short documentation, pairing with a colleague, or a change that fitted into the tools the team already used.
- Report the result with a number or observable change, whether it spread beyond your team, and what did not work. Keep your own contribution visible.
- The mistake that sinks it is a tool you installed that nobody adopted, or an improvement with no evidence and no mention of resistance.
Follow-up
- Who objected, and what did you say to them?
- How did you measure that the change helped?
- What would you do if the team still declined?
How do you handle feedback or code reviews when your initial implementation is challenged by senior team membe
How do you handle feedback or code reviews when your initial implementation is challenged by senior team members?
Approach
- Use a real example where a senior engineer challenged your implementation. State what you built and the specific concern, for instance business logic in a controller, a missing test or a security gap.
- Show the listening step: you asked for the reasoning, reproduced the issue and checked the evidence with a test or measurement before reacting.
- If they were right, say so plainly and describe the fix. If you disagreed, show how you presented evidence and alternatives respectfully and let the team decide.
- Finish with the habit you changed, such as self-review before opening a pull request, smaller changes, or a standing checklist, so the story shows growth.
- The mistake that sinks it is a defensive story where the reviewer was wrong, or one where you gave in without understanding the concern.
Follow-up
- What would you do if you still disagreed after the discussion?
- How do you give review feedback to someone more senior than you?
- What did you change in the way you open pull requests afterwards?
- 01
Describe your experience working with frontend technologies like JavaScript, HTML, CSS, and modern frameworks such as Angular or React.
- 02
Tell me about a time when you had to collaborate with cross-functional stakeholders to translate ambiguous business requirements into technical specifications.
- 03
How do you manage competing priorities and tight deadlines in a fast-paced development environment?
- 04
Describe a situation where you identified a technical process improvement and successfully advocated for its adoption within your team.
- 05
How do you handle feedback or code reviews when your initial implementation is challenged by senior team members?
- 06
Tell me about a stretch of work that put you under stress and how you chose what to do first.
What rounds do candidates report for the ATC Software Engineer loop?
Candidates report three rounds over about 3-5 weeks. The Screening Call is a recruiter conversation about your background, interest in the energy sector and the hybrid work model. The Technical Interview is with the Hiring Manager or a Senior Engineer and covers your resume, technical skills, system monitoring and scripting. The Panel Interview is a final stage with cross-functional team members, covering behavioral and situational questions on stress and prioritization.
ATC Software Engineer candidate reports ↗Which technologies should I prepare?
Prepare C# with .NET Core or Java with Spring Boot, JavaScript, HTML and CSS, SQL Server or Oracle, and Git on GitHub. Angular or React, cloud platforms, CI/CD tooling and enterprise GIS are described as extras, and candidates also report Agile development, Oracle Business Intelligence Enterprise Edition and Power BI among the topics. Docker and infrastructure as code are reported as less common. Go deepest on the stack you list as strongest.
ATC Software Engineer candidate reports ↗Do I need GIS or ArcGIS experience?
The topic breakdown candidates report includes ArcGIS Enterprise, ArcGIS web services and geospatial knowledge, while the requirements describe enterprise GIS and utility or infrastructure familiarity as advantages rather than must-haves. Learn the basics: map and feature services, layers, spatial references and how a web application calls a GIS service. If you have no GIS experience, say so and describe a similar integration you did.
ATC Software Engineer candidate reports ↗How should I prepare for the technical interview?
Reports describe a resume-driven conversation with the Hiring Manager or a Senior Engineer, including system monitoring and scripting. Prepare a detailed story for each technology you list, rehearse the reported design, database, testing and CI/CD questions aloud, and have a script and a monitoring example ready. Practise sketching the legacy-integration design on paper so you can redraw it.
ATC Software Engineer candidate reports ↗Is there a coding test or take-home?
Candidate reports do not mention an algorithm round or a take-home. The reported questions are experience, design and troubleshooting discussions, so most preparation time should go to explaining real work. If you want some coding practice, the PracHub practice drills on event batches, idempotent request fingerprints and keyset paging match the integration and database themes, though they are not reported ATC questions.
ATC Software Engineer candidate reports ↗What should I expect from the Panel Interview?
Candidates report cross-functional team members asking behavioral and situational questions about stress and prioritization. Prepare four first-person STAR stories (ambiguous requirements, competing priorities, a process improvement and a challenged code review), and a situational answer for a serious bug found shortly before a release. The number of panelists is reported to vary by department.
PracHub Software Engineer practice ↗Is the role hybrid?
Candidates report that the recruiter call covers the hybrid work model. Specifics such as how many days in the office depend on location and department, so ask about them in the screening call and get the answer in writing.
ATC 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.
- 01ATC 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.
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.
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.
Ramp Software Engineer Interview Guide
Systems practice for Ramp software engineer candidates, weighted toward payments and lending work: the load that actually arrives, the failure modes that matter there, and the invariants a partial outage must not break.
Mistral AI Software Engineer Interview Guide
Testing exercises for Mistral AI software engineer prep: choosing boundary cases over repetition, isolating tests from shared clock and ordering, and treating an intermittent failure as a defect rather than noise.