
Made tech Software Engineer interview typically runs 3 rounds: HR, technical system design/pair programming, and a scenario-based architect conversation. The process took a little over two weeks and felt rushed and highly structured.
$41K
Avg. Base Comp
$90K
Avg. Total Comp
3
Typical Rounds
2-3 weeks
Process Length
Our candidates report that Made Tech is looking for engineers who can stay grounded when the conversation gets concrete. The strongest signal isn’t flashy architecture; it’s whether you can take a public-service style problem, turn it into a sensible design, and then keep extending that same solution in code without losing the thread. We’ve seen repeated emphasis on pragmatic tradeoffs and a collaborative, test-driven mindset, which suggests they care less about perfect answers than about how you reason in real time.
A recurring theme is how opinionated the panel can be about delivery style. One candidate described architects pushing on digital transformation and client discovery in a very practical way, with a clear preference for someone who can gather requirements from a customer and translate them into something buildable. That lines up with the coding feedback too: they seemed to value detail-oriented implementation and TDD over algorithmic cleverness. In other words, they want to see whether you can work like someone who will actually ship with a team, not just whiteboard alone.
We’ve also noticed that the process can feel checklist-driven, so concise, structured thinking matters. Candidates who did best were ready to explain why they chose a particular cloud feature, how they handled a recent project, and how they’d resolve conflict without drifting into theory. The non-obvious trap here is over-engineering: if your design sounds impressive but not practical, it can work against you. Made Tech appears to reward engineers who can be calm, specific, and useful under pressure.
Synthesized from 1 candidate report by our editorial team.
Had an interview recently?
Share your experience. Unlock the full guide.
Real interview reports from people who went through the Made tech process.
The part that stood out most to me was how quickly they moved from small talk into a very structured technical exercise. My first round was with HR and it was pretty informal, mostly about my background, why I was interested in the role, and a recent project I had worked on. After that, the process moved into a longer technical round that lasted about an hour and combined system design with pair programming. They gave me a public-service style use case and asked me to design the system first, then immediately switched into coding specific use cases on top of that same problem. The coding portion felt less like a classic algorithm interview and more like they were watching how I reasoned through the design and whether I could work in a collaborative, test-driven way. They seemed to care a lot about TDD, keeping the solution detail-oriented, and making pragmatic choices rather than trying to impress them with a fancy architecture.
I also had a scenario-based conversation with two architects, which was more about how I would approach a digital transformation and how I’d go to a client to gather requirements. That round felt very practical and a bit opinionated; they wanted to see a grounded approach instead of a theoretical one. In the earlier technical discussion, I was also asked to design and code a bike rental system, and there were behavioral questions about my ideal development process, a recent project and the cloud features behind it, and how I handled conflict with a colleague. Overall the interviews took a little over two weeks and felt rushed at times, with interviewers moving quickly through their checklist. The panel was friendly enough, but the process was very box-ticking and not especially interested in getting to know me beyond the answers. I didn’t get an offer, and my main takeaway was to be ready to jump straight into a practical system design, explain tradeoffs clearly, and code in a collaborative TDD style under time pressure.
Prep tip from this candidate
Practice designing a public-service or bike-rental style system, then be ready to turn that design into pair-programming use cases with a TDD mindset. Also prepare to explain the cloud features and tradeoffs behind a recent project, since they asked for that level of detail.
Share your own interview experience to unlock all reports, or subscribe for full access.
Sourced from candidate reports and verified by our team.
Topics based on recent interview experiences.
Featured question at Made tech
How would you negotiate and resolve disagreements when a client rejects your proposed solution?
| Question | |
|---|---|
| 2nd Highest Salary | |
| Top Three Salaries | |
| Merge Sorted Lists | |
| Empty Neighborhoods | |
| Employee Salaries | |
| Closest SAT Scores | |
| Subscription Overlap | |
| Monthly Customer Report | |
| Prime to N | |
| Top 3 Users | |
| Rolling Bank Transactions | |
| Customer Orders | |
| String Shift | |
| Comments Histogram | |
| Retailer Data Warehouse | |
| Random SQL Sample | |
| Largest Salary by Department | |
| Find the First Non-Repeating Character in a String | |
| Bagging vs Boosting | |
| Size of Joins | |
| Upsell Transactions | |
| Find the Missing Number | |
| Raining in Seattle | |
| First Touch Attribution | |
| Cumulative Distribution | |
| Hurdles In Data Projects | |
| Manager Team Sizes | |
| Job Recommendation | |
| P-value to a Layman |
Synthesized from candidate reports. Individual experiences may vary.
An informal first conversation with HR focused on your background, motivation for the role, and a recent project. This stage also included some behavioral discussion, such as your ideal development process and how you handled conflict with a colleague.
A structured technical round that moved quickly from system design into coding on the same problem. Candidates were asked to design a public-service style system, then implement specific use cases, with an emphasis on pragmatic choices, test-driven development, and collaborative reasoning.
A practical discussion with two architects about how you would approach a digital transformation and how you would gather requirements from a client. The interview was grounded in real-world consulting scenarios and favored a hands-on, opinionated approach over theoretical answers.