Member-only story
Do Data Engineering Candidates Really Know Anything?
A framework for honestly evaluating programming skills, technical proficiency and conceptual knowledge.
Currently job searching? Give yourself an edge by developing a personal project using my free 5-page project ideation guide.
Once, after helping a client with a resume, I received an angry phone call. After receiving help they applied for a job. And, thanks to the changes we made together, scored an interview. But there was a problem. The interviewer asked whether the applicant knew an obscure Adobe program.
Admittedly, the client gave the perfect response: “I don’t know it but I’m a fast learner and, if given the opportunity, I’d be happy to learn prior to my start date.” There was (what I imagine to be) an uncomfortable pause.
The interviewer responded: “Oh… if you don’t know it, why is it on your resume?”
This is the worst nightmare for someone working in a highly technical field like data science, where seemingly everyone needs to know everything at every skill level. Such a discrepancy between what a hiring manager is looking for and what you’re actually comfortable admitting can lead to uncomfortable situations from deflecting interview questions to bombing white board sessions.
Which begs the question: How do you actually know when you really know a programming language, orchestration tool or data modeling technique?
The first step to answer this is getting rid of antiquated ways of talking about technical skills. Typically, when one describes their technical abilities they bucket their experience into one of three categories:
- Novice
- Proficiency
- Mastery
This is unhelpful because the delta between proficiency and mastery is massive and the difference between someone who is a novice and someone who is proficient is, at best, undefined.
Therefore, I’d like to propose a new skill gap framework that focuses more on the “how” of your abilities and ignores meaningless metrics like certifications.
