Take-Home Assignment Simulator: One Dataset, 15 Graded Steps

Explanation: Confirming dimensions first catches a truncated download or an extra header row before either poisons your analysis. nrow() and ncol() read the frame's shape directly, and wrapping them in a named vector documents what each number means. Reviewers notice when you state the size of what you were given rather than assuming it, because a wrong row count is the quietest way an analysis goes wrong.

Explanation: sapply() walks each column and returns its class in a named vector, which is the fastest way to audit an import. Here order_date and units arrived as "character", so date arithmetic and any multiplication would fail or silently coerce. This is the single most common take-home data issue, and flagging it early tells the reviewer you will not blindly trust read.csv() output.

Explanation: is.na() returns a logical vector, and sum() counts the TRUE values because logicals coerce to 1 and 0, so sum(is.na(x)) is the idiomatic missing-count. Only units is affected, with two gaps. Knowing the count before you act prevents overreacting: two missing rows out of thirty is an imputation decision, whereas twenty would be a data-quality escalation to the client.

Explanation: as.Date() parses the ISO YYYY-MM-DD strings into a real Date so you can subtract dates and extract months, while as.integer() turns "19" into 19 and quietly leaves the missing values as NA. Type-fixing before analysis is non-negotiable: a date left as text sorts alphabetically and a count left as text cannot be multiplied, so both would derail the revenue work that follows.

Explanation: Logical row-subsetting keeps only the rows where the condition is TRUE, and naming the columns trims the output to what the client needs to correct. One order, ORD-023, carries a negative price, which is a sign-entry error rather than a real value. The judgment reviewers reward is that you surface and document the anomaly instead of silently deleting it, since the client owns the fix.

Explanation: Taking the absolute value assumes the price magnitude was right and only its sign was mistyped, a defensible fix you would still note to the client. Median imputation fills the two gaps with a robust center that is unmoved by extreme orders, and wrapping it in as.integer() keeps the column a whole-number count. Ending with a verification that both problem counts are zero documents that the cleaning worked, which is exactly the rigor a reviewer looks for.

Explanation: Multiplying two columns is vectorised, so units * unit_price produces the per-order revenue in one pass without a loop. The total near 19,279 and the mean near 643 are the first headline numbers a reviewer sanity-checks, and computing them on the cleaned data is what makes them trustworthy. Had you skipped the imputation, the two missing units would have made those orders NA and quietly understated the total.

Explanation: format(date, "%Y-%m") reduces each date to a sortable month key, and group_by() plus summarise() totals revenue inside each key. April stands out as a sharp dip, the kind of pattern a stakeholder will ask about. Note that the tibble prints large values abbreviated, so 2669. is 2669.34 shown to four significant figures; the underlying number is exact and only the display is shortened.

Explanation: filter() keeps only the North rows, and summarise() collapses them to a single row where n() counts orders and sum() totals revenue. Because the input is a plain data frame with no groups, the result prints in base style rather than as a tibble, which is a harmless display difference. Scoping a report to one segment on request is a routine stakeholder task, and doing it in two clear verbs keeps the logic auditable.

Explanation: left_join() attaches the matching unit_cost to every order by category and keeps all order rows, so nothing is dropped even if a category were absent from the cost table. Profit subtracts the cost of goods from revenue, and grouping then ranking surfaces that Gizmos lead despite Widgets being the most common category, because their low unit cost widens the margin. A left join is the safe default here precisely because it never silently discards unmatched sales.

Explanation: Grouping by region and summing gives one revenue total per region, and arrange(desc()) puts the leader on top so the deck reads at a glance. East edges out West by a slim margin, a gap small enough that you would caution the stakeholder against over-reading it on only thirty orders. Grouped-summarise-then-arrange is the workhorse pattern behind almost every ranked report you will produce.

Explanation: Sorting descending and taking the first three rows is the standard top-N idiom, and select() trims the columns to what the sales lead cares about. The biggest order, ORD-014, cleared 1,600 in revenue. On a small sample these leaders can be noisy, so a careful analyst reports them as the largest observed orders rather than as a durable pattern, and would revisit the ranking as more data arrives.

Explanation: Because the "%Y-%m" labels sort the same way as real dates, a plain string comparison against "2023-03" cleanly splits the year into halves without any date arithmetic. Revenue fell about 44 percent from the first half to the second, which is the kind of period delta a stakeholder acts on immediately. Reporting the direction and the size of the change together, rather than two raw totals, is what turns a number into a decision.

Explanation: The slope of about 33.7 means each additional unit sold adds roughly 33.7 in revenue on average, which is close to the mean unit price and therefore a sensible sanity check. Its tiny p-value confirms units strongly predict revenue, while the intercept is not significant and has no real meaning at zero units. Reading a coefficient table, not just fitting the model, is what a take-home reviewer actually grades.

Explanation: A single headline row communicates the result faster than any chart: thirty clean orders, about 19,279 in revenue, roughly 15,053 in profit, and East as the leading region. Each figure traces back to an earlier step, so assembling them is really a check that your pipeline is internally consistent. Ending a take-home with a crisp, self-consistent summary is what separates a strong submission from a raw dump of intermediate tables.