Senior Data Analyst Interview Preparation Guide - FAANG Standards

Direct answer

Compare each incoming staging row to the current dimension row by business key: if a tracked attribute changed, close out the current row (current_flag = false, effective_to = today) and insert a new row with a new surrogate key and current_flag = true. In SQL this is usually written as a two-step UPDATE-then-INSERT, or as a single MERGE where supported.

Structured elaboration

• Step 1, detect and close changed rows: UPDATE product_dim SET effective_to = CURRENT_DATE - 1, current_flag = false WHERE current_flag = true AND product_id IN (SELECT product_id FROM stg_products s WHERE s.price <> product_dim.price OR s.name <> product_dim.name). Compare every tracked attribute, not just one, or you will miss changes.
• Step 2, insert new versions: INSERT INTO product_dim (product_key, product_id, name, price, effective_from, effective_to, current_flag) SELECT new_key(), s.product_id, s.name, s.price, CURRENT_DATE, '9999-12-31', true FROM stg_products s LEFT JOIN product_dim d ON s.product_id = d.product_id AND d.current_flag = true WHERE d.product_id IS NULL OR s.price <> d.price OR s.name <> d.name. This also handles brand-new products (the LEFT JOIN finds no current row).
• Why two steps, not one blind INSERT: you must close the old row before, or in the same transaction as, inserting the new one, or you will briefly have two current_flag = true rows for the same business key.

Worked example

product_dim(product_key, product_id, name, price, effective_from, effective_to, current_flag) starts with (1, 'P100', 'Widget', 9.99, '2026-01-01', '9999-12-31', true). Staging row ('P100', 'Widget', 12.99) arrives with a price change. Step 1 updates key 1 to effective_to = today-1, current_flag = false. Step 2 inserts (2, 'P100', 'Widget', 12.99, today, '9999-12-31', true). Any fact loaded before today still resolves to key 1 (old price) via the as-of join; any fact from today onward resolves to key 2.

Trade-offs and pitfalls

On engines that support a native MERGE statement, wrap the same UPDATE/INSERT logic in one MERGE for atomicity and to avoid a race between the two steps. Always compare ALL tracked attributes in the change-detection predicate; comparing only one column silently misses changes to the others. If the dimension is large, batch the detection query so it uses an index or clustering key on business_key rather than scanning the whole table on every load.

Direct answer
A good 30-60-90 plan moves someone from learning the environment, to contributing under supervision, to owning outcomes independently, with the phase boundaries defined by demonstrated behavior (what they can do unsupervised) rather than by the calendar alone. Track it with a small number of concrete, visible outputs per phase so "on track" is something you can point to, not just a feeling.

The three phases, by what changes

• Days 1-30 (learn and observe): environment setup, codebase or domain orientation, shadowing, and one small real contribution rather than a toy task, so the first change is real but low-risk.
• Days 31-60 (contribute under guidance): own a medium-sized piece of work end to end with a mentor available for review and unblocking, not doing it alongside them line by line.
• Days 61-90 (own outcomes): lead something (a project, an on-call rotation, a smaller onboarding task for the next hire) with the mentor as a backstop, not a co-pilot.

How you know they're on track

• Define the signal per phase in advance, not retroactively: for phase 1, did they reproduce the environment and ship one small real change without major help; for phase 2, is their review feedback shrinking in volume and severity over successive changes; for phase 3, can they make a reasonable decision alone and only escalate the genuinely hard calls.
• Check in on cadence (weekly early on, less frequent later) rather than waiting for day 30, 60, or 90 to find out something drifted three weeks ago.

Adjusting the plan for real constraints

• Limited training resources: when there's no dedicated ramp-up bandwidth (no spare mentor hours, no formal training material), lean harder on asynchronous artifacts: written runbooks, recorded walkthroughs, a curated list of the most representative recent changes, and a lighter-touch weekly sync instead of daily pairing. The phases stay the same; what changes is how much is self-serve versus live.
• Cross-skill ramp: if someone hired primarily for one skill set is expected to also ship in an adjacent one by day 90 (for example, a backend-focused hire expected to ship frontend work), that adjacent skill needs its own explicit milestone inside the plan, not an assumption it'll happen by osmosis. Concretely: days 1-30 stays focused on their strong area to build early confidence and trust; days 31-60 introduces the adjacent skill on a small, well-scoped, low-risk piece with close review; days 61-90 has them own something end to end in the new area, even if smaller in scope than their core-skill ownership.

Worked example
For a new hire joining an established codebase with a small team and no dedicated onboarding budget (the limited-resources case), the 30-60-90 looked like: days 1-30, self-serve environment setup using a written runbook plus a single half-day pairing session, culminating in one small, real bug fix; days 31-60, ownership of one medium feature with async review as the main touchpoint, and a short weekly 15-minute sync instead of daily check-ins; days 61-90, the new hire wrote the onboarding runbook update for the next person, which served double duty as both a real deliverable and a check on whether they actually understood the system well enough to explain it. Being on track was tracked by a short checklist per phase (environment reproducible, first fix merged with normal review effort, feature shipped with review comments trending down) rather than a single blanket "how's it going" check-in.

Trade-offs and pitfalls

• Treating the day boundaries as fixed calendar dates rather than behavioral milestones creates false confidence; someone can hit day 60 without actually being ready for phase-3 ownership, and pushing them into it anyway sets them up to fail.
• Under-supporting the adjacent-skill ramp (assuming a backend engineer will "pick up" frontend without an explicit milestone) is a common way cross-skill onboarding quietly fails; it needs the same structure as the primary skill, just smaller in scope.
• Compressing the plan under limited training resources by cutting phase 1 short (rushing into real ownership before the environment and codebase are understood) trades a faster-looking ramp for more review overhead and rework later.

A predictive churn model will enable targeted, cost-effective retention by identifying customers at high risk of leaving before they do. With a prioritized list of at-risk accounts integrated into CRM and marketing automation, we can shift from reactive to proactive interventions—personalized offers, timely outreach, and product improvements—reducing churn, preserving revenue, and improving unit economics. As a data analyst I will deliver the model, validation metrics, and a dashboard so stakeholders can operationalize interventions and measure lift.

Key assumptions:

• Sufficient historical data (≥12 months of behavior, transactions, support, marketing touches)
• Ability to run interventions (email/CS/offer) on flagged customers
• Average lifetime value (LTV) and current monthly churn baseline are known

Estimated costs & time-to-value:

• Development: 4–8 weeks (data prep, feature engineering, model training, validation) — $25k–$50k (internal effort + cloud compute)
• Integration & pilot: 2–4 weeks — $10k
• Time-to-first-payback: 3 months after pilot (first measurable retention lift)

Expected benefits / metrics (annualized):

• Churn reduction: 10–25% relative (conservative-to-optimistic)
• Revenue retained: = Current MRR * churn_reduction%
• ROI: 3–6x within 12 months (depending on intervention cost)
• Model performance target: AUC ≥ 0.75; precision@top10% ≥ 40%
• Cost per retained customer (intervention): <$50
• Payback period: 3–9 months

Primary risks:

• Data gaps or quality issues limiting model accuracy
• Inability to operationalize interventions at scale
• False positives causing unnecessary cost or customer annoyance
• Regulatory/consent constraints on outreach

I recommend funding a 12-week pilot focused on the highest-value segment to validate assumptions, measure lift, and scale rapidly if ROI targets are met.

Situation: After a mobile release, a cohort’s analytics show missing events. As the on-call data scientist, I need a reproducible, prioritized debugging & mitigation plan to find root cause and reduce further data loss.

Plan (prioritized steps):

1. Triage & scope

• Confirm affected cohort (app version, OS, device models, region, user IDs, timeframe).
• Compare event volumes vs baseline and percent drop; determine if complete loss or partial.

2. Fast mitigation

• If release likely, roll-back toggle/feature-flag for event emission or disable new SDK change.
• Enable high-priority sampling or temporary alternative event path for the cohort (e.g., batched upload to backup endpoint).

3. SDK checks (mobile)

• Check changelog/commit diff for SDK changes around event batching, buffering, flush triggers, or exception handling.
• Inspect device logs / in-app telemetry for SDK errors, exceptions, crash reports, or rate-limit responses.
• Verify SDK configuration: API keys, endpoint URLs, session handling, opt-out logic, consent flags.

4. Network path

• Check mobile network error logs: DNS failures, SSL/TLS handshake errors, HTTP 4xx/5xx, timeouts, proxy rules.
• Reproduce calls from affected devices / emulators; capture packet traces or use Charles/mitmproxy to view requests and payloads.
• Validate CDN or load balancer health and recent config changes.

5. Ingestion brokers & pipeline

• Inspect API/gateway logs for received requests and error rates. Are requests reaching edge?
• Check broker metrics (Kafka/RabbitMQ): incoming message rate, rejected messages, partition errors.
• Look for schema validation failures - malformed events might be dropped.

6. Consumer lag & downstream

• Monitor consumer group lag (Kafka offsets): if lag spikes, consumers may be slow or crashed.
• Check downstream processing errors (parsers, enrichment, storage) and DLQ/backpressure.
• Verify storage write errors (e.g., failed inserts to warehouse, rate limits, quota).

7. Telemetry & observability

• Correlate logs with APM traces, mobile SDK telemetry, and business metrics.
• Inspect alerting dashboards for anomalies aligned to release time.
• Search for feature-flag or rollout logs that map users to cohort.

8. Root cause hypothesis & test

• Form hypotheses (e.g., SDK bug causing buffered events not flushed; endpoint changed; schema rejection).
• Create tests: instrument a canary build, replay events, and simulate network conditions.

9. Recovery & data repair

• If events were buffered on devices, trigger a forced flush via SDK update/remote config or instruct clients to reopen session.
• If ingestion accepted but downstream failed, replay from broker or reprocess backups.
• If irrecoverable, estimate volume loss and backfill where possible using alternative sources (server logs, third-party SDKs).

10. Post-incident actions

• Document timeline, root cause, and action items.
• Add tests: e2e mobile-to-warehouse integration, schema validation, consumer resilience.
• Improve telemetry: SDK health metrics (flush success, queue length), network failure counters, per-version event rates, and automated alerts on cohort-level drops.

Key reasoning: prioritize quick mitigation to stop ongoing loss, gather evidence across SDK → network → ingestion → consumers, validate with reproducible tests, and plan recovery and preventive observability improvements.

Approach (how to connect)

• In Power BI Desktop use Get Data → Azure → Azure Synapse Analytics (or Azure SQL Data Warehouse connector) and select DirectQuery mode. Publish the dataset to the Power BI Service; if Synapse is in a VNet use an On-premises data gateway or Azure Private Link as required.
• In the dataset settings choose DirectQuery (not Import) so visuals send live SQL to Synapse.

Performance best practices (what to do and why)

1. Push aggregations/materialized objects to Synapse

• Create aggregated tables or materialized views in Synapse for common high-level queries (e.g., daily/weekly totals by product/region). Materialized views in a dedicated SQL pool are maintained and serve very low-latency queries; ensure refresh schedule matches SLAs.
• In Power BI use aggregation tables (model-level aggregations) that use those Synapse tables so small visuals hit aggregated data and avoid scanning raw fact tables.
  Why: reduces scanned data and network transfer; lowers query latency.

2. Prefer dedicated SQL pool vs serverless

• Dedicated SQL pool: choose when you have predictable, high-concurrency, low-latency interactive reporting. Dedicated supports distribution keys, partitioning, materialized views, result-set caching and workload management—important for heavy dashboards.
• Serverless SQL pool: best for ad-hoc analysis, exploratory queries, or cost-sensitive workloads with low concurrency. It scans files on-demand (Parquet/Delta) and lacks materialized view support—so expect higher latency for repeated interactive workloads.
  Why: trade-off between cost and interactive performance/advanced features.

3. Limit visual complexity and dataset design

• Keep each report page to a few visuals (4–6) that the user needs; avoid visuals that require scanning the full fact for every update (e.g., many high-cardinality slicers).
• Use pre-aggregated dimensions (small lookup tables) in Import mode when possible—use composite models (Import + DirectQuery) so dimensions are imported and the large fact remains DirectQuery.
• Avoid multi-field cross-filtering and complex calculated columns in the report; prefer push-down SQL via views.

4. Enable query reduction and dataset configuration

• In Power BI file settings (and Service): turn on Query reduction features (disable automatic cross-filtering between visuals, require explicit apply for slicers, sync slicers sparingly).
• Increase cache duration in Power BI if appropriate, and enable "result set" caching in Synapse/dedicated pool where available.
  Why: reduces the number of queries sent to Synapse and eliminates redundant work.

5. Synapse-specific optimizations

• Use proper distribution keys and partitioning for large fact tables; align distribution with frequent join keys to avoid data movement.
• Create statistics and keep them updated; use clustered columnstore indexes for compressing large fact tables.
• Use resource classes/workload management to reserve concurrency for interactive workloads.
• Use query profiling (Query Store/DMVs) to find slow queries and rewrite them, add indexes, or create targeted materialized views.

Operational tips and edge-cases

• Monitor query patterns (Power BI Performance Analyzer + Synapse Query Store) to identify heavy visuals.
• For very low-latency SLAs, pre-aggregate nightly and serve via Import or materialized views.
• If users need real-time row-level changes, accept higher DirectQuery costs or use hybrid: imported dimension + DirectQuery fact with targeted aggregations.

Short example flow

1. Build nightly aggregated tables in Synapse: sales_by_day_product_region (materialized view in dedicated pool).
2. In Power BI import small dimension tables, use DirectQuery for the fact and map Power BI aggregation tables to the Synapse aggregated tables.
3. Enable query reduction (Require apply on slicers), limit visuals per page, and monitor queries. Move to dedicated pool if concurrency/latency require it.

This combination keeps interactive UX responsive while minimizing data scans and cost.

High-level approach: I’d keep the same structured 0–30 / 30–60 / 60–100 cadence but adapt pace, risk tolerance, and stakeholder patterns based on regulatory burden and growth tempo.

A) Highly regulated financial institution
0–30: Discovery focused on governance — meet compliance, data governance, risk, and core business partners. Map data lineage, sensitive fields (PII, PCI), and existing ETL/API owners. Request formal data access: security training, NDAs, role-based access requests; expect multi-week approvals.
30–60: Small, compliant quick wins: read-only sandbox queries against anonymized or aggregated datasets; build one executive-ready dashboard that uses approved metrics (e.g., loan performance). Simultaneously design robust pipelines with logging, lineage, and audit trails.
60–100: Deliver hardened reporting and automation with documented validation tests and sign-offs from compliance. Establish recurring review cadence with stewards and a change-control process.

Prioritization: favor foundational correctness, reproducibility, and auditability over speed. Quick wins must be low-risk and approved.

Stakeholders: heavy involvement from legal/compliance and data stewards; use formal communication (RFCs, scheduled governance reviews).

B) Fast-growth consumer startup
0–30: Rapid discovery: meet PMs, growth, product, ops to learn KPIs and data sources. Lightweight data map; request pragmatic access (analytics DB, event streams). Approvals often informal — get access via owner emails and short onboarding.
30–60: Deliver high-impact quick wins: ad-hoc cohort analyses, retention funnels, and a conversion dashboard using existing event data. Iterate quickly with stakeholders.
60–100: Build more scalable pipelines and standardize definitions (metrics glossary), automate regular reports, and introduce monitoring. Start introducing better governance but tuned to speed.

Prioritization: favor fast, measurable impact (experiments, growth signals) while incrementally hardening foundations.

Stakeholders: frequent, informal syncs, demos, and embed with product/growth teams; use async updates and rapid feedback loops.

Key tradeoffs: regulated environment -> slower but safer; startup -> fast but requires later technical debt cleanup. I’d explicitly surface these tradeoffs with timelines and risk mitigations in week-1 stakeholder alignment.

1. First Response Time (median & P95)

• Decision: Reallocate agents across channels or extend shift coverage if first-touch lagging.
• Trigger: Median > 30 min or P95 > 4 hours for high-priority tickets → alert to staffing lead.

2. Time to Resolution (median & P95)

• Decision: Change SLAs, escalate to specialist teams, or add knowledge-base articles.
• Trigger: Median > SLA (e.g., 24 hrs for standard) or P95 > 72 hrs → investigate root cause.

3. SLA Compliance Rate (by priority)

• Decision: Adjust SLA targets, hire/shift resources, or reprioritize ticket routing.
• Trigger: SLA compliance < 95% for P1 or < 90% for P2 over rolling 7 days.

4. Tickets by Channel & Channel Load %

• Decision: Reallocate agents across email/chat/phone; prioritize channel-specific hiring/training.
• Trigger: One channel > 60% of total load and service levels dropping.

5. Backlog (tickets older than threshold) and Aging Distribution

• Decision: Triage backlog for bug vs process issues; create backlog burn-down plans.
• Trigger: Tickets > SLA-age increasing week-over-week by >20%; alert when >5% are >30 days.

6. Reopen Rate / Escalation Rate

• Decision: Improve quality training, update KB, or escalate product defects to engineering.
• Trigger: Reopen rate > 5% or escalation rate > 3% (product bugs) → product triage meeting.

7. Customer Satisfaction (CSAT) & NPS by issue type

• Decision: Targeted coaching, product improvements, or policy changes.
• Trigger: CSAT rolling 7-day avg < 80% for a category or NPS drop > 10 pts month-over-month.

8. Volume of Repeat Issues / Tags indicating potential product bug

• Decision: Initiate bug triage, create hotfix backlog, or update documentation.
• Trigger: Same-issue volume > 1% of weekly tickets or rapid spike (e.g., 3x baseline) → urgent bug review.

For each metric include trend, segment (priority, product, agent), and SLA baseline in the dashboard to enable drill-down diagnostics and automate alerts when thresholds breached.

How I would investigate
I would compare the query profile, not just the SQL text. A CTE, or common table expression, is a named subquery. On some warehouses it is inlined, and on others it may be materialized or repeatedly scanned. I would look for repeated reads of the same large table, lost predicate pushdown, and big intermediate results.

First checks

• Run EXPLAIN or the warehouse query profile.
• See whether the same base table is scanned more than once.
• Check whether filters are applied after large joins instead of before them.
• Compare row counts at each step to find the explosion point.

What I would change first
If a suspicious CTE is referenced once, I would inline it or fold it into the parent query. If it is reused multiple times, I would stage the filtered result in a temp table or a materialized table so the expensive work happens once.

Rule of thumb
Readability is good, but if separate CTEs each reread a billion-row fact table, the query gets slower. The fix is usually to push filters earlier, keep only needed columns, and avoid recomputing the same join or aggregation in multiple branches.

Direct answer: Don't narrate the whole path. Select one project per career stage, junior, mid, senior, that shows impact increasing, then make the comparison explicit by putting your first role and your current one side by side on decision-making authority and technical depth, so the interviewer sees the delta (the size of the difference between then and now) rather than inferring it.

Structured elaboration

The direct before/after comparison

Open or close with an explicit comparison of your very first role in the field against your current one, on two axes: decision-making authority (what you could decide alone versus what needed sign-off) and technical depth (the complexity of problems you were trusted with). Stating the comparison directly does the interviewer's synthesis work for them; a chronology forces them to infer the delta themselves.

One project per stage, chosen for increasing impact

Rather than listing every project at every stage, select one project per career stage (junior, mid, senior, or whatever stages you actually have) and use each to show impact increasing: a step up in scope, ambiguity, or outcome. Three well-chosen examples that clearly escalate beat six examples that don't visibly build on each other.

Anchor one transition on a specific promotion

Narrate a specific promotion concretely: what changed at the moment of the promotion or scope increase, and the outcomes in the first six to twelve months that validated it. This is what separates "I was promoted" from evidence that the promotion was earned.

A lesson learned at each transition

At each stage change, name one concrete lesson learned, something about how you make decisions, what you delegate, or how you think about risk, that you carried forward. This shows the progression changed how you think, not just your title.

Worked example

Skeleton: "Early on, in [junior-stage project], I [what you did], and [a specific type of decision, e.g. any change to a shared system] needed sign-off from someone else. [Lesson from that stage]. At the mid-level stage, in [mid-stage project], I [what you did with more scope], which taught me [lesson]. The clearest transition was [specific promotion or scope increase]: in the six to twelve months after, I [what you delivered that validated it]. Today, in [senior-stage project], I [decisions you now make without sign-off, the technical depth you're trusted with]. Comparing that first role to now directly: back then [what you couldn't decide alone, or the limited technical scope]; today [what you decide alone, or the depth you're trusted with]."

Filled illustration: "Early on, as a junior data engineer, I built and maintained individual ETL pipelines, and any change to the data model needed a senior engineer's sign-off. That stage taught me to over-document my reasoning, since I couldn't yet assume people would trust my judgment without it. At the mid-level stage, I owned the pipeline architecture for one product area end to end, which taught me to think about failure modes before they happened rather than fixing them after. The clearest transition was being promoted to lead the data platform team: in the following year, I redesigned how the team handled schema changes across the org, and the fact that other teams adopted it without me pushing it validated that the promotion reflected real trust, not just a title change. Today, I make architecture decisions for the platform without needing sign-off, and I'm trusted with problems that don't have an established playbook yet. Comparing that first role to now directly: back then I needed approval to change a single data model; today I set the standard other teams' models follow."

Trade-offs & pitfalls

• Listing every project at every stage instead of one representative example per stage buries the escalation the interviewer is trying to see.
• Describing a promotion without describing what you did in the months after to validate it leaves the interviewer to take the title change on faith.
• Skipping the direct first-role-versus-now comparison and hoping the interviewer infers the growth from a set of anecdotes is a missed opportunity; state the delta plainly.
• A story with events but no stated lesson at each transition reads as things that happened to you rather than growth you actively drove.

Direct answer

When legal or compliance flags a possible regulatory problem on something about to ship, that flag is new information, not an attack on the project. The first move is to separate the specific risk from the whole feature: find out exactly what triggers the concern, then look for a way to ship everything outside that blast radius (the specific data, users, or markets the flagged concern actually touches) while the risky piece gets handled properly. Treating the flag as either a full block to fight or a formality to route around are both weak answers; the senior move is to make the freeze as small as the actual risk.

Structured elaboration

1. Turn the flag into a scoped, written finding

Ask for the specific clause or regulation, the specific data flow or behavior it applies to, and which markets or user segments are affected. A flag that sounds like 'this violates a regulation' often narrows down to 'this one data field, in these two markets.' Until that scoping happens, nobody can reason about mitigation, they can only argue about the abstract freeze.

2. Sort what's actually blocked from what's just slow

Once scoped, most flags fall into three buckets: genuinely unsafe to ship anywhere (rare, but real, treat it as a hard stop); unsafe in specific markets or for specific data (the common case, often scoped out with a flag or market-level rule); or unsafe as currently designed but fixable with a smaller change than a full freeze (needs a scoped rework, not a blanket delay).

3. Bring a mitigation, not just a constraint

Offer a concrete option: disable the flagged behavior for the affected markets, gate it behind a feature flag (a toggle that turns a piece of functionality on or off without a new deployment), or ship a version that omits the specific data flow while the rest proceeds. This turns the conversation from 'can we go or not' into 'does this mitigation satisfy the concern,' which moves much faster.

4. Get joint, written sign-off before proceeding

Both the business owner and compliance need to agree in writing on what shipped, what did not, the remaining risk, and who owns closing it. This protects everyone if the interpretation is questioned later and prevents the same argument from recurring next release.

5. If a real freeze can't be avoided, negotiate the timeline explicitly

Sometimes there is no safe scoped path and the freeze has to hold for the affected piece. Here the negotiation shifts to: what's the minimum change needed to clear the concern, who is assigned to it, and can the review be fast-tracked with a dedicated reviewer instead of sitting in a general queue. A freeze with a committed, shrinking timeline is a very different conversation from an open-ended one.

Worked example

A team is about to ship a feature that logs a new field for product analytics, and legal flags that collecting that field may violate a data-protection rule in one region. Scoping the flag shows the issue is narrow: one field, one region. Instead of freezing the whole release, the team ships everywhere else immediately, and for the flagged region ships the same feature with that one field's collection disabled behind a config switch. Legal signs off on the scoped version in writing. The team opens a follow-up item, with an owner and a target date, to redesign how that field is collected (for example, aggregating it instead of storing it per user), so the region isn't stuck without the feature indefinitely.

Trade-offs and pitfalls

• Treating every compliance flag as either a full block or a nuisance to route around is the most common mistake here; both extremes erode trust with the compliance function over time.
• Scoped mitigations (flags, market gating, field exclusions) are good short-term tools but can quietly become permanent if nobody owns the follow-up fix. The sign-off should name an owner and a date, not just describe a workaround.
• Escalating past compliance to force a ship date, without addressing the underlying concern, tends to resurface later as a bigger problem: a real violation or a regulator inquiry. Speed gained by skipping the process rarely survives contact with the risk it was protecting against.
• The strongest signal of seniority isn't how fast the team got to yes, it's whether the final decision is something both sides would still defend the same way months later.