Custom Solution Development Questions

Focuses on designing and delivering bespoke technical solutions to meet specific customer or project requirements. Candidates should explain how they gather requirements, translate needs into technical designs, build prototypes, iterate with stakeholders, validate solutions, and deliver production quality implementations. Discussions may include architectural decision making, trade off analysis, integration with existing systems, customization of third party software, testing strategies, documentation, and how to measure success and maintainability. Provide examples of complex customizations, how constraints were managed, and how technical and non technical stakeholder feedback was incorporated.

EasyTechnical

46 practiced

Describe best practices for provisioning repeatable development environments for multiple teams working on a custom solution. Cover infrastructure-as-code choices (Terraform, ARM/Bicep), data masking or synthetic data strategies, and how to keep dev environments affordable and close to production for reliable testing.

Sample Answer

Start by defining goals: reproducible, versioned, secure, cost-controlled environments that mirror production enough for reliable testing.

Infrastructure-as-Code- Choose Terraform for multi-cloud/portable stacks; use providers per cloud and a module-per-service pattern. Use a remote state backend (S3/GCS + Dynamo/Storage bucket locking) and workspaces or per-team state files to isolate environments.- Use ARM/Bicep when targeting Azure-native teams for tighter integration and simpler parameterization. Keep templates modular and expose parameters for sizing, SKU, and feature flags.- Enforce policy as code (Sentinel/OPA) and CI linting (tflint, Checkov) before apply. Store modules in a registry and version pins in root configs.

Data strategies- Prefer synthetic data for new features where realistic distributions matter; generate using scripts that mirror cardinality, referential integrity, and schemas.- For masked production copies, implement deterministic, reversible masking for debugging (tokenization) or one-way hashing for sensitive fields. Automate masking pipelines: exported snapshot → mask job (spark/python) → load to dev DB.- Maintain anonymization tests to assert no PII remains and preserve referential integrity.

Keeping costs low- Use smaller SKUs, reserved/spot instances, or burstable types for dev. Implement autoscaling and schedules to shut down non-prod resources outside work hours.- Provide “dev-light” and “dev-full” flavors; default to dev-light and allow on-demand promotion (self-service) to dev-full for integration testing.- Use ephemeral environments per feature branch with short TTLs and automated cleanup.

Automation and governance- Build a CI/CD pipeline to provision environments on branch creation and destroy on merge. Expose a self-service catalog (Terraform Cloud, Azure DevOps, GitHub Actions + templates).- Tagging, cost center labels, and budget alerts per environment; weekly cost reports to teams.- Keep secrets out of IaC (Vault/Key Vault) and inject at runtime.

Testing fidelity- Use shared staging that mirrors prod for end-to-end, and smaller isolated devs for day-to-day. Regularly refresh dev data cadence (weekly) and validate parity of key behaviors via smoke tests.

Summary: Modular IaC + remote state + policy-as-code, deterministic masking or synthetic data pipelines, tiered environment sizes with schedules and autoscaling, and CI-driven ephemeral environments deliver repeatable, secure, affordable dev environments that remain close enough to production for reliable testing.

HardTechnical

57 practiced

Design a migration plan from a heavily customized on-prem ERP to a SaaS ERP while preserving business logic. Address strategies for handling custom workflows, data model differences, incremental cutover, reconciliation, training, and fallback plans if the migration exposes business-critical gaps.

Sample Answer

Requirements & constraints:- Preserve existing business logic (SLAs, approvals, tax rules), minimize downtime, phased go-live, regulatory/compliance needs, rollback tolerance, target SaaS capabilities/APIs.

High-level approach:1) Discovery & design- Inventory customizations: catalog workflows, extensions, integrations, reports, and data entities; prioritize by business-criticality and frequency.- Classify each customization: adopt-as-standard (configurable in SaaS), re-implement using SaaS extension points (business rules engine, custom fields), or implement outside via middleware (microservices) if SaaS cannot support.- Define success criteria, KPIs, and cutover acceptance tests.

2) Mapping & implementation strategy- Build canonical data model and transformation layer to map on‑prem schema → SaaS model; document field/semantics gaps.- For complex workflows, design one of: - Native re-build using SaaS workflow engine (preferred for maintainability) - Extension using SaaS plugins/webhooks - External orchestration service (middleware) to preserve logic without cluttering SaaS- Create automated test suites that validate business rules end-to-end.

3) Data migration & reconciliation- Staged ETL: extract → transform → load into sandbox, validate, then to production.- Use incremental delta syncs (CDC) to minimize cutover delta.- Reconciliation strategy: row- and business-level checksums, aggregated financial balances, sample transactions, and automated reconciliation reports. Set tolerance thresholds and alerting.

4) Incremental cutover & parallel run- Phased by module (e.g., Procurement → Inventory → Finance) or by business unit.- Run both systems in parallel for a defined period; reconcile daily until stable.- Use feature flags and routing proxies to gradually move traffic to SaaS.

5) Training & change management- Role-based training: administrators, power users, end users; hands-on sandbox workshops and runbooks.- Provide playbooks for exception handling, escalation paths, and quick-reference guides.- Pilot group feedback loop to iterate workflows and training materials.

6) Monitoring, KPI gates & fallback- Predefined gates: data reconciliation pass rates, functional test success, user acceptance sign-off, performance SLAs.- Fallback plan: until gate closure keep canonical source writable on on‑prem; implement reverse sync for critical transactional windows. For critical gaps discovered post-cutover, have documented rollback procedures per module and emergency integration adapters to route transactions back to on‑prem while fixes are developed.- Post-migration: 90-day hypercare with dedicated SME on-call, automated health dashboards, and a backlog for incremental improvements.

Trade-offs & governance:- Rebuilding natively increases maintainability but may require process change; middleware preserves logic quicker but adds operational overhead.- Establish steering committee to arbitrate decisions, prioritize must-haves vs. nice-to-haves, and manage risk.

This plan balances risk (parallel runs, reconciliation, rollback options), preserves business logic through careful classification and middleware/extensions, and ensures operational readiness through phased cutover and targeted training.

EasyTechnical

45 practiced

Describe how you'd configure a Jira project and workflow to support a custom development lifecycle: discovery → prototype → build → QA → UAT → production. Include recommended issue types, custom fields for technical context, automation rules (e.g., transition on PR merge), and how you integrate this with Confluence and CI tools for traceability.

Sample Answer

I’d design a Jira project that maps directly to the lifecycle: Discovery → Prototype → Build → QA → UAT → Production, with clear issue types, fields, automations and integrations so stakeholders and engineers have traceability.

Project & Workflow- Custom workflow statuses: Backlog, Discovery, Prototype, Ready for Build, In Progress (Build), Code Review, QA, UAT, Ready for Prod, Released.- Enforce transitions with required fields and validations (e.g., cannot move to Ready for Build without Design Artifact).

Issue types- Epic (feature / customer outcome)- Capability / Feature (grouping)- Story (development work)- Spike / Research (Discovery)- Prototype (POC)- Bug- Task / Chore- Release (to track production rollout)

Custom fields (technical context)- Architecture Link (Confluence page URL)- Design Owner (user picker)- Components impacted (multi-select)- Risk / Rollback Plan (text)- DB / Infra Changes (checkbox + link)- Deployment Window (date/time)- CI Build ID / Artifact Version (automated)

Automation rules- On PR merged to main -> transition linked Story to “Code Review” or “Ready for QA”; add comment with PR URL and build artifact. (Integrate Bitbucket/GitHub)- When CI job passes for commit tagged with jira-key -> transition issue to “QA” and populate CI Build ID field.- When QA passes -> automatically create UAT checklist subtask and notify product owner.- On issue moved to Released -> trigger deployment pipeline or post webhook to CD tool; add Release note to Confluence.- Auto-link commits/PRs by parsing branch names that include Jira keys.

Confluence & traceability- Template pages: Architecture, Design Decisions, Test Plan. Each Story/Spike references a Confluence page via Architecture Link field.- Use Jira macros in Confluence to show live sprint/epic status and release notes.- Maintain a Release Notes page auto-populated from JQL that filters Release issues.

CI/CD integration- Connect Jira to CI (Jenkins/GitHub Actions/Bitbucket Pipelines) to push build status, artifact versions, test results and code coverage into issue fields and comments.- Store artifact version and pipeline URL in CI Build ID field for reproducible deployments.

Operational practices- Enforce branch naming convention: feature/JIRA-123-description to enable automatic linking.- Use Automation audit and periodic cleanups to close stale Prototype issues.- Create dashboards: Release readiness (blocked, in QA, failing builds), Tech Debt, Traceability matrix (requirements → design → commits → build → release).

Why this works- Mirrors business lifecycle for stakeholders.- Ensures technical context is captured (design, infra, rollback).- Automations reduce manual state drift and enforce traceability from Confluence design to code and deployments.

MediumSystem Design

46 practiced

You must integrate point-of-sale (POS) streams into an ERP system for a large retailer. Design an integration pattern that satisfies near-real-time updates, deduplication of events, idempotency, and resilience to outages. Describe middleware choices (Kafka, Event Hub, message queues), schema strategy, and how you'd validate data consistency.

Sample Answer

Requirements & constraints- Near-real-time (seconds), high throughput from many POS terminals, guarantee no double-posting to ERP, survive outages, support replay and auditing, measurable data consistency.

High-level pattern (event-driven, durable buffer)POS -> API gateway / edge aggregator -> Kafka (central event bus) -> stream processors -> ERP adapters (to ERP inbound APIs/CDC)

Middleware choices & trade-offs- Kafka (preferred): durable, high-throughput, partitioning for scale, retention+compacted topics for replay and dedupe, strong ecosystem (Kafka Streams/ksql, Connect). Supports exactly-once semantics (EOS) end-to-end with Kafka Streams + transactional writes.- Azure Event Hubs / AWS Kinesis: viable managed alternatives; less mature exactly-once features but workable with consumer-side idempotency.- Traditional MQs (RabbitMQ, SQS): good for simple queues but weaker for large-scale replay/history and high-throughput stream processing.

Schema strategy- Use a schema registry (Avro/Protobuf/JSON Schema). Avro or Protobuf recommended for compact binary, schema evolution, and enforcement.- Topic design: - raw-pos-events (append-only, retention window) - dedup-compacted (keyed by global event-id or transaction-id; compaction keeps latest state) - processed/erp-intent (validated, canonical payload mapped to ERP model)- Include metadata: source-id, terminal-id, event-id (UUID), sequence-number, timestamp, schema-version, checksum.

Deduplication & idempotency- Event producers assign globally unique event-id (UUID or ULID) and per- terminal monotonic sequence.- In Kafka: use event-id as message key and write to a compacted topic; processors can check whether event-id already exists.- Consumer-side idempotency: ERP adapter performs idempotent operations (upsert by business-key or record event-id write-ahead table in ERP DB). Use transactions: write to ERP and commit offset transactionally (Kafka transactional producers or two-phase commit pattern).- For exactly-once: Kafka Streams with EOS + transactional writes to output topics; if ERP supports idempotent API, simpler: idempotent POSTs keyed by event-id.

Resilience to outages & backpressure- Edge aggregators buffer locally and batch forward when connectivity restored.- Kafka provides durable retention; processors can replay after outage.- Implement exponential backoff and circuit-breakers for ERP calls; route failed records to a DLQ (Kafka DLQ topic) for manual/automated remediation.- Rate-limit and scale consumers horizontally by partitioning by business-key (store-level partitions to preserve order per terminal).

Validation & data consistency- Real-time checks: schema validation, checksum verification, business-rule validation in stream processors; invalid records -> quarantine topic.- Periodic reconciliation: nightly or hourly aggregate compare between POS totals and ERP totals (by store/day/hour) using unique event-id counts and checksums.- Use change-data-capture (CDC) from ERP to Kafka to cross-check writes (end-to-end verification). Implement alerting on divergence thresholds.- Observability: metrics (lag, throughput, error rates), distributed tracing (trace id through event), and automated reconciliation dashboards.

Operational concerns & security- SLA-driven retention and partition count sizing; capacity plan for peak shopping seasons.- Encryption in transit and at rest, RBAC for schema registry and Kafka, and audit logs.- Runbook for DLQ remediation, replays, and schema evolution.

Why this design- Kafka + schema-registry provides durable, auditable stream with replay and compacted dedupe semantics. Combined with idempotent ERP writes and reconciliation gives near-real-time updates while preventing duplicates and enabling robust outage recovery — matching enterprise retailer needs.

HardSystem Design

56 practiced

Design a multi-tenant custom SaaS architecture serving 1,000 enterprise tenants with isolated data and per-tenant customizations. Discuss data architecture (shared schema with tenant_id vs isolated DB), deployment model, schema migrations, onboarding automation, CI/CD implications, and cost vs isolation trade-offs.

Sample Answer

Requirements & constraints- 1,000 enterprise tenants, strict per-tenant data isolation and some tenant-specific customizations, cost-conscious, high availability, automated onboarding.

High-level recommendation- Hybrid multi-tenant model: shared application layer (single codebase), two-tier data strategy: shared-schema for low-to-mid customers; isolated DB/schema (or dedicated DB cluster) for large/high-compliance tenants. This balances cost and strict isolation.

Data architecture- Shared-schema (tenant_id column): - Pros: low cost, easy scaling, fewer DB instances, simpler ops. - Cons: noisy-neighbor risk, harder per-tenant backup/restore, regulatory concerns.- Isolated DB (per-tenant schema or DB instance): - Pros: strong isolation, per-tenant backups/restore, custom tuning, easier compliance. - Cons: higher cost, more operational overhead, connection pooling limits.- Hybrid decision rule: SLA/compliance, data volume, and performance determine isolation level. Use tagging (tenant.metadata.isolation_level).

Deployment model- App: containerized microservices on Kubernetes. Single codebase, per-tenant feature flags and config stored in a config service.- Routing: API gateway with tenant-aware routing and rate-limiting.- DB: multi-tenant pool for shared schema; tenant-specific connection strings for isolated DBs (managed by a connection broker).- Secrets/config per-tenant stored in vault.

Schema migrations- Use versioned, backward-compatible migrations (Flyway/Liquibase/DBMate). Principles: - Always deploy additive (new columns/tables); avoid destructive migrations in same release. - Run migrations in two phases: platform-level (shared DBs) and isolated DBs. For isolated DBs, run migrations via orchestration (K8s Job) per-target in parallel with rate limits. - Support online toggles: deploy code that supports both vN and vN+1 schema, then flip feature flags, then clean up old schema in a later release. - Maintain migration metadata per-tenant for isolated DBs; include retry and rollback plans.

Onboarding automation- Self-serve provisioning pipeline: - IaC templates (Terraform/CloudFormation) to provision network, DB (shared schema assignment or new DB), service accounts, secrets, monitoring. - Orchestrator service triggers migrations, seeds tenant config, assigns quotas, and notifies billing. - Health checks and smoke tests post-provisioning. - For isolated tenants, automate creation of read replicas, backups, and alerting policies.

CI/CD implications- Single pipeline for application code; environment-aware deployment templates.- Feature flags and config to enable per-tenant customization without branching.- For isolated-DB tenants, a separate migration & deployment stage that targets tenant DBs; keep these runs idempotent.- Canary/canary-by-tenant: roll out features to a small percentage of tenants or specific tenants.- Automated tests: unit, integration with a sandbox tenant, and per-tenant contract tests. Include DB migration tests against representative schemas (shared and isolated).- Monitoring + automated rollback triggers on error/latency/DB metrics.

Operational concerns & trade-offs- Cost vs isolation: - Shared schema: lowest cost, but limited for strict compliance/perf. Good for most tenants. - Per-tenant DB: higher cost (~DB instance per big tenant), but required for compliance and noisy-neighbor protection. - Consider grouping tenants into pools (sharded DBs by tenant group) for middle ground.- Security & compliance: encryption at rest, per-tenant key management for isolated DBs, strict RBAC, audit logs.- Backup & recovery: per-tenant restore easier with isolated DBs; with shared schema, implement row-level export tools and tenant extraction tooling.- Scalability: scale app horizontally; scale DB by pooling, read replicas, and sharding for heavy tenants.- Observability: tenant-tagged metrics, distributed tracing, per-tenant SLA dashboards.

Final decision heuristic- Default to shared-schema for cost-efficiency; automatically upgrade a tenant to isolated DB when they exceed thresholds (data size, throughput, compliance). Provide clear SLAs and pricing tiers reflecting isolation and operational costs.

Unlock Full Question Bank

Get access to hundreds of Custom Solution Development interview questions and detailed answers.

Join thousands of developers preparing for their dream job.