Hiring is one of the ways Dashdoc becomes itself. We look for a mutual fit: people who share our values and way of working, and who will also leave their own mark on the team.
Dashdoc is the transportation management product used by thousands of carriers and shippers in Europe. Our engineering team is 40+ people. This post is simply how we hire today: what you’ll go through, in order, and what we care about.
Heads-up: We tweak this process over time. What you read here is our current version, not carved in stone.
Order and pace: The sequence below is the usual one, but it can shift a bit depending on calendars (yours and ours). We don’t have a single fixed “standard duration”: it depends on how fast we can book slots and how deep we need to go. We aim for steady progress once we’ve started: concrete dates, keeping back-and-forth over email to a minimum, and a clear “where we are” when you ask.
Selection process: So far, every CV is read by a human, no automated filtering. We can’t commit to giving personal feedback to every applicant, but every application is genuinely read. When we don’t move forward with someone, it’s usually less a matter of skill level than of fit for the specific role we’re hiring on.
The rounds
Every step is a two-way conversation: we try to be clear about what that slot is for, you can ask us anything, and nothing here is meant to trip you up. We leave time in each session for your questions on the role, the stack, how we work, or what comes next.
Why these rounds
We want our interviews to reflect the actual work, not reward people for being good at interviews. Day to day, our engineers read unfamiliar code, debug real systems, shrink big problems into shippable slices, and talk about trade-offs with people who aren’t engineers. The mix below is what we’ve found maps best to that, including the parts that are tiring for everyone, because hiring without enough depth tends to hurt both sides later.
1. Screening call, ~30 min, remote 💬
We use the same baseline questions for everyone so it stays fair, and so we don’t forget the basics.
We want to know your path, what you’re looking for, and what drives you. You can ask us anything, we’ll be straight about what’s great here and what’s hard.
This is usually conducted by an engineering manager, and it’s a good opportunity to ask us anything you want to know about the role, the company, the team, the stack, etc. You’ll be asked about your salary expectations, your availability, your notice period, etc.
What helps on your side: you don’t need to “study.” A rough idea of what you’ve done recently, what you want next, and why Dashdoc (even if that reason is still fuzzy) would work for you. If you’re unsure about seniority, team, or scope, don’t be afraid to say it!
2. Technical test, ~45 min to 1 h, remote 🐛
No whiteboard. No LeetCode.
You get a full-stack debugging task on a small, messy legacy codebase. The goal is for it to be closer to “joining a team” than to a textbook exercise (our codebase is tidier than the exercise, for what it’s worth 😅).
We care how you find your way in unfamiliar code: how you read it, what you ask, what you’d change and why. We’re not testing whether you’ve memorized Django or React. We are used to interviewing people with no experience on our stack; we’ll help with details if you need it. We’re interested in how a typical SaaS (frontend + API + how they talk) fits together.
The bug itself isn’t huge; what we care about is how you navigate unknown code calmly and methodically.
Format: it’s a live session with engineers from the team. You share your screen, explore the repo, and talk us through what you’re seeing. We’re not grading your typing speed; we’re watching how you structure the search (where you look first, what you verify, how you narrow it down). If you’re stuck, say so! We’d rather see how you unblock with help than watch anyone pretend.
What helps: a quiet slot and a good internet connection. Let’s be honest: the bug itself is usually not the hardest part, yet this is the most selective step, because it shows how clearly someone can build a mental model of unfamiliar code and follow the execution path under time pressure. My advice: don’t rush, have no assumptions about the code, just follow the code and how the frontend and backend interact.
3. Product & tech shaping, ~1.5 h, remote or on-site 🎯
This part is a bit specific to us, and we like it.
We imagine you’re shipping an MVP for a product idea. Together we shape scope: what is the problem we’re really trying to solve, who is it for, what ships first, what waits, how you’d structure it, what you’d bet on technically.
There’s no model answer. We want to see how you think with us: product sense, trade-offs, and how you explain choices. At Dashdoc, engineers own features end to end (problem → ship); this session is a compressed version of that kind of discussion.
Format: we bring a short written brief; the rest is discussion. Whiteboard, notes, bullet lists, whatever helps you think. It’s normal to challenge the premise, to ask “who is this for?”, or to change your mind once we add a constraint. We’re not scoring a slide deck; we’re watching how you collaborate under uncertainty.
4. The “Who” interview, ~45 min to 1 h, remote or on-site 📖
Loosely based on the Who approach: we walk through your story. What you built, what you’re proud of, what you’d do differently, how you grew.
We’re listening for how you work: ownership, honesty about mistakes, curiosity.
What to expect: we’ll spend time on a few chapters of your career, not every bullet on your CV. Come with 2–3 examples you’re happy to go deep on (a messy project, a conflict you handled, a decision you’d revise). Specific beats abstract every time.
5. Reference calls 🤝
We’ll ask for a few people you’ve worked with (peers, managers, etc.) and have short chats with them. It rounds out what interviews can’t always show: strengths, how you collaborate, and where you’re still growing.
We usually ask for references when we’re seriously considering an offer, not as a generic paperwork step at the start. We’ll tell you what we’re trying to learn so you can pick people who’ve actually seen you work.
6. Meet a founder, ~30 min, remote ☕
Informal chat with our CEO or CTO; where the company is headed on our side, what pulls you in on yours. A last mutual check-in before we hopefully work together.
Why it’s there: at our size, founders are still close to strategy and culture. This isn’t a veto round on trivia; it’s a chance for both sides to sanity-check “does this still feel right?”
Things we want you to know 💛
You can stop anytime, so can we. If Dashdoc isn’t for you, say so; we’ll take it well. If we don’t continue, we’ll tell you as soon as we can.
We try not to drag things out. Long ghosting helps nobody. We want enough time to decide properly, without losing momentum.
We hire the way we’d want to be hired. Interviewers know the brief: be explicit about what each round is for, give you room to think out loud, and answer your questions honestly. We’re not playing roles or setting ambushes, we’re checking whether working together would make sense on both sides.
That lines up with how we talk about our values day to day. Care means feedback you can use and a no that comes with clarity, not silence. Ambition and Passion show up in serious, engaged conversations, not in pressure tricks. Speed is about respecting your time: keeping the process moving and not leaving you guessing for weeks.
You don’t need a logistics background. Some of us knew freight before joining; most didn’t. You just need to be curious about the domain!
We’re still improving this
Like any product, our hiring process gets feedback and iterations. We ask candidates and interviewers what felt fair, clear, and respectful.
If something was confusing or unnecessarily heavy, we want to know! It helps us fix the process.
Been through it? We’d love your honest take. Thinking of applying? Hope this helps you know what to expect.
If helping reshape how transport runs sounds like your kind of problem, we’d love to hear from you.