A housing-authority waitlist team finds that applicant_id is int64 in one extract and string in another, so cuDF and pandas joins fail. What should they do first?
Select an answer to reveal the explanation.
Short Explanation
If one spreadsheet stores badge numbers as text and another as numbers, the join key never lines up—even when the people match. Rename columns so both sides agree, cast to one dtype, then join. Guessing on last names or inventing new IDs just makes the waitlist mess worse.
Full Explanation
Successful joins in pandas and cuDF require compatible join keys: shared column identity and compatible dtypes. When applicant_id is int64 in one housing-authority extract and string in another, the correct first step is to rename keys for consistency and cast applicant_id to one shared dtype before merging. That restores deterministic key equality so waitlist enrichment and eligibility joins actually match the same people across systems.
Ignoring the dtype mismatch and joining on last name only substitutes a weak, collision-prone attribute for a designed identifier and will falsely merge or miss applicants. Deleting all rows where ID formats differ destroys records because of a representation problem rather than a true absence of applicants—an audit and fairness failure for waitlist analytics. Replacing both ID columns with randomly generated UUIDs each run breaks historical linkage and makes the join non-reproducible across nightly loads.
Exam caveat: casting strings like "00123" to integers can drop leading zeros that are part of an agency’s external ID format; sometimes the shared dtype should be a normalized string, not int64. Operational check: profile both key columns, choose an explicit canonical dtype, cast both sides, verify overlap counts before versus after casting on a sample, then join and reconcile against a known matched applicant list.