Ascentt Software Engineer Interview Guide

The 60-second brief

Candidates describe Ascentt as a company whose engineers build enterprise applications, cloud architectures and data platforms for client organizations. The reported work includes distributed microservices, infrastructure on AWS, Azure or GCP, pipelines that process unstructured big data, and custom analytics. Some projects are business intelligence and enterprise performance management implementations that customize packaged software such as Oracle BI and Hyperion. A Software Engineer in this loop is expected to be comfortable on the software side (Java, Scala or Python, SQL and PL/SQL) and to have working knowledge of cloud services, batch and streaming data processing, and reporting.

This guide is for engineers preparing for the Ascentt Software Engineer loop. It covers the two reported stages, the 25 questions candidates report (streaming and batch pipelines, SQL and PL/SQL tuning, cloud and DevOps, coding, BI and enterprise reporting, and behavioral), and a plan that takes you through them in a week. It suits both candidates from a general software background and those who already have BI or cloud delivery experience.

Candidates report two stages over roughly 2-4 weeks: an Initial Screening Assessment that mixes multiple-choice questions with practical coding, followed by Technical Rounds on system design, past projects and languages such as Python or Java.

Focus areas

• Python
• Data Pipelines (Batch & Streaming)
• Microservices Architecture

Overview

The reported question set is unusually wide for a single Software Engineer loop. It runs from Spark streaming design and SQL tuning, through Docker, Terraform, CloudFormation and CI/CD, to Oracle BI repository modeling, fit-gap analysis and self-service analytics. Treat it as three layers: a coding and SQL base that every candidate needs, a cloud and data-pipeline layer that matches the stack candidates list (Spark, Kinesis, Lambda, AWS, Azure, GCP), and a BI and enterprise layer that matters more or less depending on the team.

The screening stage is described as multiple-choice questions across data science, DevOps, cloud, databases and statistics, plus practical coding, and one tip mentions Generative AI as a topic area. That means breadth counts early: you can lose the stage on a DevOps or statistics fact even if your coding is strong. Spend a short block refreshing vocabulary in each of those areas, then spend most of your time on the technical rounds, where candidates report system design and detailed discussion of past projects.

Language flexibility is a repeated warning in the reports: some coding evaluations restrict which language you may use. Be able to write clean Python as well as your primary language, and ask in advance which languages a live session allows. Practise the reported coding tasks (star patterns, multi-dimensional arrays, parsing and aggregating an unstructured log file) in plain Python without libraries you cannot rely on.

Because the work is client-facing, many reported questions ask how you handle vague requirements, shifting priorities, security and product stakeholders, and mentoring. Prepare four or five project stories you can tell top-down: architecture first, then the implementation detail, then the business result. Make sure each one names a decision you personally made and what it cost.

The Ascentt interview process

Candidates describe two stages and a total span of about 2-4 weeks; the exact format can shift with region and with whether the team leans toward cloud architecture or BI delivery.

Initial Screening Assessment

Candidates report this stage as a combination of multiple-choice questions and practical coding. The multiple-choice portion is described as spanning data science, DevOps, cloud technologies, databases and statistics, so it rewards breadth rather than depth in one area. The coding portion is where the reported array, string and log-parsing style tasks fit. Approach it as two separate preparations: a fast refresh of definitions and trade-offs across those domains, and timed coding in Python plus your main language, since some evaluations restrict syntax choices.

What to demonstrate

• Breadth across databases, cloud, DevOps, data science and statistics fundamentals
• Working code on a practical task, including Python
• Basic complexity reasoning when you explain a solution

How to prepare

• Write the star-pattern and multi-dimensional array task in Python from scratch, then again in your primary language, without looking anything up
• Write the log-file task: read lazily, extract the error code with a regular expression, count with a dictionary, and handle malformed lines
• Refresh one-page summaries for SQL joins and indexes, container basics, IaC terms, CI/CD stages and basic statistics so multiple-choice items do not catch you cold
• Confirm in advance which languages the assessment allows

Technical Rounds

Candidates report in-depth discussions covering system design, past projects, and specific languages such as Python or Java. The reported questions that fit this format include designing a streaming pipeline with Spark, contrasting batch and streaming processing, handling unstructured data in a microservices architecture, SQL and PL/SQL tuning, cloud environments and Infrastructure as Code, and CI/CD troubleshooting. BI-oriented teams add OBIEE, fit-gap and self-service analytics topics. Approach it by choosing two or three projects from your history and rehearsing them top-down, then practise the design and tuning questions aloud with a diagram.

What to demonstrate

• Ability to design a data or cloud system and justify trade-offs
• Depth on projects you have actually built, from architecture down to implementation
• Command of the language you code in, such as Python or Java
• SQL and database tuning knowledge

How to prepare

• Draw the Spark streaming pipeline design end to end: sources, ingestion, processing, storage, monitoring, failure handling
• Prepare the batch versus streaming comparison with a concrete case where each one is the right choice
• Practise explaining a SQL tuning session from slow query to explain plan to fix
• Rehearse two project walkthroughs with architecture first, then one hard implementation detail, then the business outcome

Where candidates lose points

Treating the screening as coding only and arriving without refreshing databases, DevOps, cloud, statistics and Generative AI basics

Reported screenings mix multiple-choice questions across those areas with practical coding. Make one-page summaries of each domain and test yourself on them a day or two before the assessment.

Being unable to write the coding tasks in Python because you only practise in one language

Candidates warn that some evaluations restrict syntax choices. Solve the star-pattern, multi-dimensional array and log-parsing tasks in Python without helper libraries, and confirm the allowed languages before any live session.

Describing a streaming pipeline as a list of tools instead of a design with failure handling

For the Spark question, state sources, ingestion, processing, sink and monitoring, then say what happens on duplicates, late data, consumer restarts and a downstream outage. Contrast it explicitly with the batch alternative.

Claiming OBIEE, Oracle BI or Hyperion experience you cannot detail

If asked about RPD modeling, security setups or fit-gap analysis, give the layers, the roles and the concrete case you worked on, or state your gap and map it to a similar semantic-layer or reporting project.

Giving behavioral answers that describe the team's work rather than your decisions

For the mentoring, tight-deadline, shifting-priority and cross-functional questions, pick stories where you chose the plan, name the trade-off and report a checkable result.

Questions & practice

Write a Python script to generate specific star patterns and manipulate multi-dimensional arrays.

Medium · Coding and Problem Solving

Approach

1. For star patterns I ask for the exact shape and size n, whether trailing spaces matter, and whether it is solid or hollow. Each row is computed from its index: in a centred pyramid of n rows, row i (0-based) is ' ' * (n - 1 - i) + '*' * (2 * i + 1). Printing is O(n^2) characters.
2. Composite shapes reuse rows: a diamond is the pyramid followed by its first n - 1 rows reversed, and a hollow shape prints stars only on the first and last row and at the row's edge positions. I test n = 0, 1 and 2.
3. For 2D arrays I build grids with [[0] * cols for _ in range(rows)], never [[0] * cols] * rows, which repeats one inner list so a write to one row shows up in every row.
4. Common operations: transpose with [list(r) for r in zip(*m)] (zip yields tuples); rotate a square matrix 90 degrees clockwise in place by transposing and then reversing each row, which is O(n^2) time and O(1) extra space; spiral order with four shrinking boundaries, checking for single-row or single-column leftovers.
5. If NumPy is allowed: m.T for transpose, np.rot90(m, k=-1) for a clockwise turn (the default is counter-clockwise), and remembering that slices are views, so writing to a slice changes the original.

Follow-up

• How do you rotate a non-square matrix, and can it be done in place?
• Print a hollow diamond of size n.
• What does your spiral traversal do on a single row or an empty matrix?

Given an unstructured log file, write a script to parse, filter, and aggregate specific error codes efficientl

Medium · Coding and Problem Solving

Given an unstructured log file, write a script to parse, filter, and aggregate specific error codes efficiently.

Approach

1. I clarify the input first: a few sample lines, the timestamp format, where the error code appears, whether stack traces span multiple lines, file size, and whether files are rotated or gzipped.
2. I stream rather than load: iterate with for line in f (open with errors='replace' for bad bytes, gzip.open for .gz files) and match each line against one precompiled regex with a named group, for example re.compile(r'ERROR\s+(?P<code>E\d+)'). Lines that do not match are counted as malformed instead of crashing the script.
3. I aggregate with collections.Counter or defaultdict(int) keyed by code, or by (code, hour) if a time breakdown is asked for. Filters such as level, time range or a set of codes use set membership. That is O(n) time over lines and O(k) memory in distinct keys, and Counter.most_common(n) gives the top codes.
4. For many files I process each file in a separate process (multiprocessing.Pool) and merge the Counters by adding them. At cluster scale it is the same map-reduce in Spark. A quick shell version is grep -oE 'E[0-9]+' | sort | uniq -c | sort -rn.
5. Edge cases: empty file, lines with two codes, codes inside stack-trace lines, mixed time zones, and a partially written last line.

Follow-up

• How would you attribute a multi-line stack trace to the error line that started it?
• Change the output to errors per minute and flag spikes.
• The logs grow to hundreds of gigabytes a day. What changes?

How do you structure unit tests and validation procedures for mission-critical software applications?

Medium · Coding and Problem Solving

Approach

1. I describe the layers: many fast unit tests on pure logic, fewer integration tests against real dependencies (Testcontainers for a database or Kafka), contract tests between services, and a small set of end-to-end tests on the main user paths.
2. Unit test structure: Arrange-Act-Assert with one behaviour per test, deterministic by injecting the clock and random seed, and mocks only at boundaries (pytest with unittest.mock, or JUnit 5 with Mockito). I parametrise boundary cases: empty, None or null, maximum size, negative numbers, off-by-one limits, Unicode, time zones and DST changes.
3. Beyond hand-picked examples I use property-based tests (Hypothesis, jqwik) for invariants and mutation testing (mutmut, PIT) to check the tests actually fail when the code is wrong. Coverage, especially branch coverage on the important paths, is a floor rather than the goal.
4. Validation outside unit tests: schema validation of inputs at service boundaries, data checks in pipelines (row counts, null and uniqueness checks, reconciliation of totals against the source), and a regression test for every production bug.
5. Everything runs in CI on every pull request and blocks the merge on failure. Flaky tests are quarantined with an owner rather than retried until green.

Follow-up

• How do you test code that depends on the current time or a third-party API?
• What coverage target would you set, and what does it not tell you?
• How do you test that a data pipeline's output is correct, not just that it ran?

What steps do you take when you encounter a logic error in a time-sensitive coding problem during an interview

Medium · Coding and Problem Solving

What steps do you take when you encounter a logic error in a time-sensitive coding problem during an interview?

Approach

1. I stop adding code and say what I see: the input that fails, the expected output and the actual output. Then I shrink it to the smallest input that still fails.
2. I trace that input by hand through the code, checking the usual suspects: off-by-one loop bounds or slices (a Python slice end is exclusive), a wrong initial value (0 where a max needs float('-inf')), mutating a list while iterating over it, shared inner lists from [[0] * n] * m, integer versus float division, and empty or single-element input.
3. I write the invariant the loop should keep (for example, the window sum equals sum(nums[l:r + 1])) and check it with an assert or a print at the point where it breaks, instead of rewriting large blocks.
4. If a counterexample shows the approach itself is wrong, not just the code, I say so, fall back to a correct brute-force version, and then improve it.
5. After the fix I rerun every case, including empty input, a single element, duplicates and negatives, and I say the final complexity again.

Follow-up

• You are almost out of time and the bug is still there. What do you do?
• Which test cases would have caught this bug before you ran the code?
• How do you decide between patching the code and changing the approach?

How do you conduct business requirements analysis to design custom Business Intelligence applications?

Medium · Business Intelligence and Enterprise Per

Approach

1. I start from decisions rather than screens: which decisions the application supports, who makes them (executives, analysts, operations), and how fresh the data must be. I record these as user stories plus a KPI catalogue where every metric has a precise definition: formula, grain, filters, time zone and owner.
2. Next comes source analysis: I map each KPI to source systems and fields, then profile the data (nulls, duplicates, keys that do not join, code values that differ by system) so gaps surface before build.
3. I design the model as a dimensional model: fact tables at a declared grain, conformed dimensions shared across subject areas, Type 2 slowly changing dimensions where history matters, and row-level security requirements such as region or business unit captured up front.
4. I validate early with wireframes and a prototype on real data, reconcile its numbers against existing reports or the finance system, and get sign-off on the metric definitions.
5. I also capture non-functional needs (dashboard response time, refresh schedule, concurrent users, export formats) and prioritise with MoSCoW so the first release is usable.

Follow-up

• Two departments define 'active customer' differently. How do you resolve it?
• A requested metric cannot be computed from the available data. What do you do?
• How would you measure whether the application is actually used?

What experience do you have with custom platforms that allow users to build self-service analytics and visuali

Medium · Business Intelligence and Enterprise Per

What experience do you have with custom platforms that allow users to build self-service analytics and visualizations?

Approach

1. The core is a governed semantic layer over curated warehouse data: business-friendly names, metric definitions and join paths defined once, as in the OBIEE repository's presentation layer, LookML or a Power BI dataset. Users build analyses on top without writing SQL.
2. Governance: certified datasets kept separate from sandbox areas, row-level security mapped to identity groups, masking of PII columns, and usage auditing to see who queries what.
3. Performance: aggregate tables or materialised views for common grains, caching, a deliberate choice between extracts and live queries, and guardrails (row limits, query timeouts) so ad hoc exploration does not overload the warehouse.
4. Adoption: a data dictionary, starter templates and short training, then monitoring which user-built reports are most used and promoting those to certified content.
5. I anchor the answer in one platform I built or supported, describing my own part with figures I can defend (number of users, datasets, reports).

Follow-up

• How do you stop the same KPI being defined five different ways by different users?
• A user-built report is slow and loads the warehouse. How do you handle it?
• How would you implement row-level security in the semantic layer?

How do you approach performing a fit-gap analysis for enterprise software packages like Oracle BI or Hyperion?

Medium · Business Intelligence and Enterprise Per

Approach

1. I begin with a prioritised requirements catalogue: reports and KPIs, planning, budgeting and consolidation processes, security roles, integrations and data volumes, each with a business owner.
2. I map each requirement against what the package delivers out of the box: prebuilt subject areas, ETL mappings and dashboards in Oracle BI Applications; forms, business rules and consolidation logic in Hyperion Planning or Financial Management. Each one is classed as fit, partial fit (configuration) or gap.
3. For each gap I choose a resolution (configure, extend with a custom subject area or ETL mapping, change the business process, use a workaround, or add a third-party tool) and estimate effort along with upgrade impact, since every customisation makes future patches and upgrades costlier.
4. I validate with conference-room pilots, walking business users through the package with their own data so partial fits are confirmed or reclassified.
5. The deliverable is a fit-gap matrix (requirement, classification, resolution, effort, owner, decision) that feeds scope, estimates and change control.

Follow-up

• The business insists on a customisation that will complicate upgrades. How do you handle it?
• How do you estimate the effort for a gap you have not built before?
• How do you tell a real gap from a process the business could change?

How do you translate qualitative business needs into quantitative analytical reporting solutions?

Medium · Business Intelligence and Enterprise Per

Approach

1. I turn the vague goal into specific questions and then into metrics with explicit definitions. For example, 'are customers happier?' becomes repeat-purchase rate, complaint rate per thousand orders and resolution time, each with a formula, grain, filters, time window and target.
2. I separate input metrics the team can act on from outcome metrics that move slowly. Where no direct measure exists I pick a proxy and state its limitation.
3. I check data availability and quality for each metric before building, and agree definitions with stakeholders on sample numbers so the first real report is not a surprise.
4. Report design follows the audience: a short summary against target and prior period for executives, drill-down for analysts, chart types matched to the comparison, and no vanity totals without context. I use medians for skewed values such as resolution time, because a few outliers distort the mean.
5. I record the definitions in a metric dictionary, reconcile against known figures, and revisit the report once usage shows whether it changes decisions.

Follow-up

• A stakeholder rejects a metric once it shows bad news. What do you do?
• How would you detect that a metric is being gamed?
• When would you report a median instead of a mean?

How do you optimize complex SQL and PL/SQL queries for large-scale relational databases?

Medium · Technical and Domain Knowledge

Approach

1. I start from the real plan, not a guess: DBMS_XPLAN.DISPLAY_CURSOR with ALLOWSTATS LAST (after a run with the gather_plan_statistics hint) to compare estimated rows with actual rows per step; a large gap usually means stale or missing statistics, fixed with DBMS_STATS and histograms on skewed columns.
2. Then access paths: an index on selective predicates, with equality columns before range columns in a composite index. A function on the column (TRUNC(order_date), UPPER(name)), an implicit type conversion or a wildcard at the start of a LIKE pattern stops a normal B-tree index from being used, so I rewrite the predicate or add a function-based index.
3. For joins I reduce rows before joining, select only needed columns, and check the join method: nested loops suit a small driving set with an indexed inner table, hash joins suit two large sets. Date-partitioned tables need predicates that allow partition pruning.
4. In PL/SQL I replace row-by-row loops that run one statement per row with a single set-based SQL statement, or BULK COLLECT with a LIMIT plus FORALL to cut context switches, and use bind variables so the statement is parsed once and shared.
5. I prove the gain with logical reads (consistent gets) and elapsed time on production-sized data, before and after, and check AWR or ASH for the top statements.

Follow-up

• A query got slow overnight with no code change. What do you check first?
• When does adding an index make performance worse?
• How would you stabilise a plan that flips between good and bad depending on bind values?

Hold a per-tenant active cap against concurrent creates

Hard · write skew · isolation levels · constraints

A tenant on the standard plan may hold at most 50 resources with status='active'. The create handler runs SELECT count(*) FROM resource WHERE tenant_id = $1 AND status = 'active', compares to 50, then inserts. Two creates arrive 3 ms apart on different instances and the tenant lands at 51. Name the anomaly, say whether PostgreSQL 16 READ COMMITTED or REPEATABLE READ prevents it and why, then give an implementation that holds the cap at READ COMMITTED with the exact statements. Finally, say what changes when the cap is 'at most one running export per tenant' on job_run.

Approach

1. Name it: write skew. The two transactions read an overlapping set and write disjoint rows, so there is no row-level conflict for the engine to detect and each commit is individually legal.
2. Rule out the levels precisely. READ COMMITTED takes a fresh snapshot per statement and takes no lock on the counted rows, so both see 49. PostgreSQL's REPEATABLE READ is snapshot isolation: it removes non-repeatable reads and phantoms within the snapshot but still admits write skew, because the anomaly is not a re-read of a changed row, it is a read of a set that a concurrent transaction invalidates. Only SERIALIZABLE closes it, by tracking the read dependency and aborting one transaction with SQLSTATE 40001 — a guarantee that exists only if the application re-runs the whole transaction from the read.
3. Convert the set predicate into a single-row conflict: keep tenant.active_resource_count and run UPDATE tenant SET active_resource_count = active_resource_count + 1 WHERE tenant_id = $1 AND active_resource_count < 50 in the same transaction as the INSERT. Zero affected rows is the cap, returned as 409. The row lock serialises the decision at any isolation level, and contention is bounded to one tenant's row — which is also the fair-scheduling unit, unlike a global counter that would convoy every tenant behind one row.
4. State the cost you just took on: a counter is a second source of truth that can drift, so every path that changes status must adjust it inside the same transaction, and a periodic reconciliation has to exist, with resource_revision as the authority for what the count should have been.

Follow-up

• A resource moves from archived back to active. Which statements change, and what breaks if the counter update and the status change land in different transactions?
• The cap becomes plan-dependent and a plan can change mid-month. Where does the number 50 live, and who reads it?

Can you explain how you would design and build a streaming data pipeline using big data technologies like Spar

Medium · Technical and Domain Knowledge

Can you explain how you would design and build a streaming data pipeline using big data technologies like Spark?

Approach

1. I start from the source and the freshness the consumer needs: events land in a replayable log (Kafka topic or Kinesis stream) partitioned by a key such as device or account id, and partition or shard count caps read parallelism.
2. In Spark Structured Streaming I read with readStream, parse against an explicit schema with from_json, and send records that fail parsing to a dead-letter table instead of failing the query.
3. For aggregations I window on event time and set withWatermark so late events within the bound are counted and state stays bounded; events older than the watermark are dropped, and append output mode with aggregation needs that watermark.
4. Fault tolerance comes from checkpointLocation (offsets plus state). End-to-end exactly-once needs a replayable source and an idempotent or transactional sink (Delta or file sink, or foreachBatch with a MERGE keyed on batchId); the Kafka sink is at-least-once.
5. I size it with maxOffsetsPerTrigger and the trigger interval, watch input rate against processing rate, batch duration and consumer lag, and compact small output files.

Follow-up

• How would you reprocess the last week of events after fixing a bug in the transformation?
• What happens to state and offsets if the sink is unavailable for an hour?
• How do you count events that arrive after the watermark has passed?

What are the key differences between batch and streaming data processing in distributed cloud environments?

Medium · Technical and Domain Knowledge

Approach

1. The core difference is bounded versus unbounded input: batch processes a complete dataset on a schedule with latency of minutes to hours, streaming processes events continuously with latency of seconds. Spark Structured Streaming runs micro-batches; Flink processes per event.
2. Correctness differs: a batch job can recompute a whole partition and be rerun or backfilled simply, while streaming needs event-time windows, watermarks for late data, a state store and checkpoints, plus an idempotent or transactional sink for exactly-once results.
3. Cost and operations differ: batch can run on ephemeral clusters (EMR, Dataproc, Databricks jobs) and spot capacity; streaming runs all the time and needs lag monitoring, autoscaling, and Kafka partitions or Kinesis shards sized for peak throughput.
4. Architecture choices: Lambda keeps a batch layer and a speed layer (two code paths that can disagree); Kappa uses one streaming path and replays the log to reprocess.
5. I decide from the consumer's freshness requirement: a daily finance report is a batch job, fraud or alerting on live events is a stream, and a dashboard refreshed every few minutes may only need frequent micro-batches.

Follow-up

• How do you backfill a streaming job after a logic fix?
• How do you keep a metric consistent when one team computes it in batch and another in a stream?
• When is micro-batch latency not good enough?

How do you handle unstructured big data sets within a microservices architecture?

Medium · Technical and Domain Knowledge

Approach

1. I keep large unstructured payloads (documents, images, logs) out of synchronous service calls: clients upload straight to object storage (S3, Blob Storage, GCS) with pre-signed URLs and multipart upload, and services pass a reference (URI, content hash, metadata) in an event. This is the claim-check pattern.
2. An ingestion service validates the upload, assigns an id, uses the content hash to dedupe, and writes the raw object immutably. It then publishes an event to a queue or log (Kafka, SQS, Pub/Sub).
3. Processing workers consume those events and extract structure (parsing, OCR, entity extraction). Each service writes to the store that fits its reads: a search index such as OpenSearch for full-text, a document database for metadata, the warehouse for analytics. Each service owns its own store.
4. Consumers are idempotent, keyed on the object id, with retries using exponential backoff and a dead-letter queue. Event schemas are versioned, ideally in a schema registry, so producers and consumers can change independently.
5. Workers scale on queue depth, and storage lifecycle rules move cold raw data to cheaper tiers. Keeping the raw zone means I can rerun extraction later without asking producers to resend.

Follow-up

• How would you reprocess every stored document after the parser changes?
• How do you handle a single multi-gigabyte file without exhausting worker memory?
• Which steps need ordering guarantees, and how do you get them?

How do you approach setting up and managing multi-environment production systems on AWS, Azure, or GCP?

Medium · Cloud Infrastructure and DevOps

Approach

1. I isolate environments at the account level (separate AWS accounts under Organizations, Azure subscriptions or GCP projects) so IAM, quotas and blast radius are separate, and build every environment from the same IaC modules with per-environment variables.
2. I build one immutable artifact per commit (a container image pinned by digest) and promote that same artifact through dev, staging and prod. Configuration comes from environment variables, Parameter Store or App Configuration, and secrets from Secrets Manager, Key Vault or Secret Manager, never baked into the image.
3. Networking and access: a separate VPC or VNet per environment with non-overlapping CIDR ranges if they will ever be peered, least-privilege roles, and prod access through audited break-glass roles rather than standing admin rights.
4. Release safety: staging mirrors prod topology, automated tests gate promotion, prod deploys use blue/green or canary with automatic rollback, and database migrations follow expand-then-contract so old and new code both run during rollout.
5. I tag resources by environment for cost reports and budgets, keep logs and metrics separated per environment, and run scheduled drift detection against the IaC.

Follow-up

• A release works in staging and fails in prod. How do you find the difference?
• How do you give staging realistic data without copying production PII?
• How do you ship an urgent hotfix without bypassing every gate?

How do you implement Infrastructure as Code using tools like Terraform or CloudFormation?

Medium · Cloud Infrastructure and DevOps

Approach

1. Both tools are declarative: I describe the desired state and the tool computes the diff. Terraform uses providers, resources and modules and keeps a state file; terraform plan shows the diff and apply executes it. CloudFormation manages state inside AWS as stacks, and change sets preview updates.
2. Terraform state lives in a remote backend with locking (S3 with a DynamoDB lock table or S3 native locking in recent versions, an Azure Storage container, or GCS), encrypted and never committed to git, because it can hold secrets.
3. Structure: small versioned modules (network, database, service), a root configuration per environment or per component to keep state small, pinned provider and module versions, and outputs to pass values between layers.
4. Pipeline: fmt and validate, static checks such as tflint or checkov, the plan posted on the pull request for review, and apply only after merge with an approval step. A scheduled plan reports drift.
5. Pitfalls I guard against: renaming a resource address means destroy and recreate unless I use a moved block or terraform state mv; prevent_destroy on databases; and import blocks or terraform import to adopt resources created by hand.

Follow-up

• Someone changed a security group in the console. What happens on the next plan, and what do you do?
• How would you split one large state file that has become slow and risky?
• When would you pick CloudFormation over Terraform?

How do you ensure high availability, security, and performance scaling in cloud-native applications?

Medium · Cloud Infrastructure and DevOps

Approach

1. Availability: stateless services behind a load balancer spread across availability zones, with health checks and autoscaling (auto scaling groups or the Kubernetes HPA). The database runs as a managed multi-AZ deployment with read replicas. I agree SLOs and RTO/RPO first and go multi-region only if those targets require it.
2. Resilience: timeouts on every call, retries with exponential backoff and jitter, circuit breakers and bulkheads so one slow dependency cannot exhaust threads, idempotency keys so retried writes do not double-apply, and queues to absorb spikes.
3. Scaling: scale out on CPU, latency or queue depth; cache with a CDN and Redis; treat the database as the usual bottleneck (connection pooling, read replicas, partitioning); load test to find the limit before users do.
4. Security: least-privilege IAM roles, workloads in private subnets, security groups and a WAF at the edge, TLS in transit, KMS-backed encryption at rest, secrets in a secrets manager, image scanning and patching, and audit logs such as CloudTrail.
5. Observability: metrics, structured logs and traces, with alerts on SLO burn rate and user-facing errors rather than raw CPU.

Follow-up

• Walk through what happens when one availability zone fails.
• How do you stop client retries from turning a partial outage into a full one?
• How would you scale a write-heavy relational database?

Can you explain how you integrate data sources using ETL concepts and data warehouse principles?

Medium · Business Intelligence and Enterprise Per

Approach

1. Extraction: a full load for small reference tables, incremental loads using a reliable watermark column, or change data capture from database logs (GoldenGate, Debezium) for large or frequently changing tables. Raw data lands unchanged in a staging area so loads can be replayed.
2. Transform and load: standardise codes, units and time zones, deduplicate, map keys across systems through master data, then load a Kimball star schema with facts at a declared grain, dimensions keyed by surrogate keys, and conformed dimensions shared across subject areas. In ELT the transforms run inside the warehouse (for example with dbt).
3. History: Type 1 slowly changing dimensions overwrite the attribute; Type 2 closes the current row (end date, current flag) and inserts a new one, so facts join to the version that was valid at the time.
4. Reliability: loads are idempotent (MERGE on the natural key, or overwrite a date partition) so a rerun cannot duplicate rows. Late-arriving facts are linked to an inferred dimension member that is updated later. Row counts and sums are reconciled between source and target, and an orchestrator (Airflow, Informatica, ODI) handles dependencies and retries.
5. Performance: bulk or direct-path loads, date partitioning, and incremental processing instead of nightly full reloads once volumes grow.

Follow-up

• A fact row arrives before its dimension row exists. What do you load?
• Write the SQL for a Type 2 dimension update.
• Yesterday's load must be rerun. How do you guarantee no duplicates?

Can you walk through your process for building and troubleshooting a continuous integration and continuous dep

Medium · Cloud Infrastructure and DevOps

Can you walk through your process for building and troubleshooting a continuous integration and continuous deployment pipeline?

Approach

1. Build: checkout, install dependencies from a lockfile with caching, lint and unit tests, then build the artifact once (a container image tagged with the commit SHA) and push it to a registry. Integration tests, a staging deploy and smoke tests come next, then a gated prod deploy (canary or blue/green) with automatic rollback on failed health checks.
2. Credentials: the pipeline gets cloud access through OIDC federation or the CI system's secret store rather than long-lived keys checked into config.
3. Troubleshooting starts at the first failing step's log, not the last line. I compare against the last green run: commits, dependency versions, runner image, environment variables, cache keys.
4. I sort the failure by cause: a flaky test (passes on rerun, so I check order dependence, time and shared state, then quarantine it and fix it), an unpinned dependency upgrade, a stale or corrupt cache, expired credentials, runner limits (out of memory, disk full) or network access to the registry.
5. For deploy-stage failures I check readiness and liveness probes, config or secrets missing in that environment, and migration ordering, and I reproduce by running the same image locally.

Follow-up

• A test passes locally and fails only in CI. How do you narrow it down?
• The pipeline has become too slow for the team. Where do you look for time?
• How do you roll back a release that included a database migration?

How would you approach debugging and refactoring an existing software module with performance bottlenecks?

Medium · Coding and Problem Solving

Approach

1. I measure before touching code: reproduce with representative input, record a baseline (latency, throughput, memory), then profile to find where time actually goes: cProfile with pstats or py-spy for Python, Java Flight Recorder or async-profiler for the JVM, EXPLAIN plans for database calls.
2. Then I classify the hot spot: algorithmic (nested loops doing lookups that a dict or set makes O(1) on average), I/O (an N+1 query pattern I can replace with one join or batch call), memory (loading a whole file when a generator would stream it), lock contention, or repeated work that caching or memoisation removes.
3. Before refactoring I pin behaviour with characterisation tests (golden inputs and outputs), so the refactor provably returns the same results.
4. I change one thing at a time and re-measure each step, in small reviewed commits (extract functions, separate I/O from pure logic), and add a benchmark or performance test to CI so the regression cannot come back silently.
5. I report the result in measured terms (p95 latency before and after, rows per second) and name the trade-off, such as cache staleness or extra memory.

Follow-up

• The profile shows time spread evenly with no single hot spot. What next?
• How do you prove the refactored module returns exactly what the old one did?
• When would you rewrite the module rather than refactor it?

Suggested practice checklist

The seven days follow the reported loop: coding and SQL for the screening and technical rounds first, then pipelines, cloud, BI and finally behavioral rehearsal. Each day produces something you can check, such as working code, a diagram or a spoken answer.

Day 1 — Map the loop and audit your stack

• Write the two reported stages (screening assessment, technical rounds) and list under each what candidates describe: multiple-choice domains, practical coding, system design, past projects, Python or Java.
• Rate yourself from 1 to 5 on Python, Java or Scala, SQL and PL/SQL, Spark, AWS, Azure or GCP, Docker, Terraform or CloudFormation, CI/CD, and OBIEE or Oracle BI.
• Pick the three lowest scores and the two projects you will walk through in the technical rounds.

Deliverable: A skills grid with ratings, the three weakest topics marked, and the two chosen projects named.

Day 2 — Python coding for the screening

• Write the star-pattern and multi-dimensional array task in Python, then in your main language, and note any syntax differences.
• Write the log-file script: read line by line, parse the error code with a regular expression, filter, count with a dictionary, skip malformed lines and print results sorted.
• Practise the logic-error question: talk through how you would find and fix a failing test case under time pressure.

Deliverable: Working Python for the star-pattern task and the log parser, plus a short list of the edge cases you tested.

Day 3 — SQL, PL/SQL and database tuning

• Write a multi-table join with conditional aggregation and read its execution plan; add an index and compare plans.
• List the tuning steps you would take on a slow query: plan, indexes, predicates that defeat indexes, join order, statistics, and PL/SQL row-by-row loops replaced by set-based statements.

Deliverable: One query with before-and-after plans and a one-page SQL and PL/SQL tuning checklist.

Day 4 — Streaming and batch data pipelines

• Draw the Spark streaming pipeline from source to sink, marking where duplicates, late events and restarts are handled.
• Write a batch versus streaming comparison covering latency, correctness, cost and operational effort, with one use case for each.
• Sketch how unstructured data moves through a microservices system: where raw data lands, which service parses it, and how schemas evolve.

Deliverable: Two diagrams (streaming pipeline, unstructured data in microservices) and a half-page comparison of batch and streaming.

Day 5 — Cloud, IaC and CI/CD

• Outline a dev, test and production setup on one cloud: separate accounts or projects, networking, secrets and promotion between environments.
• Write a small Terraform or CloudFormation resource definition and explain state, plan or change-set review, and drift.
• Write your CI/CD pipeline stages and a troubleshooting sequence for a failing deploy, then answer the high-availability, security and scaling question aloud.
• Prepare your Docker and orchestration story with one real failure you debugged.

Deliverable: An environment diagram, one infrastructure-as-code snippet, a pipeline stage list and a spoken Docker story.

Day 6 — BI, ETL and enterprise reporting

• Write the layers of an OBIEE repository and a row-level security example, or the equivalent semantic-layer concepts in the tool you know.
• Outline a fit-gap analysis for a packaged BI product such as Oracle BI or Hyperion: requirements, standard capability, gap, customization or workaround, effort.
• Describe an ETL flow into a star-schema warehouse and how you would translate a vague business need into a measurable report.
• Answer the self-service analytics and requirements-analysis questions aloud.

Deliverable: A fit-gap template filled in for an example requirement, an ETL-to-warehouse diagram and spoken answers to the BI questions.

Day 7 — Refactoring, testing and behavioral rehearsal

• Answer the performance-bottleneck refactoring question: profile first, change one thing at a time, keep tests green.
• Write your unit-test structure for software where failures are costly: unit, integration, edge and failure-path cases, and what runs in CI.
• Rehearse the behavioral questions aloud with a story each for shifting priorities, mentoring or migration, security and product collaboration, and a tight deadline, then the reasons for joining Ascentt.

Deliverable: Recorded answers to the behavioral prompts and a written testing and refactoring checklist.

Stories for the Ascentt behavioral questions

Candidates report behavioral questions about shifting priorities, mentoring and technical migrations, working with product owners and IT security, tight deadlines, and motivation for joining. For a client-facing engineering role, each story should show a decision you made, the trade-off involved and a result you can verify. Also be ready to turn experience questions about Docker or OBIEE into short, honest stories about what you built.

1. Why are you interested in joining Ascentt, and how do your professional goals fit its consulting and engineering model?

What is your experience with RPD modeling, OBIEE Answers, dashboards, and configuring integrated security setu

Medium · Technical and Domain Knowledge

What is your experience with RPD modeling, OBIEE Answers, dashboards, and configuring integrated security setups?

Approach

1. Answer from what you personally built. Walk the OBIEE repository in layers: the physical layer (imported tables, keys, joins, connection pools), the business model and mapping layer (logical tables, logical joins, dimension hierarchies, logical table sources, calculated measures) and the presentation layer (subject areas shown to users).
2. For Answers and dashboards, say what you created and why: analyses with prompts and filters, dashboard pages, and what you did when a dashboard was slow, such as aggregate tables, limiting columns or fixing a join that fanned out.
3. For security, separate three controls: who can log in and which application roles they hold, which subject areas and objects each role may see, and row-level data filters on logical tables. Give one concrete case, such as a regional manager who sees only one region's rows.
4. If your OBIEE exposure is thin, say so in the first sentence and map it to the nearest equivalent, for example a semantic layer or governed data model in another BI tool. A claimed skill you cannot defend ends the topic badly.

Follow-up

• How did you restrict rows by user, and where in the repository did that filter live?
• A dashboard that was fast last month now times out. What do you check first?
• Why model a logical dimension hierarchy instead of exposing physical tables directly?

What is your experience with Docker, containerization, and container orchestration tools?

Medium · Cloud Infrastructure and DevOps

Approach

1. Anchor the answer in one real system. State what ran in containers, how many services, and which parts you owned: Dockerfiles, base image choice, build pipeline, or orchestration configuration.
2. Show you understand the mechanics: layer caching and multi-stage builds to shrink images, a non-root user, pinned base image versions, image tags tied to a commit identifier, health checks, and CPU and memory limits.
3. For orchestration, name the tool you used (Kubernetes, ECS or another) and explain deployments, rolling updates, readiness versus liveness probes, and how configuration and secrets reached containers without being baked into the image.
4. Close with a failure you debugged, such as a container stuck in a restart loop or an image that was far too large, and the evidence you used to find the cause. If you only used Docker locally, say that and describe how you would move from compose to an orchestrator.

Follow-up

• How did you keep secrets out of the image and out of the repository?
• A container keeps restarting in production. Walk me through your first five minutes.
• Why would you pick an orchestrator over running containers directly on virtual machines?

How do you handle shifting project priorities and vague requirements when designing a new software service?

Medium · Behavioral and Process

Approach

1. Pick a project where the requirements were genuinely unclear or changed mid-way. Spend two sentences on the situation, then describe the mechanism you used to cope, not just your attitude.
2. Show the sequence: you asked clarifying questions, wrote down assumptions and got them confirmed, and split the work into a thin slice that delivered value early while the unclear parts were resolved.
3. Explain how you made the design tolerate change: stable interfaces between services, configuration instead of hard-coded rules, and a short decision log so stakeholders could see what had been settled.
4. When priorities shifted, say what you stopped or deferred, who agreed, and what it cost. End with the outcome and one thing you would now do earlier.

Follow-up

• What did you drop when the priorities changed, and who signed off on that?
• How did you decide which assumption was riskiest to confirm first?
• Describe a time your first reading of the requirement was wrong.

Can you describe a time when you had to mentor a junior developer or guide a team through a complex technical

Medium · Behavioral and Process

Can you describe a time when you had to mentor a junior developer or guide a team through a complex technical migration?

Approach

1. Choose a story where someone else grew or a migration actually landed. State who the junior developer or team was, what the migration or task was, and why it was hard in terms of risk, not just size.
2. Describe your plan in steps: an inventory of what had to move, an incremental cutover instead of a single switch, a rollback path, and written guidance the team could use without you.
3. Show how you taught rather than took over: pairing on the first case, code review with explanations, a small task with increasing scope, and agreeing what the person would own.
4. Give a result you can verify, such as the migration finishing without an outage, or the junior developer shipping a feature alone. Name one thing that went wrong and how you adjusted.

Follow-up

• What did you do when the junior developer fell behind or disagreed with your approach?
• How would you have rolled back if the cutover had failed halfway?
• How did you decide what to delegate and what to keep?

How do you collaborate with cross-functional teams, such as product owners and IT security, to resolve critica

Medium · Behavioral and Process

How do you collaborate with cross-functional teams, such as product owners and IT security, to resolve critical infrastructure issues?

Approach

1. Pick an incident or issue in which product and security concerns pulled in different directions, for example a vulnerability fix that threatened a release date, or an access change needed to unblock a pipeline.
2. State each group's goal in its own terms. Show that you translated technical risk into business impact for the product owner, and delivery impact into security terms for the security team.
3. Describe the options you brought with costs: fix now, mitigate and schedule, or accept with a recorded sign-off. Name who made the final call and how it was documented.
4. Report the result and what you changed afterwards, such as a security check in the CI/CD pipeline or an agreed escalation path, so the same conflict did not recur.

Follow-up

• What did you do when security and the product owner disagreed and neither would move?
• How did you communicate status to people outside engineering while the issue was open?
• What process change came out of it?

Tell me about a time when a project faced a tight deadline and how you managed your deliverables without compr

Medium · Behavioral and Process

Tell me about a time when a project faced a tight deadline and how you managed your deliverables without compromising code quality.

Approach

1. Open with the deadline and what was at stake in one or two sentences, then spend your time on the trade-offs you made.
2. Show scoping first: you separated must-have from nice-to-have, agreed the cuts with the stakeholder, and protected the parts that could cause real damage if wrong, such as payment, data integrity or security paths.
3. Name the quality practices you kept under pressure: tests on the critical paths, code review, small releases behind a flag, and a rollback plan. Be specific about what you deliberately skipped and recorded as follow-up work.
4. Finish with evidence the quality held, for example few defects after release or no rollback, and what you scheduled afterwards to pay down the shortcuts.

Follow-up

• Which feature or test did you cut, and why was that the safest cut?
• How did you tell the stakeholder that scope had to shrink?
• What happened to the shortcuts after the release?

Why are you interested in joining Ascentt, and how do your professional goals align with our consulting and en

Medium · Behavioral and Process

Why are you interested in joining Ascentt, and how do your professional goals align with our consulting and engineering model?

Approach

1. Build the answer from three pieces you can defend: what the role works on as candidates describe it (cloud platforms, data pipelines, BI and enterprise reporting for client projects), the part of that stack where you already have experience, and what you want to learn next.
2. Address the consulting and engineering model named in the question directly: client-facing delivery, changing project scopes and possible travel. Say why that mix suits you with an example from your own work, such as a client or stakeholder project.
3. Name one concrete area, such as streaming pipelines on Spark or semantic-layer work for self-service analytics, and explain how it connects to your next two or three years.
4. Avoid reciting a company slogan or generic admiration. If travel or project rotation does not suit you, say what you can do and ask about the arrangement honestly.

Follow-up

• What kind of project would you not want to take on, and why?
• How do you feel about travelling to client sites for an implementation?
• Where do you see your skills fitting best: cloud engineering, data pipelines or BI delivery?