Data Architect Interview Questions in India (2026)

Data Architect is one of the most senior technical roles in India's data ecosystem, and the interview process reflects that seniority. You are expected to show deep knowledge of data modelling, distributed systems, cloud platforms, and the ability to align data strategy with business goals.

As of mid-2026, knok job radar is tracking 57 open Data Architect positions across India. Delhi has the highest count with 8 openings, followed by Bangalore with 7 and Chennai with 5. Hyderabad shows 2 openings and Pune has 1. The market is active but concentrated in a few cities, so consider remote or hybrid roles if your preferred city has few listings.

Interview processes at most companies run three to five rounds: a recruiter screen, a technical deep-dive, a system design or case-study round, and a leadership and behavioural panel. Some companies add a take-home assignment. This guide covers the questions candidates commonly report, with worked answers and a realistic preparation plan.

1. Walk me through an ML model you shipped to production. What was the business impact?
2. How do you handle imbalanced datasets in a fraud-detection use case?
3. Explain bias-variance trade-off with an example from your work.
4. How would you design an A/B test for a recommendation model?
5. SQL vs Python for feature engineering, when do you use each?
6. Tell me about a time your model performed poorly post-deployment. What did you do?

Q: A business wants to migrate from an on-premise data warehouse to the cloud. How do you approach it?

Start by auditing the current state: catalog all data sources, document volumes, query patterns, SLA requirements, and data ownership. Then define the target architecture, choosing a platform (such as BigQuery, Snowflake, or Redshift) based on cost, ecosystem fit, and team skills. Select a migration strategy: lift-and-shift works for quick wins, but re-architecting often pays off for long-term performance. Run a pilot with one low-risk workload to surface surprises early. Set up data validation checkpoints to confirm no data loss and no quality regression. Finally, run the old and new systems in parallel for a period before decommissioning on-prem to reduce risk and build stakeholder confidence.

---

Q: Design a real-time fraud detection data architecture for a payments company.

The architecture needs two paths: a hot path for millisecond decisions and a cold path for model training and reporting. On the hot path, transaction events flow through a streaming platform (Apache Kafka or AWS Kinesis) into a stream processing layer (Apache Flink or Spark Streaming) where rules and ML model scores are applied, and the decision is written back within the transaction window. On the cold path, all events land in a data lake (S3 or GCS), are processed in batch, and feed a feature store that the ML team uses to retrain fraud models. Key design decisions include idempotent writes to avoid double-processing, a feature store shared between training and serving to eliminate training-serving skew, and a feedback loop so confirmed fraud cases re-enter training data. Monitoring dashboards track false-positive rates so operations teams can tune thresholds without waiting for a full model release.

---

Q (Behavioural): Describe a situation where a data architecture decision you made turned out to be wrong. What did you do?

Situation: At a previous role, I proposed a centralised monolithic data warehouse to consolidate reporting across five business units, believing it would simplify governance.

Task: After six months it became clear the design was creating a bottleneck: every team had to wait for a central team to model their data, and the warehouse could not handle the varied latency requirements.

Action: I ran a retrospective with stakeholders, acknowledged the design gap openly, and proposed a shift toward a data mesh approach where each domain owned its own data product, with a shared governance layer for common standards. I drew up a phased migration plan to avoid disrupting existing reports.

Result: Domain teams gained autonomy, the central team shifted to a platform-engineering role, and time-to-insight for new reporting requests improved significantly. The key lesson: a governance model that ignores team topology will always struggle.

STAR for behavioural questions: 20% situation, 10% task, 50% action, 20% result with numbers.

CIRCLES for product cases (PM): Comprehend, Identify customer, Report needs, Cut through prioritisation, List solutions, Evaluate trade-offs, Summarise recommendation.

For system design (engineering): clarify scale (DAU, QPS), draw high-level boxes, deep-dive one component, discuss failure modes and monitoring.

Signals that move Data Architect candidates forward in India:
- Ownership of outcomes, not tasks
- Comfort with ambiguity and incomplete data
- Collaboration with cross-functional partners
- Understanding of India-specific constraints (UPI, logistics, multilingual users, price sensitivity)
- Realistic salary expectations aligned with level

Week 1: Audit your knowledge and fill gaps

List the core topics from the section above and honestly rate yourself on each. Spend the first week reading and revising areas where you feel least confident. Focus on distributed systems and cloud platform fundamentals if you come from a purely on-prem background. Review the basics of whichever cloud platform appears most often in the job descriptions you are targeting.

Week 2: System design practice

Pick one architecture scenario each day (fraud detection, recommendation engine, real-time analytics, data migration, multi-tenant SaaS data platform) and design it from scratch on paper or a whiteboard. Think through the components, data flow, failure modes, and cost implications. Practice explaining your design out loud, as if presenting to an interview panel. After each session, note two things you would improve next time.

Week 3: Mock interviews and behavioural preparation

Do mock interviews with a peer or a practice platform. For behavioural questions, prepare three to four STAR stories covering: a time you influenced without formal authority, a failed technical decision and what you learned, a situation where you simplified complexity for a business audience, and a time you had to push back on an impractical requirement. Practise these stories until they feel natural, not scripted.

Week 4: Company-specific research and final polish

For each company you are interviewing with, research their data stack (often visible on engineering blogs or in job descriptions), their industry, and their scale. Tailor one or two scenario answers to their specific context. Revisit any weak spots flagged in your mock interviews. In the day before each interview, do a light review rather than cramming.

Knok checks 150+ job sites nightly, applies to jobs matching your resume, and messages HR for you, so while you are preparing, new Data Architect openings are being tracked and applied to on your behalf.

• Rambling without a clear result metric
• Badmouthing previous employers
• Quoting global salary data without India context
• Ignoring the 'why this company' question
• Over-indexing on frameworks without showing real shipped work

Questions are grouped by theme. Candidates report that system design and scenario questions carry the most weight at the senior level.

Fundamentals

1. What is the difference between a data warehouse, a data lake, and a data lakehouse? When would you choose each?
2. Explain the CAP theorem. How does it guide your choice of database for a distributed system?
3. What is data lineage, and why does it matter at enterprise scale?
4. Walk us through the layers of a modern data platform: ingestion, storage, processing, and serving.
5. What is the difference between OLTP and OLAP, and how do you design schemas differently for each?

Design and Scenario

1. A business wants to move from an on-premise data warehouse to the cloud. How do you approach the migration?
2. Design a real-time fraud detection data architecture for a payments company.
3. Our data pipelines are breaking frequently and data quality is poor. How would you diagnose and fix this at scale?
4. How would you handle slowly changing dimensions (SCDs) in a data warehouse, and which SCD type do you prefer for a given use case?
5. How do you design for data governance: access control, data classification, and audit trails?

Behavioural

1. Tell me about a time you had to convince non-technical stakeholders to adopt a new data platform or architecture.
2. Describe a situation where a data architecture decision you made turned out to be wrong. What did you do?

Data Modelling and Storage

Relational modelling (3NF, star schema, snowflake schema), slowly changing dimensions and their types, dimensional modelling best practices, NoSQL data models (document, wide-column, key-value, graph), and when to use each.

Distributed Systems Concepts

CAP theorem, consistency models (eventual vs. strong), partitioning and sharding strategies, replication, and fault-tolerance patterns. Interviewers at product companies probe this area deeply, so do not treat it as optional revision.

Cloud Data Platforms

Hands-on familiarity with at least one major cloud: GCP (BigQuery, Dataflow, Pub/Sub), AWS (Redshift, Glue, Kinesis), or Azure (Synapse, Data Factory). Know the cost models and when managed services make sense versus self-managed clusters.

Batch and Streaming Pipelines

Apache Spark for batch, Apache Kafka and Flink for streaming. Understand Lambda vs. Kappa architecture trade-offs. Know common pipeline failure modes and how to build for observability (dead-letter queues, data quality checks, alerting).

Data Governance and Security

Data classification, role-based access control (RBAC), column-level security, data masking, and audit logging. DPDP Act compliance is increasingly relevant in India as of 2025 and 2026, and interviewers at BFSI and health-tech companies ask about it directly.

Modern Data Stack Tools

dbt for transformation, Airflow or Prefect for orchestration, Delta Lake or Apache Iceberg for open table formats, and a data catalogue tool such as Apache Atlas or Collibra.

Architecture Patterns

Data mesh, data fabric, medallion architecture (bronze, silver, gold layers), and event-driven architectures. Be ready to compare these patterns and explain when each fits, not just name them.

Behavioural and Leadership Skills

Stakeholder communication, building consensus across engineering and business teams, and articulating trade-offs in plain language. Senior panels often evaluate this as seriously as technical depth.

Going straight to a solution without clarifying requirements. In system design rounds, interviewers want to see you ask questions first: what is the scale, what are the SLA requirements, what is the team's existing stack? Jumping to an answer before clarifying looks like overconfidence and often leads to a design that misses the actual need.

Ignoring cost and operability. A technically elegant architecture that is expensive to run or hard to operate will not impress a senior panel. Always mention cost trade-offs and how the system will be monitored in production.

Treating behavioural questions as less important. At the Data Architect level, leadership and communication are evaluated as seriously as technical skill. Prepare proper STAR stories. Vague answers like 'I worked with the team to sort it out' do not pass the bar at this level.

Over-indexing on one cloud or one tool. If you only know one cloud platform deeply, acknowledge it but show you understand the underlying concepts well enough to reason about any platform. Interviewers value depth of reasoning over brand familiarity.

Not knowing the 'why' behind your choices. Saying 'I would use Snowflake' is not enough. You need to explain why: the pricing model suits variable workloads, the separation of compute and storage fits the use case, the team already has the skills. Always follow a tool recommendation with the reasoning.

Forgetting data governance and compliance. In India, data residency and the DPDP Act are live concerns. If you design an architecture without mentioning access control, audit trails, or data classification, senior interviewers at regulated industries such as BFSI or health tech will notice the gap immediately.