Deutsche Telekom Digital Labs Data Scientist Interview: Questions, Experience & Prep (2026)

Deutsche Telekom Digital Labs (DTDL) is Deutsche Telekom's technology and product engineering hub in India, building AI, analytics, and platform solutions for one of Europe's largest telecom groups. The company had 175 open roles on knok jobradar as of mid-2026, with Data Scientist positions spread across product analytics, network intelligence, and customer experience domains.

The Data Scientist interview at DTDL typically covers machine learning fundamentals, statistics and probability, SQL and Python coding, and at least one business or case-style discussion. Candidates report a strong focus on Telco-specific problem framing, such as churn prediction, network anomaly detection, and customer lifetime value modelling. Interviewers want to see that you can move from a vague business question to a structured modelling plan, and then communicate results to a non-technical audience.

Salary ranges from knok jobradar data (as of 2026) are:

Bangalore has the highest concentration of Data Scientist openings at DTDL and across the market generally, with 166 of the 937 total Data Scientist roles knok tracked nationally.

The questions below are drawn from candidate reports and the kind of problems DTDL teams work on. Expect a mix of conceptual, coding, and situational questions across rounds.

1. Walk me through an end-to-end machine learning project you owned. How did you handle data quality issues at each stage?
2. How would you build a churn prediction model for a telecom customer base? What features would you engineer and why?
3. Explain precision and recall. In a network fault detection scenario, which matters more and how would you justify that choice to the business?
4. You have a heavily imbalanced dataset for fraud or anomaly detection. What techniques would you use and what are their trade-offs?
5. How do you ensure a model that performs well offline also performs well in production? What monitoring would you put in place?
6. Describe a time you disagreed with a stakeholder about interpreting model results. How did you resolve it?
7. How would you design an A/B test to measure the effect of a personalised offer on plan upgrades? What would you measure and for how long?
8. Explain how a Random Forest works. When would you choose it over XGBoost or a simple logistic regression?
9. Write a SQL query to find the top customers by data usage in each city for a given billing month.
10. What is regularisation? Compare L1 and L2 and give a scenario where each is the better choice.
11. How would you communicate a model's limitations to a product manager who wants to deploy it immediately?
12. Deutsche Telekom operates across multiple markets. If your model is trained on one market's customer data, what issues arise when applying it to a different market?

Use these as templates. Replace the specifics with your own project experience.

Q: How would you build a churn prediction model for a telecom customer base?

*Situation:* At a previous role, the retention team had no systematic way to identify customers likely to leave and was spending outreach budget on low-risk accounts.

*Task:* I was asked to build a churn prediction model so the team could prioritise who to contact before their contract renewal window.

*Action:* I started by defining 'churn' precisely with the business team, since the label itself was ambiguous across different contract types. I then combined usage data including call drop rates, data consumption trends across rolling windows of several recent weeks, billing disputes, and support ticket counts. I trained a logistic regression as a baseline, then an XGBoost model using stratified k-fold cross-validation because the churn class was a minority. I chose the probability threshold by plotting the precision-recall curve and aligning it with the team's actual outreach capacity.

*Result:* The model gave the retention team a ranked list to work from. Post-deployment reviews showed a clear improvement in outreach efficiency over the previous untargeted approach, consistent with what industry surveys cite as typical lift for Telco churn models.

---

Q: Describe a time you disagreed with a stakeholder about interpreting model results.

*Situation:* A product manager wanted to present our recommendation model results to senior leadership, but she was framing the model's output as certainty rather than probability.

*Task:* I needed to correct this framing before it led to over-confident business decisions, without delaying the presentation or damaging the working relationship.

*Action:* I set up a short working session and walked through concrete examples: cases where the model gave a high score but the customer did not convert, and cases where a low-score customer did. I reframed the output as a 'likelihood ranking' rather than a guarantee, and suggested we present it with a clear note on the model's confidence range. I also prepared a one-page summary of model assumptions and known limitations for the appendix.

*Result:* The stakeholder appreciated the transparency. Leadership asked good questions about edge cases rather than challenging the model outright, which opened a productive conversation about next improvements and built more durable trust in the team's work.

---

Q: You have a heavily imbalanced dataset for network fault detection. How do you handle this?

*Situation:* I was working on a model to flag network nodes likely to fail within a short operational window. Actual failures were a small fraction of total observations.

*Task:* Build a classifier that catches real faults without flooding the ops team with false alarms.

*Action:* I first checked whether the imbalance was a real-world condition or a data collection artefact. After confirming it was real, I tried three approaches: adjusting class weights in the loss function, SMOTE oversampling on the minority class in the training set only (never leaking into validation or test sets), and adjusting the decision threshold after training. I evaluated all three using F1 and precision-recall AUC rather than accuracy, since accuracy is misleading on imbalanced data. I also held a separate discussion with ops about what false positive rate was operationally acceptable before finalising the threshold.

*Result:* The class-weight adjustment combined with threshold tuning gave the best balance for the team's capacity. The model entered a pilot and surfaced alerts at a rate the ops team validated as accurate, consistent with what industry surveys report for similar network monitoring systems.

For machine learning design questions: Start by clarifying the business problem and success metric before touching any algorithm. Then cover data (what you have, what you would need, quality risks), feature engineering rationale, model selection with reasons, evaluation strategy, and how you would deploy and monitor. Interviewers at DTDL want to see you think in systems, not just in algorithms.

For statistics and probability questions: State your answer clearly first, then prove you understand the intuition behind it, not just the formula. When explaining concepts like p-values or confidence intervals, always link them to a business decision. Reciting textbook definitions without context reads as memorisation.

For SQL and coding questions: Think out loud. State your assumptions upfront (for example, 'I am assuming one row per customer per day'), write readable code with clear aliases, and check your own query for edge cases like NULLs or duplicates before declaring it done.

For stakeholder and conflict questions: Use the STAR format: Situation, Task, Action, Result. Keep the Situation brief, spend most of your time on Action, and make the Result specific and business-connected. A story where something went wrong but you recovered and learned is often more compelling than a smooth success.

For Telco-specific questions: DTDL works on real telecom problems. Show you understand concepts like ARPU, customer lifetime value, network KPIs, and the behavioural differences between postpaid and prepaid customers. You do not need prior Telco experience, but you should have read up on the domain before your interview.

Strong ML and statistics fundamentals. DTDL interviews test whether you genuinely understand what you are doing, not just whether you can import a library. Expect questions where the right answer depends on context, and be prepared to defend your choices when probed.

Production and scalability awareness. With millions of customers in the Deutsche Telekom ecosystem, interviewers want to know you think about model drift, retraining pipelines, latency, and what happens when a model fails silently. Mentioning MLOps concepts naturally, not as buzzwords, is a clear positive signal.

Telco domain curiosity. You do not need prior Telco experience, but candidates who have done basic research on churn drivers, network quality metrics, or telecom product economics consistently report a smoother interview experience. This preparation is noticeable and appreciated.

Clear communication. Data Scientists at DTDL work with product managers, engineers, and business stakeholders. Interviewers will assess whether you can explain a complex model decision in plain language. Practise explaining your past projects to someone who is not a data scientist.

Ownership mindset. Questions about end-to-end projects and disagreements with stakeholders are testing whether you treat your work as your responsibility or wait to be directed. Show initiative and follow-through in every answer, even for projects that did not go perfectly.

Step 1: Nail the fundamentals. Review core ML concepts: bias-variance trade-off, overfitting, cross-validation, regularisation, and evaluation metrics beyond accuracy. For statistics, focus on probability distributions, hypothesis testing, and Bayesian thinking. These come up in almost every DTDL round candidates report.

Step 2: Practise Telco use cases. Before your interview, be able to speak fluently about churn prediction, customer segmentation, network anomaly detection, and lifetime value modelling. Map at least one of these to a project from your own experience, even if the domain was different.

Step 3: Sharpen your SQL. Write window functions, self-joins, and aggregation queries by hand. DTDL data roles regularly test SQL. Practise on realistic datasets with nulls, duplicates, and multi-table joins until you can write clean queries without looking anything up.

Step 4: Prepare your STAR stories. Have three or four strong project stories ready: one where you solved a hard data problem, one where you influenced a non-technical stakeholder, and one where something went wrong and you recovered. Each story needs a clear business outcome.

Step 5: Research DTDL specifically. Look up what products DTDL builds, which business units they support, and what their job descriptions reveal about their stack. Python, Spark, and MLflow are commonly cited in DTDL postings. Tailoring even one example to their context makes a difference.

Step 6: Do a spoken mock interview. Explain your most complex project out loud to someone who will ask follow-up questions. Most candidates are surprised how differently an answer sounds when spoken versus rehearsed silently. Record yourself if no practice partner is available.

Jumping to a model before defining the problem. Many candidates launch into 'I would use XGBoost' before clarifying what success looks like or what data exists. DTDL interviewers specifically look for structured thinking first, algorithm choice second.

Using accuracy as the only metric. For the imbalanced datasets common in Telco work (fraud, faults, churn), accuracy is misleading. Always mention precision, recall, F1, or AUC-PR, and explain why the chosen metric fits the specific problem.

Memorising answers without understanding the depth. If you say 'I used SHAP for explainability,' be ready to explain how SHAP values are computed and when they can mislead. Interviewers will probe past the surface answer.

Weak SQL under pressure. Candidates who list SQL on their resume but stumble on window functions or subqueries lose credibility quickly. Practise writing queries from scratch, not just reading them.

Ignoring business context in answers. A model answer that ends with 'the metric improved' without mentioning what the business actually did with the model reads as incomplete. Always connect technical work to a business decision or outcome.

Not asking clarifying questions. In case-style rounds, diving straight into a solution without asking 'what does the business want to optimise?' or 'what data do we actually have?' signals inexperience. Interviewers expect and reward the clarification step.