Member-only story
What Hiring Managers Secretly Look for in Data Engineers
These 3 traits will actually get you hired

The market for data engineers has been pretty intense for a while. Standing out against your peers can be difficult, especially when the competition is so fierce.
However, there are some traits that I’m always looking for when hiring data engineers and I think they’ll surprise you.
Now, you still need to ensure you reach the interview stage. This involves doing the basics right such as honing your CV and brushing up on technical skills (and LeetCode depending on the role).
Let’s now look at the traits that will increase your success rate on top of sound technical proficiency.
Trait #1 — Be proactive
One of the first things I want to discover about the person I’m interviewing is their proactive nature. I’m looking for historical proof of taking their own initiative to make things happen and solve problems.
As a leader of a data team, my time is stretched. I’m responsible for technical deliveries, data architecture, project consultancy, and running my own team.
If I hire someone who needs everything spoon-feeding to them, my productivity drops and so does my team’s. This is why I’m looking for proactive people. If you’ve been given a task and hit a blocker, you should look for alternatives, watch some videos, or ask your favorite LLM.
Now this doesn’t mean my team can’t come to me. They come to me all of the time. But when they do they’re usually asking for one of two things: sign off on a decision, guidance on which solution to choose from a few they’ve come up with.
They’re not looking to be given the answer, they’re looking for my experienced opinion on which path to take.
Trait #2 — Own your fuck ups
We all make mistakes. We make most of our mistakes in our earlier years but they never stop. We’re fallible humans and this will always happen.
Mistakes are often a lot easier to rectify when they’re reported early. In most well-run organizations, almost all of them can be undone — and if they can’t the fault is often not on…