Interview Question Bank
Real interview questions by role, each with guidance on what a strong answer looks like — not scripts to memorize, but the structure interviewers are listening for. Looking for algorithms instead? See the coding question bank.
Data Scientist Interview Questions
Data science interviews mix ML theory, practical judgment, and storytelling about impact. Interviewers care less about reciting formulas than about whether you can defend trade-offs you made on real projects.
Explain the bias–variance tradeoff and how it shows up in a real project.
Define both terms in one sentence each, then anchor them in a concrete decision: e.g. you chose a shallower gradient-boosted model because validation error rose with depth while training error kept falling. Close with how you diagnosed it (learning curves, cross-validation gap) rather than reciting theory.
How do you handle missing data in a dataset?
Show a decision process, not a single trick: first quantify missingness and whether it is random (MCAR/MAR/MNAR), then match the remedy — drop, impute (mean/median, model-based), or treat missingness itself as a feature. Mention leakage: imputation parameters must be fit on the training split only.
How do you evaluate a machine learning model beyond accuracy?
Pick metrics from the business cost of errors: precision/recall and PR-AUC for imbalanced classes, calibration when probabilities feed decisions, and a baseline comparison (majority class, current heuristic). Strong answers add a slice analysis — performance by segment, not just the global number.
Describe a time your analysis led to a real business decision.
Use STAR with numbers: the stake, what you did differently from the obvious approach, and the measured outcome ("churn model prioritized 20% of accounts, retention spend dropped 15%"). Interviewers probe follow-through — say how you knew the impact was causal (holdout, A/B, diff-in-diff).
How would you explain a complex model to non-technical stakeholders?
Demonstrate, don't describe: pick one model and translate it live ("the model scores each customer like a credit score; these three factors move it most"). Mention tools you actually use — SHAP summaries turned into plain-language drivers, or a one-page decision memo instead of a notebook.
How do you approach anomaly detection in a large dataset?
Frame it as: define "normal" first (seasonality, segments), then pick a method matched to label availability — statistical thresholds or isolation forests when unlabeled, supervised models when incidents are labeled. Say how you control the false-positive budget, because alert fatigue kills these systems.
How do you design and analyze an A/B test?
Cover the full arc: hypothesis and primary metric fixed up front, power analysis to size the sample, randomization unit chosen to avoid interference, and a pre-registered stopping rule. The senior signals are the failure modes — peeking, multiple comparisons, novelty effects — and one example where a test result surprised you.
Walk me through your feature engineering process.
Ground it in one project: how domain knowledge suggested candidate features, how you handled categoricals/time (target encoding, lags, windows), and how you validated that a feature earned its place (importance plus ablation, not vibes). Mention leakage checks — features computed with future information are the classic silent killer.
When do you reach for SQL versus Python or R?
Show a pragmatic split: SQL for pulling, joining, and aggregating at the source (push compute to the warehouse), Python/R once you need statistics, modeling, or plotting. The best answers mention moving work between them deliberately — "I prototype in pandas, then push the heavy groupbys back into SQL" — rather than loyalty to one tool.
How do you monitor a model in production?
Name the three layers: service health (latency, errors), data drift (input distributions vs training), and performance decay (predictions vs delayed ground truth). Say what triggers a retrain and who gets paged. A concrete story — "our fraud model degraded after a product change shifted the features" — beats a monitoring-tools shopping list.
Product Manager Interview Questions
PM interviews test structured thinking under ambiguity: prioritization, metrics fluency, and stakeholder navigation. Interviewers want a framework applied with judgment, not a framework recited.
Daily active users have gone down on our app. How do you investigate?
Structure first: clarify magnitude and timeframe, rule out measurement bugs, then segment (platform, geo, cohort, acquisition channel) to isolate where the drop lives. Only then hypothesize causes — a release, a marketing pause, seasonality, a competitor. End with the fastest disproof test, not a list of everything.
How do you prioritize features for a product roadmap?
Name a framework (RICE, impact/effort) but immediately show its limits: scores encode assumptions, so say how you pressure-test them — user evidence for reach, engineering spikes for effort. Strong answers include something you deliberately said no to and the strategic reason why.
Tell me about a product decision where data and intuition disagreed.
This probes judgment. Pick a real case: the metric said one thing, qualitative signal said another, and explain which you trusted and why (metric was a proxy, sample was biased, long-term vs short-term). The credible ending is what you did to resolve the conflict — a cheap experiment, not a leap of faith.
How do you measure the success of a product post-launch?
Tie metrics to the launch goal: adoption (activation rate), engagement depth (frequency, retention curve), and business outcome (revenue, cost). Distinguish leading vs lagging indicators, set a review checkpoint before launch, and say what result would make you roll back — pre-committing is what separates rigor from rationalizing.
How do you handle a feature request that conflicts with your product vision?
Show respect plus spine: dig into the underlying problem (the request is a proposed solution, not the need), quantify who else has it, and either solve the need in a vision-consistent way or explain the trade-off you are protecting. Escalate with options and a recommendation, never a flat no.
How do you keep engineering and business teams aligned?
Concrete mechanisms beat platitudes: a single written source of truth for priorities, engineers in discovery calls so context transfers early, and translating both directions — business asks framed as user problems, technical constraints framed as scope/time choices. Give one example where alignment broke and what you changed.
What metrics would you define for a brand-new product?
Structure by lifecycle: one north-star metric tied to delivered value, then supporting metrics along the funnel — acquisition, activation (define the "aha" moment precisely), retention, and a guardrail metric that catches you gaming the others. Explain why vanity metrics (downloads, page views) are excluded, and how the set changes after product-market fit.
Estimate the market size for this product.
The number matters less than the scaffolding: state your approach (top-down from population vs bottom-up from usage), write assumptions out loud, keep arithmetic simple, and sanity-check the result against a known anchor. End by naming which assumption moves the answer most — that is the part interviewers actually grade.
Pick a product you think is poorly designed. How would you improve it?
Choose something you genuinely use — not the interviewer's product. Diagnose with a framework (who is the user, what job are they hiring it for, where does it fail), propose one or two focused changes, and define the metric that would prove the improvement worked. Critique without a success metric reads as taste, not product thinking.
How do you communicate requirements to engineers?
Describe your written artifact (PRD, one-pager) and what it fixes: the problem, the user, success metrics, and constraints — while deliberately leaving the "how" to engineering. Mention the feedback loops around it: a kickoff review where engineers poke holes, and acceptance criteria concrete enough that "done" is not a debate.
Marketing Manager & Specialist Interview Questions
Marketing interviews reward candidates who connect creative work to measured outcomes. Every campaign story should carry a number and an attribution method.
Describe a successful marketing campaign you ran.
Structure: objective → audience insight → channel choice → result with attribution. The differentiator is the insight ("we found signups spiked from comparison searches, so we built comparison content") and honesty about what you would do differently. A campaign story without a control or baseline reads as decoration.
How do you measure the effectiveness of a campaign?
Lay out the funnel you instrumented: reach → engagement → conversion → retention/LTV, with the primary KPI fixed before launch. Address attribution head-on (UTM discipline, holdout geos, incrementality tests vs last-click) — naming the limits of your measurement is what senior interviewers listen for.
How do you conduct market segmentation and targeting?
Walk one real segmentation: the data you clustered on (behavioral beats demographic), how you validated segments are actionable (different message, channel, or price actually moves them), and how the targeting changed spend. Avoid textbook 4-quadrant answers with no dataset behind them.
What digital marketing tools and platforms do you use, and why those?
Group by job-to-be-done rather than listing logos: analytics (GA4 + a product-analytics tool), SEO (search console + a rank/keyword tool), automation/CRM, and creative testing. For each, one sentence on a decision the tool actually changed — tools you can't tie to a decision sound like résumé padding.
How do you use data to optimize an underperforming campaign?
Show the diagnostic order: verify tracking first, then decompose the funnel to find the broken stage (CTR fine but conversion poor → landing page, not the ad). Describe one structured test you ran (audience, creative, or offer — one variable), the result, and the kill criteria you set beforehand.
How have you optimized content for search (SEO)?
Demonstrate the full loop: keyword/intent research, content mapped to intent (not keyword-stuffed), technical hygiene (titles, internal links, page speed), and measured movement in impressions/position over months. Bonus credit for saying what didn't work — SEO stories with only wins sound borrowed.
How do you split budget between brand and performance marketing?
Show you understand the tension: performance is measurable and short-cycle, brand compounds but resists attribution. Anchor your split to stage and payback math (early-stage: mostly performance until CAC stabilizes; then shift as channels saturate). Name how you would measure brand anyway — search volume, direct traffic, incrementality geo tests.
How would you build a content strategy from scratch?
Lay out the sequence: audience and intent research first, a focused topic architecture (a few pillars, not fifty scattered posts), production cadence you can sustain, distribution baked in per piece, and a measurement loop that kills what fails. The differentiator is prioritization logic — why these topics first — not the list of channels.
You have $10k for a product launch. Where does it go?
Resist spending it all on ads. Strong answers allocate against the goal: a slice to creative/landing-page quality, a testing budget across two or three channels with explicit kill criteria, and a reserve to double down on the winner. Show the math per channel (expected CPC → conversions) and what you would do differently at $100k.
What would your first 90 days in this role look like?
Structure in thirds: learn (audit funnels, meet sales/product, read the data before changing anything), quick wins (one or two fixes with visible impact — often tracking hygiene or an underperforming page), then a plan with owners and metrics. This question screens for judgment and humility; arriving with a rigid playbook reads as neither.
Financial & Business Analyst Interview Questions
Analyst interviews test technical mechanics (modeling, statements, SQL) plus the judgment to sanity-check outputs and communicate what the numbers mean.
Walk me through a DCF analysis.
Hit the mechanics in order — project free cash flows, choose a discount rate (WACC and how you built it), terminal value (growth vs exit multiple), discount and sum — then show judgment: which assumption the valuation is most sensitive to and how you sanity-check against multiples. Mechanics without sensitivity analysis reads as memorized.
How do you analyze financial statements to assess a company's health?
Connect the three statements instead of listing ratios: profitability trend (income statement), cash conversion (cash flow vs net income — divergence is the classic red flag), and leverage/liquidity (balance sheet). Name 3–4 ratios you actually start with and one time a ratio told a misleading story.
Describe your experience with budgeting and forecasting.
Describe the cadence you owned (annual budget, rolling forecast), your method (driver-based beats line-item extrapolation), and accuracy: variance analysis you ran, the biggest miss, and the process change it caused. Interviewers probe whether your forecasts fed real decisions or just decks.
Describe a complex business problem you analyzed. What was your process?
Pick a problem with genuine ambiguity. Show the shape: define the question sharply, break it into drivers, gather data (and handle its gaps honestly), test the leading hypothesis, and land on a recommendation someone acted on. The phrase to earn: "here is what I would have gotten wrong without the data."
How do you ensure accuracy and reliability in your analysis?
List concrete habits: reconcile totals against an independent source, build sanity checks into models (balance checks, magnitude tests), version and document assumptions, and have someone else break your model before it ships. Admitting one error you caught late — and the check you added — lands better than claiming zero errors.
What tools do you use for analysis, and how do you choose?
Match tool to task: Excel for models others must audit, SQL for pulling and reshaping data at source, Python/R when the analysis needs statistics or automation, BI (Tableau/Power BI) for recurring self-serve views. One migration story ("moved a weekly Excel report to SQL + dashboard, saved N hours") proves it.
Describe the most complex SQL query you have written.
Pick one with real structure — multi-step CTEs, window functions, or a tricky deduplication — and narrate the business question it answered, not just the syntax. Explain one performance decision (why you filtered early, what the join order cost) and how you verified correctness against a known total. Complexity without verification is a red flag, not a flex.
Walk me through a variance analysis you performed.
Show the decomposition discipline: actual vs plan, split into price/volume/mix (or the equivalent drivers for your domain), isolating each factor's contribution. Then the judgment layer — which variances were noise vs signal, and what decision the analysis changed. End with how the process improved the next forecast cycle.
How do you build a KPI dashboard executives actually use?
Start from decisions, not data: interview the audience for the three questions they ask weekly, put those on top with targets and trends, and push everything else to drill-downs. Mention the operational half — data freshness, a single owner per metric definition, and deleting charts nobody opens. Adoption is the success metric of the dashboard itself.
Tell me about a time your analysis was wrong.
Choose an error with stakes, explain how it slipped through (bad join, survivorship bias, stale assumption), and — the part being graded — how it was caught and what check now exists because of it. Owning the miss and institutionalizing the fix reads as senior; claiming you have never shipped a wrong number reads as unexamined.
Behavioral (any role) Interview Questions
These recur in nearly every interview regardless of role. Prepare each as a 90-second story with a number in it — then stop talking.
Tell me about yourself.
Present → past → future, 90 seconds: what you do now (one line with scope), the two or three experiences that built the skill this role needs, and why this role is the logical next step. Tailor the middle to the job description; do not recite your résumé chronologically.
Tell me about a time you failed.
Choose a real failure with real stakes (not "I work too hard"), own your specific contribution to it, and spend most of the answer on the system you changed afterward. The interviewer is testing whether you convert failure into process — end with a later win that used the new process.
Describe a conflict with a coworker and how you resolved it.
Keep it professional-disagreement, not personal drama. Show that you sought their reasoning first, found the shared goal, and moved to a resolution mechanism (data, a trial, escalating a clean decision). Never make the other person the villain — interviewers imagine themselves as that coworker.
Why do you want to work here?
Two layers: something specific about the company you could only know by doing homework (product direction, a launch, an engineering post), connected to your own trajectory. Generic praise ("great culture") signals a mass-applied candidate; specificity is the entire game.
Tell me about a time you led without authority.
Pick a cross-functional situation: you saw the gap, built alignment by making others' goals easier (not by escalating first), and shipped a result you can quantify. This question screens for the influence muscle — the mechanics of HOW you persuaded matter more than the outcome.
Where do you see yourself in five years?
Show direction without a rigid script: the capability you want to deepen, the scope you want to grow into, and how this role compounds toward it. Companies are screening for retention risk and self-awareness, not for a precise org-chart prediction.
What is your greatest weakness?
Pick a real, non-disqualifying weakness (not a humblebrag), then spend two-thirds of the answer on the management system: the concrete habit or process you built around it and one measurable sign it is working. The question tests self-awareness plus improvement machinery — "I'm a perfectionist" fails both.
Tell me about a time you disagreed with your manager.
Show productive dissent: you disagreed on substance, made your case with evidence in private, and then — whichever way it went — committed fully to the decision. Include one case where you turned out wrong and said so. Interviewers are screening for both spine and coachability; stories with a villain fail.
Describe delivering under a tight deadline.
The skill being probed is scope triage, not heroics. Walk through how you cut to the essential slice, communicated the trade-offs early, and shipped the thing that mattered — then what you cleaned up afterward. All-nighter stories without a prioritization decision inside them read as poor planning, not dedication.
Why are you leaving your current job?
Face forward: one honest, neutral sentence about the limit you hit (scope, growth, direction), then pivot to what this role offers that the current one cannot. Never disparage the employer — the interviewer maps whatever you say onto how you will one day talk about them. Keep it under thirty seconds.
Software Engineer Interview Questions
Engineering interviews outside the coding screen are about judgment: how you choose, how you recover, and how you work with people who disagree. Algorithm practice lives in the coding question bank; these are the rounds that decide the level you are offered.
Walk me through a system you designed end to end. What would you change now?
Lead with the constraint that drove the design (traffic shape, latency budget, team size, deadline), not the technology list. The senior signal is one thing that broke in production and what it taught you, plus a specific boundary you would draw differently today.
Tell me about the hardest bug you have debugged.
The value is in the method, not the symptom: how you narrowed it down (bisect, logging, a reliable repro) and which assumption turned out to be wrong. Finish with what you changed so that class of bug surfaces faster next time.
How do you decide between shipping fast and building it properly?
Answer with a real tradeoff you made and the reversibility test behind it: a one-way door deserves the extra week, a reversible one usually does not. Say whether the cleanup you promised actually happened - admitting it did not is more credible than pretending.
Describe a code review where you disagreed with the author.
Show that you separate taste from substance. Appeal to something external - a bug class, a contract, a benchmark - rather than preference, and say how the disagreement closed: a test that settled it, a pairing session, or you conceding.
How do you approach testing code you did not write?
Characterization tests first to pin current behaviour, then coverage on the paths that actually carry risk. Say what you decided NOT to test: treating coverage as a budget rather than a target is the experienced answer.
Tell me about a production incident you owned.
Give the timeline with a clock: detection, mitigation, root cause, prevention. Interviewers listen for whether you stopped the bleeding before you fully understood the cause, which is usually the right order, and for a prevention item that shipped.
How do you keep a large refactor from stalling?
Describe keeping it shippable at every step: migrate one slice behind a seam, run both paths, delete the old one. Name the metric that told you it was working and the piece you deliberately left un-migrated.
What technical decision on your team do you disagree with?
Pick a real one and state the other side fairly, including why the team chose it. Ending with the experiment that would settle it lands better than certainty.
Data Analyst Interview Questions
Analyst interviews test whether you can be trusted with a number. Expect questions about validating unfamiliar data, explaining uncertainty to people who will act on it, and knowing when the data cannot answer the question.
How do you validate a dataset you have never seen before?
Give the checklist you actually run: row counts against the source, key uniqueness, date coverage, null and outlier profile, then reconciliation against a number somebody already trusts. The real skill is what you do when reconciliation fails, so say that part out loud.
A dashboard metric dropped 20% overnight. Walk me through your first hour.
Check the instrumentation before the business: a pipeline failure and a real drop look identical on a chart. Then segment - platform, region, new versus returning - and line it up against release and campaign timelines. Naming the tracking-bug hypothesis first is the experience tell.
How do you decide which metric a team should care about?
Tie it to a decision it will change. A strong answer names the metric, the way it can be gamed, and the guardrail metric you pair with it so nobody optimises the business into a corner.
Tell me about a time your analysis changed someone's mind.
Use STAR and keep the resistance in the story: who disagreed, which specific evidence moved them, and what you would have done if it had not. Analysis that met no friction rarely mattered.
How do you explain statistical uncertainty to a non-technical stakeholder?
Translate into decision language - roughly what range of outcomes, and what you would do at each end - instead of putting a p-value on a slide. Say explicitly what a null result would mean for the plan.
A query that used to run in seconds now takes minutes. What do you do?
Read the plan before rewriting anything: filter early, index what you filter on, cut rows before joining, and materialise what runs daily. Mention the case where the right fix was upstream in the warehouse model rather than in the query.
How do you handle a request the data cannot answer?
Say so early, then offer the nearest question the data can answer plus the cost of answering the real one - instrumentation, a survey, a holdout. Quietly shipping a misleading proxy is the failure mode here.
Tell me about a report you built that nobody used.
Be honest, then diagnose: no owner, wrong cadence, or it answered a question nobody is measured on. The best version ends with what you killed or replaced it with.
Project & Program Manager Interview Questions
Delivery interviews are about what you do when the plan stops being true. Interviewers probe escalation timing, how you make tradeoffs visible, and whether your status reporting survives bad news.
Tell me about a project that slipped. What did you do?
Say when you knew, who you told, and what you cut. Early escalation with options beats heroics at the end, and interviewers are listening for which one you did.
How do you run a status update that people actually read?
Decisions first, risks with named owners and dates, then what changed since last time. Say how you keep it honest when the news is bad - a status that is green until it is red teaches people to ignore it.
Two teams need the same engineer next sprint. What do you do?
Take the tradeoff to whoever owns the priority, with each option costed in dates rather than adjectives. Avoid the non-answer of talking to both sides and hoping.
How do you manage a stakeholder who keeps adding scope?
Make the tradeoff visible instead of refusing: yes, and here is the date it moves to - which do you want? Mention the written change log that stops the same conversation repeating.
Describe a risk you caught before it became a problem.
How you found it matters: dependency mapping, a pre-mortem, or a quiet engineer you made it safe to speak up. Then the mitigation and what it cost.
How do you know a project is actually on track?
Prefer leading indicators - open dependencies, review latency, scope churn - over status colours, and note that a working demo beats a percentage complete.
Tell me about a time you delivered bad news to leadership.
Structure: headline, cause, options with costs, your recommendation. Say how you avoided burying it in slide fourteen.
How do you close a project?
Acceptance criteria checked, an owner named for the ongoing work, and a retro that changed exactly one thing. Projects that are never closed are how teams accumulate invisible work.
Sales & Account Executive Interview Questions
Sales interviews are a live demonstration: how you qualify, how you handle an objection, and whether you can be honest about a loss. Expect to be asked for numbers and for the deal that went wrong.
Walk me through a deal you lost and why.
Name the real reason rather than price, which is usually the symptom. The credible version ends with what you changed in qualification so the same loss does not repeat.
How do you qualify an opportunity?
Use your framework as a checklist, not a script: who signs, what breaks if they do nothing, and the date that forces a decision. Say which deals you disqualified and how much time that gave back.
A prospect goes quiet after a strong demo. What do you do?
Assume their priorities shifted rather than rudeness. Describe multi-threading to a second stakeholder, a genuinely useful touch, and the honest close - asking whether to close it out often gets a reply.
How do you handle the objection that you are too expensive?
Reframe against the cost of the status quo, quantified with their numbers, and never discount without trading for something. Naming a deal you walked away from makes it believable.
Tell me about your most difficult negotiation.
Separate their position from their interest, then say which concession you traded and which you refused. Interviewers are listening for whether you protected the relationship and the margin.
How do you build pipeline in a brand new territory?
Segment, pick the wedge where you win fastest, then sequence outreach. Give your real numbers - touches, reply rate, meetings - because vague activity answers read as no answer.
What do your first 30 days on a new product look like?
Read the last five wins and losses, learn the one demo moment that lands, and find a technical partner. Say what you would be able to do unaided by day 30.
Tell me about a forecast you got wrong.
Explain how you separate commit from best case, which signal you over-weighted, and the discipline you added afterwards. Forecast honesty is most of the job.
Customer Success & Support Interview Questions
These interviews look for judgment under pressure: triage when everything is urgent, honesty when you cannot fix it today, and the instinct to spot a quiet account before it churns.
Tell me about an angry customer you turned around.
Acknowledge, own the timeline, then say what actually changed - a fix, a credit, a process. The part interviewers care about most is the follow-through after the fire was out.
How do you prioritise when five tickets are all urgent?
Impact times blast radius, against contractual commitments. Say who you told about the ones you deprioritised, because silent deprioritisation is what turns a queue into a complaint.
A customer asks for a feature that will never be built. What do you say?
Be direct rather than hopeful, then solve the underlying job with what exists today. Log it with the business impact attached so product can see the pattern rather than a wish.
How do you spot an account about to churn?
Admin-level usage decline, a departed champion, tone change in tickets, skipped reviews. Then describe one intervention that actually worked and one that did not.
Describe a time you pushed back on your own company for a customer.
Give the internal argument and the evidence you brought, plus what you promised the customer while it was unresolved. Promising nothing you could not control is the mature version.
How do you run a review the customer values?
Lead with the outcomes they are measured on, not your feature list. Bring one recommendation and one ask - a meeting with no ask is a status update.
Tell me about a mistake that cost a customer's trust.
What you told them, how quickly, and what you changed in the process afterwards. Speed of disclosure is the whole answer.
How do you handle an issue you cannot fix today?
An honest ETA or an honest lack of one, a workaround, and an agreed check-in cadence you keep. Accounts are lost to silence far more often than to bugs.
UX & Product Designer Interview Questions
Design interviews test how you decide, not how you render. Expect questions about the research you skipped, the constraint you designed around, and how you handle a stakeholder who wants something worse.
Walk me through a design decision you got wrong.
Say how you found out - research, analytics, a support queue - what you changed, and how fast. Portfolio stories where nothing ever fails read as fiction.
How do you decide what to research before designing?
Pick the riskiest assumption and match the method to it: five interviews for a why, analytics for a how many, a survey for a distribution. Say what you would have shipped without it.
A stakeholder wants something that hurts usability. What do you do?
Restate their goal, propose an alternative that meets it, and offer a cheap test rather than a debate about taste. Say where you escalate when it stays a disagreement.
How do you handle feedback in a critique?
Separate the reaction from the diagnosis and ask for the problem rather than the proposed solution. Describe how you run a critique when you are the one giving feedback.
How do you measure whether a design worked?
Pair a behavioural metric with a task-success or effort measure, and say what you would do if the number moved for the wrong reason - more clicks is not always better.
Tell me about designing under a hard technical constraint.
Name the constraint, the options you traded away, and where you deliberately spent the flexibility you had left. Constraints are where the interviewer sees your priorities.
How do you keep a design system from becoming a straitjacket?
Rules for when deviation is allowed, a contribution path that is actually used, and an audit that catches drift before it becomes a second system.
What does accessibility mean in your day-to-day work?
Be concrete: contrast, focus order, target size, labels a screen reader can use, and one thing you caught in review last month. Vague commitment is the tell that it is not happening.