Skip to content

[JRODRIGUEZ] complete dscout interview aide coding round - #1

Open
JacobBRodriguez wants to merge 1 commit into
dscout:mainfrom
JacobBRodriguez:jrodriguez/coding-round-dscout
Open

[JRODRIGUEZ] complete dscout interview aide coding round#1
JacobBRodriguez wants to merge 1 commit into
dscout:mainfrom
JacobBRodriguez:jrodriguez/coding-round-dscout

Conversation

@JacobBRodriguez

Copy link
Copy Markdown

Coding interview round completed for DScout.

Comment thread ai_data_eng_tech_round.py
Comment on lines +132 to +133
if event_id is not None and event_id in seen_event_ids:
reasons.append("duplicate event_id")

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unhashable IDs abort event batches

event_id values like lists or dicts reach event_id in seen_event_ids, so Python raises TypeError and process_events aborts instead of adding the row to rejected_events — should we validate that event_id is a hashable scalar up front and append an event_id rejection reason first?

Severity

Prompt for AI Agents
Before applying, verify this suggestion against the current code. In
ai_data_eng_tech_round.py around lines 130-163 inside `process_events()`, the
deduplication block does `if event_id is not None and event_id in seen_event_ids:`
without ensuring `event_id` is hashable, so unhashable IDs crash with a TypeError
instead of producing a `rejected_events` entry. Refactor the logic to validate
hashability immediately after `event_id = event.get("event_id")` (e.g., attempt
`hash(event_id)` in a try/except); if it’s unhashable, append a rejection reason like
"unhashable event_id" and do not perform the set membership check or add to
`seen_event_ids`. Only add to `seen_event_ids` after the hashability check succeeds,
keeping the rest of the required-field and timestamp/duration validations unchanged.

Comment thread ai_data_eng_tech_round.py
Comment on lines +136 to +138
for field in REQUIRED_FIELDS:
if event.get(field) is None:
reasons.append(f"missing {field}")

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Blank identifiers enter valid events

Empty required identifiers like event_id: "", participant_id: "", mission_id: "", and study_id: "" pass this check because only None is rejected, so invalid records reach valid_events and can be persisted with unusable IDs — should we reject blank strings explicitly, e.g. with isinstance(value, str) and not value.strip() for these fields?

Severity

Prompt for AI Agents
Before applying, verify this suggestion against the current code. In
ai_data_eng_tech_round.py around lines 136-138 inside `process_events()`, the
required-fields loop only treats `None` as missing (`if event.get(field) is None`), so
blank/whitespace strings like `event_id: ""` incorrectly pass and can be added to
`valid_events`. Refactor this check to also reject values that are strings which are
empty or only whitespace (e.g., `isinstance(value, str) and not value.strip()`), and
append an appropriate rejection reason (e.g., `missing {field}` or `blank {field}`) when
they occur. Update or extend the existing `run_unit_tests()` cases to cover at least one
blank required field to ensure these records are rejected, not persisted as valid.

Comment thread ai_data_eng_tech_round.py
Comment on lines +149 to +150
try:
datetime.fromisoformat(ts.replace("Z", "+00:00"))

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Date-only timestamps enter analytics

datetime.fromisoformat() accepts date-only strings as midnight, so this exception-only check lets valid_events copy a date-only timestamp unchanged into mission_events and the Snowflake-ready output, even though Part 1 expects an ISO 8601 datetime — should we require an explicit time component before accepting the record?

Severity web_search

Prompt for AI Agents
Before applying, verify this suggestion against the current code. In
ai_data_eng_tech_round.py around lines 149-152 inside the process_events() timestamp
validation block, fix the bug where datetime.fromisoformat(ts) accepts date-only strings
like "2024-01-15" and turns them into midnight, allowing non-datetime values to flow
into valid_events. Refactor the logic to explicitly require an ISO 8601 datetime format
by checking the raw ts string contains a time component (for example, require a 'T'
separator and a ':' in the time part) and only then attempting fromisoformat
normalization for the trailing 'Z'. Update run_unit_tests() around the process_events
unit tests to add a case with a date-only timestamp and assert it appears as "invalid
timestamp" in rejection_reason.

Comment thread ai_data_eng_tech_round.py
Comment on lines +285 to +290
print("\n── Unit tests: process_events() ──")
try:
run_unit_tests()
print(" ✓ All process_events() unit tests passed!")
except AssertionError as _e:
print(f" ✗ Unit test failed: {_e}")

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unit-test failures are silently ignored

run_unit_tests() catches AssertionError and only prints a message, so the process still exits 0 and regressions in process_events() can slip through CI — should we let the error propagate, or re-raise it after printing?

Severity

Prompt for AI Agents
Before applying, verify this suggestion against the current code. In
ai_data_eng_tech_round.py around lines 285-290, the bottom-of-file unit test harness
wraps run_unit_tests() in a try/except AssertionError that only prints an error and then
allows execution to continue. Change this so test failures fail the run: either remove
the except block entirely or, if you want to keep the custom message, re-raise the
caught AssertionError (after printing) so the process exits non-zero. Ensure the
caller/CI observes the failure from process_events() regressions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant