BIDA common mistakes
BIDA · Understand the traps and how to avoid them.
In SQL or pandas tasks, the candidate groups and aggregates rows before joining to a lookup table, so the join key gets multiplied and the totals inflate, and they ship the number without checking row counts before and after the join.
Aggregation and joining feel like two independent steps, so candidates treat the join as a harmless enrichment and never compare the pre-join and post-join row counts or distinct-key counts.
What to do instead
Before every join, record the row count and the distinct count of the join key on both sides. After the join, re-check both. If the post-join row count exceeds the pre-join count, the join is one-to-many and must be fixed with a pre-aggregated subquery or a deduplicated lookup table before any downstream aggregation.
When writing a transformation pipeline, the candidate hardcodes dates, file paths, or column positions (for example, reading column index 3 or filtering on a literal '2024-01-01') instead of parameterizing them, so the pipeline silently produces wrong output when the source changes.
Hardcoding is the fastest way to get the task working on the sample data provided, and the candidate never tests the pipeline against a second input where the assumption breaks.
What to do instead
Externalize all environment-specific values into parameters or config (run date, input path, column names). Reference columns by name, never by position. Before finishing, mentally rerun the pipeline with a different date and a reordered column set; if it breaks, parameterize the offending value.
The candidate builds a dashboard chart with a truncated y-axis or a dual axis that makes a modest difference look dramatic, and does not label units, aggregation level, or the time window on the chart.
Default chart settings in most tools auto-scale to the data range, and candidates focus on making the chart look clean rather than on whether the visual encoding misrepresents the magnitude of the change.
What to do instead
For bar charts, always start the axis at zero. For line charts, state the axis range explicitly. Add a title that names the metric, the aggregation, and the period. If using a dual axis, label both axes and justify why two scales are needed; otherwise split into two aligned panels.
The candidate chooses a chart type that does not match the question, such as a pie chart with twelve slices, a line chart for unordered categories, or a stacked bar when the reader needs to compare individual segments.
Candidates pick the chart they can build fastest in the tool rather than reasoning from the analytical question (comparison, trend, distribution, part-to-whole, correlation) to the encoding.
What to do instead
State the question first, then map it: trend over time means line; comparison across categories means sorted bar; distribution means histogram or box plot; part-to-whole with few parts means stacked bar or pie with at most about five slices; correlation means scatter. Sort categorical axes by value unless there is a natural order.
In data modeling, the candidate stores the same attribute (for example, customer address or product category) in several tables and updates it in only one place, so reports disagree depending on which table they read.
Denormalizing for convenience feels efficient during development, and the candidate does not trace each attribute to a single system of record or define which table is authoritative.
What to do instead
Assign each attribute exactly one owning table, usually a dimension or a master entity table, and have other tables reference it by key rather than copying the value. Document the ownership in the model. When a duplicate is unavoidable for performance, define the refresh path that keeps it synchronized and note it explicitly.
The candidate designs a schema at one grain without declaring it, mixing transaction-level rows with summary rows in the same fact table, which produces double counting when the table is summed.
Candidates add rows for convenience (a monthly total appended to a daily table) without recognizing that a fact table must have a single, uniform grain that every measure conforms to.
What to do instead
Write the grain of every fact table in one sentence ('one row per order line per day') and enforce it. Put aggregates in a separate summary table or compute them at query time. Before publishing, test that summing the fact table at the declared grain matches the source system's control total.
In coding tasks, the candidate writes a solution that works on the happy path but does not handle nulls, empty inputs, duplicate keys, or type mismatches, and does not test those cases before submitting.
Candidates test with the one sample dataset given and stop as soon as the output looks right, treating edge cases as out of scope rather than part of correctness.
What to do instead
Before submitting, run the code against at least four adversarial inputs: empty input, all-null column, duplicate keys, and a type that differs from the sample (for example, numeric stored as string). Add explicit handling or an assertion for each, and state the assumed contract in a comment.
The candidate writes code that mutates the input data in place or relies on global state and execution order, so rerunning a cell or calling a function twice gives a different result.
Interactive notebooks encourage running cells out of order, and in-place operations (dropping columns, sorting, appending) feel efficient and are rarely flagged as a hazard.
What to do instead
Make functions pure: copy inputs before transforming, return new objects rather than mutating arguments, and avoid module-level mutable state. At the end of a notebook, restart the kernel and run all cells top to bottom to confirm the output is reproducible from a clean state.
The candidate interprets a p-value as the probability that the null hypothesis is true, or reports statistical significance as practical significance without stating an effect size and confidence interval.
The p-value's definition is subtle and easy to misstate under time pressure, and candidates default to 'significant or not' because that is the phrasing they have seen most often.
What to do instead
State the correct interpretation explicitly: the p-value is the probability of data at least this extreme if the null were true. Always report the effect size with a confidence interval alongside the p-value, and describe the decision in terms of both statistical and practical significance given the business context.
The candidate runs many comparisons or subgroup tests and reports the ones that came out significant, without adjusting for multiple testing or pre-registering the hypotheses.
Exploratory slicing is fast and the significant result is rewarding, so candidates stop searching once they find one and do not account for the inflated false-positive rate across many tests.
What to do instead
Separate confirmatory from exploratory analysis. For confirmatory tests, pre-specify the hypotheses and the alpha. For multiple comparisons, apply a correction such as Bonferroni or Benjamini-Hochberg and report the adjusted values. Label any post hoc finding as exploratory and require independent replication before acting on it.