As a Full Stack Engineer, you’re building both the backbone and the user experience of AVOW’s technology. How would you describe the tech culture and engineering spirit at AVOW? What makes building product here feel unique compared to other tech environments?
Two things define engineering at AVOW: ownership, and the people you get to do it with.
We’re a small team covering a lot of ground: the data pipelines, the APIs, AVOW’s Performance Hub, and the tools our colleagues use every day, so you follow a feature from the data model all the way to the screen. One of the projects I’m proudest of was moving our ETL off a single server running cron jobs onto Airflow. We treated that migration as an invitation to make the pipeline genuinely better, not just lift and shift it. One data extraction job was stretching to nearly two hours at month-end; I reworked it to pull the data in parallel date slices, carefully bounded so we stay inside our partners’ API limits, and brought it down to 15 mins EOM. Nobody assigned me that; I noticed it, proposed it, and was trusted to decide how.
That trust is what I hadn’t found before. Here you’re expected to act rather than wait for permission, and the bar is simply being able to explain how your decision serves the goal. But you’re never deciding alone; asking for a second opinion is normal, and the team really does work as one. Real autonomy with real support: that’s what makes building here feel different.
Adtech moves fast, and tech stacks evolve constantly. Beyond clean code, what mindset or qualities do you think are essential for a Full Stack Engineer to thrive at AVOW?
For me, it comes down to one thing: understand the business and the data, not only the code.
You can be excellent at building features and great at communicating across teams, and it still won’t be enough. In adtech, the numbers are the product; they become invoices, payouts, and the decisions our partners make about their budgets. If you don’t know how the business actually makes money, or how your data behaves, you can ship something that works perfectly and is still wrong.
That understanding is also what keeps you useful when the stack changes, and it changes often. Tools come and go; domain knowledge carries over.
So the quality I’d name is curiosity about the parts of the job that aren’t software.
Full stack engineering often requires translating complex technical ideas into smooth products for non-tech stakeholders. How do you and the Tech & Product team stay closely aligned with other teams across different regions?
Our teams sit across Europe, APAC, and LATAM, so alignment can’t depend on everyone being awake at the same time. Most of it runs through our product manager, who bridges the commercial side and the tech team in both directions.
The part that matters most happens before any code exists: for anything complex, we agree on the plan and on what “done” means, in plain language and written down. That is the real translation work, not explaining how something is built but confirming we are solving the problem the stakeholder actually has.
What is one modern framework or tool you’ve grown to love recently, and what is one technical bug or manual dev task you wish you could eliminate forever?
Airflow, and specifically dynamic task mapping. You describe a unit of work once and let the scheduler fan it out instead of hand-writing every task. It turned one long sequential extraction into many small parallel ones, and the side effect is what I grew to love: when something fails, you retry one slice, not the whole run. It changed how I think about designing pipelines.
The thing I would eliminate is manual data corrections. There are changes our users should be able to make themselves, where something is adjusted after the fact, and every downstream number recomputes correctly on its own. Today, a few of those still have to pass through an engineer. The work isn’t difficult; it just shouldn’t need us. Anything a user can do safely, with a proper audit trail, belongs in their hands and not in a ticket.
Outside of engineering and writing code, what keeps you inspired or energized in your free time? How does that passion influence the way you approach logic or problem-solving at work?
I’m up between 5:30 and 6 for a workout before the day starts. That has become my fuel. After work, I read to rest my eyes from any screen. Weekends are the same routine, plus friends and any social plan that might surface.
The link to work is simpler than it sounds. Training is small, repeatable effort: nothing changes in a day, and everything changes in a few months. That is also how good systems get built, and it has made me patient with problems that do not resolve in one sitting. The other part is stepping away. Some of my better solutions showed up while I was lifting or halfway through a book chapter, not while staring at the code. So I have learned to treat rest as part of the work instead of the opposite of it.
“Lightning Round”
Frontend or Backend? (Or the delicate balance of both?)
Delicate balance, but I prefer 70% backend / 30% Frontend
Tab vs. Spaces / Dark Mode vs. Light Mode?
Tab / Dark Mode
Favorite keyboard shortcut you couldn’t live without?
Not one shortcut, a whole row of them: my F keys, each mapped to a specific job, plus a terminal alias for everything I type more than twice. Two keystrokes instead of twenty, a hundred times a day.
Coffee, tea, or water when pushing code to production?
Coffee.
Looking to join the A-team and curious about life at AVOW? Check out our careers page for more info and the latest opportunities!
About the Author
