Inside the Data Interview: Tim Frazer (Director of Data & Analytics at Trust & Will)

"Everything in my process comes back to one belief: fundamentals are getting more valuable, not less."

Who is Tim Frazer?

Today I serve as a Director of Data Engineering & Analytics at trustandwill.com a series C startup in the USA. We I am responsible for sending out thousands of reports for direct to consumer, and business to business reporting, data governance, security, data platform, BI, AI where it makes sense, and all the stuff that entails for a 100+ person startup in a legal tech field.

I hold no degrees as I was homeschooled growing up, so I backed into data through an business analyst job at a grocery store after stocking selves for years, taught myself SQL because a problem in front of me needed it, then Python, then everything after. More than ten years on, I’ve built data teams from zero to teams of teams, stood up data lakes and lakehouses from scratch, ran data at a behaviour-change startup in NYC, did freelance the consulting stint full time, and interviewed and mentored across hundreds of candidates for engineering, analytics, and data product roles.

Outside of my day job, I write and podcast at Selftaught.engineer . There, I interview people who built their careers despite being told they needed a “degree,” just like I did but typically have unusual paths. This slant influences my hiring process. I don’t look for credentials; I look for people who can solve the problem at hand, time and time again.

I also do a lot of mentoring for early career developers. I help them build personal projects that highlight their actual skills. I want them to show off what they can build rather than listing their grades on a resume. This approach helps talented people stand out even when their background does not look traditional. My goal is to lower the barriers for anyone with a real passion for technology and volunteer and help organize a Data Meetup in Philadelphia https://dataphilly.com/

I also write and run a science parenting podcast with my wife where we talk parenting podcast with my wife

I own/run littlebigthings.co where my wife and I invest in seed level (small cheques like $1-$10k investments into business), or provide advisor roles to companies that don’t have heads of data, or skillsets that we have access to, and we like everyone else with AI develop software to scratch our itches.

What data team structures do you generally work with? When do they shine?

I’ve run and coached most of the shapes: the solo data person, the small centralized team, the embedded/hybrid model at scale.

Solo and small centralized teams are where I’ve spent most of my career, and they shine early when the company needs one coherent foundation, shared patterns, and someone accountable for “is the data actually right?” A few months ago I was solo and the first data engineer in the startup; now we’re a team, and the thing that made it work wasn’t the org chart, it was shared patterns from day one write-audit-publish, testing, alerting and learning how to do data product intake so the team isn’t just a help desk.

Embedded or hybrid models when the bottleneck stops being infrastructure and starts being context. An analyst sitting inside marketing will always understand attribution pain better than one sitting in a central queue.

But honestly, when someone asks me where their data team should sit in the org, my answer isn’t a reporting line ( and I love team topologies). Find the most senior person running the part of the business that makes the money and go solve their problems for them. Proximity to the money beats proximity to the tech. When I coach data teams I ask: how does this company actually make money? A surprising number can’t answer it. And if you can’t, no structure will save and you’ll build beautiful pipelines nobody needed.

The Interview Process

I don’t run the same process for every role, and I don’t do homework assignments for most of them.

For analysts and data scientists, I do set a homework piece but it’s a “trap”.
It’s a complete, realistic-ish scenario, and I assume from the start that most people will use AI to solve it these days. I leave bugs in the gaps on purpose: broken joins in generated data, circular references, and the messy issues you’d find on a real data team. Then I pose questions on top. I’m not marking the code I’m watching whether they notice. The candidates who find the planted problems are the ones who read data instead of just processing it.

For engineers, I’ve moved away from perfect code and TDD purity toward systems thinking. Usually it’s as simple as an Excalidraw board and a bunch of scenarios. What happens if this system goes down? What if you need to scale and I don’t usually mean data volume; sometimes it’s your security posture, sometimes it’s the data model. Everything comes with trade-offs, and I want to hear you reason about them out loud. I do still expect a senior engineers to know the difference between functional and object-oriented programming and testing patterns and trade offs. But the signal I’m after is how you think, not whether you memorised the textbook, and practiced leet code until you barf.

Data modeling is my favorite depth-check. What do you think of dimensional modeling? What is it? Do you know anything beyond star schema? Give me a scenario where you’d use it. Where I work now we run a mixture facts and dimensions where they earn their keep, activity schema alongside. I’m looking for people who grasp the concepts and can iterate around them, not recite them.

And through all of it, one filter matters most to me is do they want to work with the business, or just be technical? The best people I’ve hired lead with business-first questions before they touch a keyboard/Wispr flow.

AI in Interviews

Technical interviewing is broken, and AI broke it faster than anyone wants to admit, I’ve written about this on my substack and linkedin. I’ve had a candidate on Zoom with his hands in the air while his cursor kept moving and code kept appearing. “I’m not using AI,” he said. Yeah right.

Over past year I ran 35+ technical interviews for senior roles & staff engineers, people with Amazon and Bloomberg and Meta on their CVs. Six could finish a 45-minute basic Python challenge, with AI allowed for syntax. Twenty-nine reached straight for pandas on a for-loop problem, and froze when I asked for plain Python.

The problem isn’t cheating. It’s that we’ve trained a generation to operate tools instead of solve problems. People are either capable with AI or helpless without it is what worries me.

So I recently I stopped fighting AI and designed for it:

• AI is allowed for syntax, not solutions most of the time Sometimes I’ll even say: solve it with AI, and let’s walk through your prompts together. How you direct the tool is a skill worth assessing.

• Explain the problem back to me before you code. Edge cases, approach, plain English. Jump straight to code and you fail, every time yeah I’m harsh.

• I plant a test that fails on purpose. I want to see whether you read the tests or just try to make them pass.

• Teach it back. Explain your solution as if I’m a junior engineer. If ChatGPT wrote it chances are you can’t.

For most candidates, my advice is simple. Do use AI I expect you to; pretending you don’t is the real red flag. Don’t outsource the thinking. If you can’t explain the basics of the code when asked, you’ve borrowed understanding. This borrowed thinking often catches up with you, usually around week three of the job after you go live.

Closing thoughts

Everything in my process comes back to one belief: fundamentals are getting more valuable, not less. I borrow a concept from DevOps that my friend Shane Gibson mentioned. Tools will keep changing, and the platforms are like cattle which are swappable every few months. The judgment, the context, the understanding of how the business actually makes money that’s the pet. That’s what I hire for.

And if your background is weird forklift driver, jazz musician, yoga teacher that’s not a gap in your CV. Some of the best engineers I’ve worked with came in sideways. You don’t need the credential. You need to solve the problem in front of you, and then do that again, a thousand times.