cohort Data Engineer Interview: Questions, Experience & Prep (2026)

Cohort currently has 5 open Data Engineer roles, based on knok jobradar data from July 2026. Candidates report a process that typically spans 3-4 rounds, covering SQL, data pipeline design, Python, and system thinking. This guide brings together commonly reported question patterns, sample answers, and a focused prep plan so you walk in confident.

The broader market has 542 Data Engineer openings across India right now, with Bangalore leading at 92 roles and Delhi at 66. Cohort's 5 openings represent a focused hiring push, which typically means a consistent bar across rounds and interviewers who compare notes carefully.

Candidates report these question types coming up most often in Cohort Data Engineer interviews. Prepare solid answers for all of them before your first round.

1. Walk me through a data pipeline you built end-to-end. What tools did you use and why?
2. How do you handle late-arriving data in a streaming pipeline?
3. Write a SQL query to find the second-highest value in each group (for example, the second-highest salary per department).
4. Explain the difference between a star schema and a snowflake schema. When would you choose each?
5. How would you design a data warehouse for an e-commerce platform from scratch?
6. A pipeline that ran fine yesterday is now failing. Walk me through how you debug it.
7. What is data partitioning and how does it improve query performance?
8. How do you ensure data quality at each stage of an ETL pipeline?
9. Explain the CAP theorem and how it applies to a distributed data system you have worked on.
10. How would you optimise a slow-running Spark job?
11. Describe a time you had to work with messy or incomplete data. What did you do?
12. How do you version control your data pipelines and manage schema changes over time?

Use the STAR format (Situation, Task, Action, Result) for all experience-based questions. Here are three worked examples.

Q: Walk me through a data pipeline you built end-to-end.

*Situation:* My team at a mid-sized fintech was pulling transaction data from five different payment gateways into a spreadsheet manually every morning.
*Task:* I was asked to automate this and make the data available in our BI tool by 8 AM daily.
*Action:* I built an Airflow DAG that pulled data from each gateway API, applied standardisation transforms in Python, loaded it into a Redshift table, and set up dbt models for the BI layer. I added email alerts for failures and row-count checks after each load.
*Result:* The manual process that previously took the team two hours every morning was fully automated. The pipeline ran reliably for over a year, and the team caught a payment gateway bug early because the row-count alert fired when volumes dropped unexpectedly.

---

Q: Describe a time you had to work with messy or incomplete data.

*Situation:* We were building a customer churn model and the CRM data had null values across a large share of the 'last login date' column.
*Task:* I needed to clean the data without simply dropping those rows, since that would have biased the model toward active users.
*Action:* I traced the nulls back to a CRM migration where the field had not been mapped correctly. For pre-migration customers I back-filled the date using login event logs from a separate system. For cases where no log existed, I flagged the rows with an 'unknown activity' label and created a separate feature for the model.
*Result:* The model trained on the cleaned dataset performed meaningfully better. I also documented the data quality issue so future analyses would not repeat the same mistake.

---

Q: How did you handle a pipeline failure in production?

*Situation:* A nightly batch job that fed our revenue dashboard stopped partway through one night, and stakeholders noticed incorrect numbers the next morning.
*Task:* I was on-call and needed to identify the cause, fix it, and restore accurate data before the morning leadership review.
*Action:* I checked the Airflow logs and found an out-of-memory error on a Spark step processing a large partition. I re-ran that step with increased executor memory, then ran a reconciliation query to identify which downstream tables had stale data and triggered manual refreshes for those.
*Result:* Data was accurate before the review started. I also added a dynamic partition-size check to the DAG so the job would auto-scale before hitting memory limits in the future.

For system design questions (pipeline design, warehouse design): Start with requirements. Ask about data volume, update frequency, query patterns, and SLA before jumping to tools. Interviewers want to see structured thinking, not just tool name-dropping.

For SQL questions: Think out loud. State your approach before writing the query. Mention edge cases like ties or null values. Cohort interviewers typically care as much about your reasoning as the final result.

For debugging questions: Use a layered approach. Check the error message, then the data, then the code, then the infrastructure. Naming each layer shows you have debugged real pipelines, not just studied theory.

For 'tell me about a time' questions: Use STAR and keep the Situation and Task brief. Spend most of your time on Action (what you specifically did, not what the team did) and a concrete Result. Avoid vague results like 'it went well'.

For tool or technology questions: Answer what you know, then connect it to a real project. Saying 'I used Spark for X and found Y to be a common gotcha' is stronger than a textbook definition.

Based on what candidates typically report from Data Engineer interviews at product companies, here is what matters most at a place like Cohort.

Hands-on depth over theory. Interviewers will probe past your first answer. If you mention Kafka, expect a follow-up on consumer group lag or exactly-once semantics. Have at least two real projects you can discuss in depth.

Clear communication about trade-offs. Data engineering rarely has one right answer. Saying 'I chose Redshift over BigQuery because our team was already on AWS and the latency was acceptable' shows judgment. Saying 'Redshift is better' does not.

Ownership mindset. Cohort, like most product companies, wants engineers who think beyond their own task. Mentioning that you set up monitoring, wrote documentation, or trained a colleague on a pipeline signals that you take ownership.

SQL fluency. This comes up in almost every DE interview. Be comfortable with window functions, CTEs, and writing queries from scratch without an IDE.

Curiosity and directness. Candidates report that interviewers respond well to sharp, specific questions. Asking 'I noticed Cohort is hiring for 5 DE roles right now, are you building a new platform or scaling an existing one?' is the kind of question that lands well.

A focused 2-3 week plan based on what candidates typically find most useful for product-company DE interviews.

Week 1: Core skills.
Work through a solid set of SQL problems covering window functions, joins, and aggregations. Review your strongest pipeline project and write out the STAR story for it. Revise key concepts: partitioning, indexing, data modelling (star vs snowflake), and CDC (change data capture).

Week 2: System design and tools.
Practice one end-to-end system design problem per day (design a logging pipeline, design a fraud detection data store, design a real-time dashboard). Revisit the internals of tools listed on your resume. If you listed Spark, be ready to explain the difference between narrow and wide transformations and how to tune memory.

Week 3: Mock interviews and company research.
Do 2-3 mock interviews with a peer or out loud to yourself. Research what Cohort builds and think about what data problems they likely face. Prepare 3-4 thoughtful questions to ask your interviewer.

Day before the interview.
Re-read the job description. Map your experience to each requirement listed. Sleep well. Have a glass of water nearby during the call.

Jumping straight to tools. Many candidates say 'I would use Spark and Kafka' before understanding requirements. Always clarify volume, latency, and access patterns first.

Memorising SQL answers without understanding them. Interviewers often change one condition mid-question. If you memorised the solution, you freeze. Practice writing queries from scratch every time.

Being vague about your own projects. 'I worked on a data pipeline for my company' is not enough. Know your row counts, table counts, latency SLAs, and failure handling. These details separate strong candidates from average ones.

Underselling results. Candidates often skip the Result in STAR answers or say something generic. A concrete, specific result is far more memorable than 'it worked well'.

Not asking questions. Ending the interview with 'no, I think I have everything' is a missed opportunity. Prepare 2-3 genuine questions about the team, the data stack, or the problems they are currently solving.

Over-explaining tools you barely used. If a tool is on your resume but you only used it in one small project, say so honestly. Interviewers respect honesty and probe hard on anything that looks inflated.