# Content Published in 2026 > Published back then. Still relevant? Canonical URL: Domain: SQL · Difficulty: easy · Seniority: L3 ## Problem The content team is auditing everything that went out the door in 2026 to decide what still deserves a spot on the homepage. Pull the full record of every piece whose publish date lands anywhere in that calendar year. ## Worked solution and explanation ### What this is really testing Stripped of the content-team costume, this is a single-year date filter: keep the rows whose publish_date sits inside one calendar year, return them untouched. The whole table is one flat list, no grouping, no joins, no aggregation. Easy as it looks, this is the exact shape interviewers use as a warm-up to watch whether you reach for a clean range bound or fumble the year boundary. > **Trick to solving** > > Anchor the year with two literal dates, 2026-01-01 and 2026-12-31, and let a single range test do the work. You do not need to slice the year out of the column or compare year numbers; bounding the date directly is both the simplest and the fastest read of the data. #### Step 1: Keep every column The ask is the full record of each matching piece, so SELECT * is correct here. There is no projection to do and no derived column to add. Returning the whole row is what the expected output shows, columns and order intact. #### Step 2: Bound the year with a range publish_date BETWEEN '2026-01-01' AND '2026-12-31' captures the first day through the last day of the year, both ends inclusive. That inclusivity is exactly what you want: a piece published on January 1 or December 31 still belongs to the year. **Single-year filter** ```sql SELECT * FROM content_items WHERE publish_date BETWEEN '2026-01-01' AND '2026-12-31' ``` *One range predicate over publish_date, no extra machinery.* > **Common pitfall** > > The boundary bites when publish_date is a timestamp rather than a pure date. BETWEEN is inclusive, but '2026-12-31' implies midnight, so a row stamped 2026-12-31 14:30 falls AFTER the upper bound and silently disappears. On a true DATE column you are safe; the moment time-of-day enters, prefer a half-open range: publish_date >= '2026-01-01' AND publish_date < '2027-01-01'. **Inclusive BETWEEN (DATE column)** publish_date BETWEEN '2026-01-01' AND '2026-12-31'. Clean and correct when the column is a plain date with no time component. **Half-open range (TIMESTAMP-safe)** publish_date >= '2026-01-01' AND publish_date < '2027-01-01'. Catches every instant of Dec 31 and never needs you to reason about leap years or the last second of the year. > **Interviewers watch for** > > The tell of seniority on a trivial filter is whether you mention the timestamp boundary unprompted. Reaching for the half-open range, or at least flagging that BETWEEN assumes a date type, signals you have been burned by the Dec 31 drop in production and design around it. > **Performance insight** > > A contiguous range on a single column is the friendliest possible predicate for an index. With a btree index on publish_date the planner does one range scan over the matching slice instead of reading the whole table. Wrapping the column in a function like YEAR(publish_date) = 2026 would defeat that index and force a full scan, which is the slower and worse-looking choice even though it returns the same rows. ## Common follow-up questions - How would you rewrite this so it stays correct if publish_date becomes a timestamp with time-of-day? _(Tests whether they reach for the half-open range and understand the inclusive upper-bound trap.)_ - Suppose you needed the same audit for the last three years, one row per year with a count of pieces. How does the query change? _(Pushes from a flat filter toward grouping by the year extracted from the date.)_ ## Related - [All practice problems](https://datadriven.io/problems) - [Mock interview mode](https://datadriven.io/interview/content_published_in_year) - [SQL Interview Questions](https://datadriven.io/sql-interview-questions) - [Data Engineering Interview Prep Guide](https://datadriven.io/data-engineer-interview-prep) - [Daily Challenge](https://datadriven.io/daily) --- Source: DataDriven (https://datadriven.io). DataDriven is the data engineering interview community. Live code execution in SQL, Python, and Spark sandboxes. Every feature is open to every member.