Hiring a senior .NET freelancer is one of the highest-impact technical decisions a company or agency makes, and at the same time one of the worst-evaluated. Standard interviews — those with questions like "explain the difference between abstract and interface" or "what is dependency injection" — filter juniors very well but don''t distinguish between a real senior with scars and a mid-level developer selling themselves as senior because they''ve been programming for five years.
I''m going to share what actually works after being on both sides many times: as a freelancer going to interviews and as a senior who has interviewed and filtered other freelancers for reinforcement work. The good news is that with three or four well-chosen questions and an honest technical test you can filter 90 % of candidates in under two hours.
The 5 questions that separate the senior from the confused
These are the questions I would ask — and the ones I''ve been asked by the most serious clients who hired me. They''re not looking for the candidate to know the "correct" answer, they''re looking to see how they think, what experiences they bring, and whether they distinguish between what they''ve read and what they''ve lived.
1. "Tell me about a project where you got it wrong and what you learned"
This question immediately separates the authentic senior from the one inflating their resume. A real senior has identifiable failures: an architecture that didn''t scale, an estimate that doubled, a technical decision they had to roll back. And they tell it without drama, with perspective, knowing exactly what signals they should have seen earlier.
If the candidate tells you they''ve never gotten anything wrong, or that all their projects have gone well, bad sign. Either they''re lying, or they don''t take responsibility for their decisions, or they''ve done projects too small to have scars. None of the three is what you want to hire.
2. "What technology have you stopped using in the last two years and why?"
A senior has opinions. They know why they stopped using Entity Framework a certain way, why they switched from Newtonsoft.Json to System.Text.Json (or why they didn''t in legacy projects), why they abandoned a pattern they defended for years. This shows they keep learning and that they have criteria to discard, not just to adopt.
If they say "I use everything that comes out, it''s the newest", be suspicious. New isn''t always better, and a senior with judgment knows how to distinguish trend from real improvement. Most projects I see with "very modern" tech are built by people who confuse being up-to-date with knowing how to choose.
3. "If I give you a legacy module in .NET Framework 4.8 with no tests or docs, where do you start?"
The dream project is greenfield with modern stack. The real project is often legacy with eight-year-old code and nobody who can explain it. Whoever lacks experience usually answers "I''d rewrite it". A senior with scars will talk about reading the code first, writing characterization tests before touching anything, identifying risks before proposing changes, and possibly spending the first week without writing a single productive line of code.
This question also tells you a lot about whether the candidate will respect the previous team''s work. Whoever arrives despising all existing code and wanting to rewrite is a huge risk — they''ll generate internal resistance, break things that did work, and demoralize the team that''s been maintaining what they consider "garbage".
4. "How do you decide whether a task requires automated tests or not?"
Trick question. The "absolutist" answer — everything requires tests, or nothing does — tells you the candidate hasn''t worked on real projects with time and budget pressure. A real senior will talk about balance: mandatory tests on critical business logic, optional tests on UI or configuration, characterization tests before touching legacy, decisions based on the specific test''s ROI.
What you''re looking for in this question is nuance. The reality of professional development is gray, not black or white, and good seniors know it. If they recite the testing pyramid principles like an exam, they''ve read the books but haven''t faced real decisions with a client waiting.
5. "What do you need from me or my team to succeed on this project?"
This is one of the most revealing. A senior freelancer knows their success also depends on what you contribute — clear requirements, access to stakeholders, time for meetings, an available PO. If the answer is "nothing, give me the repo and accesses and that''s it", they probably haven''t worked on projects where lack of internal coordination was the bottleneck.
The answers I see as green flags are like: "I need half an hour a week with you or whoever decides priorities", "I need access to someone on the team when I have functional questions", "I prefer to deliver in short sprints to adjust direction". This shows they understand how things get done and that they''ll integrate well.
What to ask in the technical test (without slavery)
Technical tests that last 8 hours, require uploading to a private GitHub, and then nobody reviews are an insult. And a senior doesn''t do them, because they have better things to do with their Saturday afternoon. If your selection process includes that, you''re going to filter out the seniors you want and end up only with those desperate to find work.
What does work is a 60 to 90 minute technical conversation about a real problem, where the candidate can think aloud, ask questions, propose alternatives and defend decisions. You give them a concrete problem — "I have this endpoint taking 8 seconds, how would you diagnose it?", or "this code is duplicated in four places, how would you refactor it and what risks do you see?" — and let them drive the conversation.
If you need to see code written by the candidate, ask for a public repository of theirs, don''t make them write a new one for you. Any senior with several years of work has personal projects, open source contributions or examples they can share. That tells you more than a FizzBuzz kata done in a hurry.
Realistic rates in Spain in 2026
Malt''s 2026 barometer for Spain puts the average senior C# developer rate around €335 per day. The upper tier — profiles with cloud architecture specialization, tech lead, or proven experience in regulated sectors — ranges between €500 and €700 per day. Below €250 per day in the current market, you''re usually looking at mid-level profiles selling themselves as senior.
Those numbers are full day (8 hours). If you work with hourly rate, the reasonable conversion is between €42 and €90 per hour depending on seniority and specialization. And an important detail many companies ignore: a senior freelancer only charges hours worked. No vacations, no sick days, no training, no gaps between projects. So the comparison with an in-house employee isn''t rate-vs-gross, it''s rate-vs-total-company-cost (including social security, benefits, computer, office and everything else).
When the proposal figure seems high, divide it by real work hours and compare it to the real cost of an equivalent employee. Almost always the senior freelancer comes out better on closed projects, especially when it''s a specific piece of work and not a permanent position.
Engagement models: which fits you
There are three main ways to engage a senior freelancer, and choosing well avoids half the problems that arise later.
Fixed-price project. You agree scope, timeline and price before starting. The freelancer delivers what was agreed at the agreed price and takes on the risk of deviations. It''s the best option when scope is clear and the client wants predictability. It''s the worst when scope is going to change a lot during the project — in that case, the freelancer will overestimate to protect themselves and you''ll pay more than necessary.
Time & Materials (by hour or by day). You pay actual hours worked. More flexibility for you, less predictability. Works well for exploratory projects, team reinforcement, or maintenance work where you don''t know how much it''ll be until you look. Key here is having weekly hour reports and an updated forecast every two or three weeks so there are no surprises.
Monthly retainer. You contract X hours per month guaranteed, whether the project needs them or not. Fits very well with legacy app maintenance or clients needing someone "on call" technically. Cheaper per hour for the client and gives the freelancer stability. It''s my favorite model for long-term relationships.
Red flags I see in other freelancers
These are the signals that, when they appear, make me recommend a client keep looking. They''re not lethal individually, but combined they''re a serious risk.
Zero verifiable references or references that don''t answer the phone. If nobody can confirm they''ve worked with the person, assume the worst case.
Suspiciously cheap quotes. When someone offers a project at 40 % of market price, one of three: underestimates scope, will offshore work to juniors without saying it, or you''ll receive something half-finished. And sometimes all three.
Insists on starting before having scope signed. A serious freelancer wants to protect themselves and you with written scope. Whoever skips that part is because they plan to reinterpret scope on the fly.
No online technical presence — no public repo, no blog, no LinkedIn with real interaction, no community. It''s not mandatory, but a senior with fifteen years of experience usually has left technical traces somewhere.
Talks in absolute terms about technology: "I always use microservices", "I never use ORMs", "I do everything with Vertical Slice". Software reality is contextual, and a senior knows it.
Green flags that go unnoticed
And conversely, these are positive signals many clients don''t value enough when interviewing candidates.
They ask uncomfortable questions about your business on the first call. Not just about the tech stack, but about the business model, stakeholders, decisions made, ones still open. That indicates they''ll integrate, not just deliver code.
They say "I don''t know" when they don''t know. Without defensiveness, without inventing. This is very hard to fake and it''s one of the most reliable markers of real seniority.
They have a defined work process and explain it without you asking. Sprints, demos, deployments, how they log hours, how they communicate blockers. That''s a sign they''ve worked professionally and know what a healthy collaboration looks like.
When you explain your idea, they come back with questions you hadn''t considered. A good senior raises risks and doubts you should be thinking about but aren''t. If they just nod and say "perfect, that can be done", they probably haven''t understood scope — or don''t want to understand it to avoid scaring you with the budget.