Contratar a un freelance senior .NET es de las decisiones técnicas con más impacto que toma una empresa o agencia, y al mismo tiempo de las que peor se evalúan. Las entrevistas estándar — esas con preguntas tipo "explícame la diferencia entre abstract e interface" o "qué es la inyección de dependencias" — filtran muy bien juniors pero no distinguen entre un senior real con cicatrices y un developer mid que se vende como senior porque hace cinco años que programa.
Voy a contarte lo que de verdad funciona después de haber estado en los dos lados muchas veces: como freelance que se presenta a entrevistas y como senior que ha entrevistado y filtrado a otros freelance para refuerzo. La buena noticia es que con tres o cuatro preguntas bien elegidas y una prueba técnica honesta puedes filtrar al 90 % de los candidatos en menos de dos horas.
Las 5 preguntas que separan al senior del confundido
Estas son las preguntas que yo haría — y que me han hecho a mí cuando me han contratado los clientes más serios. No buscan que el candidato sepa la respuesta "correcta", buscan ver cómo piensa, qué experiencias trae y si distingue entre lo que ha leído y lo que ha vivido.
1. "Cuéntame de un proyecto donde te equivocaste y qué aprendiste"
Esta pregunta separa inmediatamente al senior auténtico del que infla su currículum. Un senior real ha tenido fracasos identificables: una arquitectura que no escaló, una estimación que se fue al doble, una decisión técnica que tuvieron que dar marcha atrás. Y lo cuenta sin drama, con perspectiva, sabiendo exactamente qué señales debería haber visto antes.
Si el candidato te dice que nunca se ha equivocado, o que todos sus proyectos han ido bien, mala señal. O miente, o no asume responsabilidad sobre sus decisiones, o ha hecho proyectos demasiado pequeños como para tener cicatrices. Ninguna de las tres opciones es lo que quieres contratar.
2. "¿Qué tecnología has dejado de usar en los últimos dos años y por qué?"
Un senior tiene opiniones. Sabe por qué dejó de usar Entity Framework de cierta forma, por qué se cambió de Newtonsoft.Json a System.Text.Json (o por qué no lo hizo en proyectos legacy), por qué abandonó un patrón que defendió durante años. Esto demuestra que sigue aprendiendo y que tiene criterio para descartar, no solo para adoptar.
Si te dicen "yo uso todo lo que sale, es lo más nuevo", desconfía. Lo nuevo no siempre es mejor, y un senior con criterio sabe distinguir tendencia de mejora real. La mayoría de proyectos que veo con tecnología "muy moderna" están hechos por gente que confunde estar al día con saber elegir.
3. "Si te doy un módulo legacy en .NET Framework 4.8 sin tests ni documentación, ¿por dónde empiezas?"
El proyecto de los sueños es greenfield con stack moderno. El proyecto real es muchas veces legacy con código de hace ocho años y nadie que sepa explicarlo. Quien no tiene experiencia con eso suele responder "lo reescribiría". Un senior con cicatrices te va a hablar de leer el código primero, escribir tests de caracterización antes de tocar nada, identificar los riesgos antes de proponer cambios, y posiblemente pasar la primera semana sin escribir una sola línea de código productivo.
Esta pregunta también te dice mucho sobre si el candidato va a respetar el trabajo del equipo anterior. Quien llega despreciando todo el código existente y queriendo reescribir es un riesgo enorme — porque va a generar resistencia interna, va a romper cosas que sí funcionaban, y va a desmoralizar al equipo que se quedó manteniendo lo que él considera "basura".
4. "¿Cómo decides si una tarea requiere tests automatizados o no?"
Pregunta trampa. La respuesta "absolutista" — todo requiere tests, o nada requiere tests — te dice que el candidato no ha trabajado en proyectos reales con presión de tiempo y presupuesto. Un senior real va a hablar de equilibrio: tests obligatorios en lógica de negocio crítica, tests opcionales en UI o configuración, tests de caracterización antes de tocar legacy, decisiones según ROI del test concreto.
Lo que buscas en esta pregunta es matiz. La realidad del desarrollo profesional es gris, no blanca o negra, y los senior buenos lo saben. Si te recitan los principios de la pirámide de testing como si fuera un examen, han leído los libros pero no han enfrentado decisiones reales con un cliente esperando.
5. "¿Qué necesitas de mí o de mi equipo para tener éxito en este proyecto?"
Esta es de las más reveladoras. Un freelance senior sabe que su éxito depende también de lo que tú aportes — claridad de requisitos, acceso a stakeholders, tiempo para reuniones, un PO disponible. Si la respuesta es "nada, dame el repo y los accesos y ya está", probablemente no ha trabajado en proyectos donde la falta de coordinación interna fue el cuello de botella.
Las respuestas que me parecen verdes son del tipo: "necesito media hora a la semana contigo o con quien decida prioridades", "necesito acceso a alguien del equipo cuando tenga dudas funcionales", "prefiero entregar en sprints cortos para ajustar dirección". Esto demuestra que entiende cómo se hacen las cosas y que va a integrarse bien.
Qué pedir en la prueba técnica (sin esclavismo)
Las pruebas técnicas que duran 8 horas, exigen subirlas a GitHub privado y luego nadie las revisa son un insulto. Y un senior no las hace, porque tiene mejores cosas que hacer con su tarde de sábado. Si tu proceso de selección incluye eso, vas a filtrar a los seniors que te interesan y vas a quedarte solo con los desesperados por encontrar trabajo.
Lo que sí funciona es una conversación técnica de 60 a 90 minutos sobre un problema real, donde el candidato puede pensar en voz alta, hacer preguntas, proponer alternativas y defender decisiones. Le das un problema concreto — "tengo este endpoint que tarda 8 segundos, ¿cómo lo diagnosticarías?", o "este código está duplicado en cuatro sitios, ¿cómo lo refactorizarías y qué riesgos ves?" — y dejas que conduzca la conversación.
Si necesitas ver código escrito por el candidato, pide un repositorio público suyo, no le hagas escribir uno nuevo para ti. Cualquier senior con varios años trabajando tiene proyectos personales, contribuciones a open source o ejemplos que puede compartir. Eso te dice más que un katas de FizzBuzz hecho con prisa.
Tarifas realistas en España en 2026
El barómetro de Malt España para 2026 sitúa la tarifa media de un desarrollador C# senior en torno a 335 € al día. El tramo superior — perfiles con especialización en arquitectura cloud, lead técnico, o experiencia probada en sectores regulados — se mueve entre 500 € y 700 € al día. Por debajo de 250 € al día, en el mercado actual, normalmente estás mirando perfiles mid que se venden como senior.
Esos números son por día completo (8 horas). Si trabajas con tarifa por hora, la conversión razonable está entre 42 € y 90 € la hora según seniority y especialización. Y un detalle importante que mucha empresa ignora: un freelance senior cobra solo las horas trabajadas. No cobra vacaciones, ni bajas, ni formación, ni los huecos entre proyectos. Así que la comparación con un empleado en plantilla no es tarifa-vs-bruto, es tarifa-vs-coste-total-empresa (que incluye seguridad social, beneficios, ordenador, oficina y todo lo demás).
Cuando la cifra de la propuesta te parezca alta, divídela entre las horas reales de trabajo y compárala con el coste real de un empleado equivalente. Casi siempre el freelance senior sale mejor por proyecto cerrado, especialmente cuando es una pieza de trabajo concreta y no un puesto permanente.
Modelos de contratación: cuál encaja contigo
Hay tres formas principales de contratar un freelance senior, y elegir bien la modalidad evita la mitad de los problemas que surgen después.
Proyecto cerrado. Pactas alcance, plazo y precio antes de empezar. El freelance entrega lo acordado al precio acordado y asume el riesgo de las desviaciones. Es la mejor opción cuando el alcance está claro y el cliente quiere predictibilidad. Es la peor cuando el alcance va a cambiar mucho durante el proyecto — en ese caso, el freelance va a sobreestimar para protegerse y vas a pagar más de la cuenta.
Time & Materials (por horas o por días). Pagas las horas realmente trabajadas. Más flexibilidad para ti, menos predictibilidad. Funciona bien para proyectos exploratorios, refuerzo a tu equipo o trabajo de mantenimiento donde no sabes cuánto va a salir hasta que lo miras. La clave aquí es tener informes semanales de horas y una previsión actualizada cada dos o tres semanas para que no haya sorpresas.
Retainer mensual. Contratas X horas al mes garantizadas, lo necesite el proyecto o no. Encaja muy bien con mantenimiento de apps legacy o con clientes que necesitan a alguien "de guardia" técnicamente. Sale más barato por hora para el cliente y le da estabilidad al freelance. Es mi modalidad favorita para relaciones a largo plazo.
Banderas rojas que veo en otros freelancers
Estas son las señales que, cuando aparecen, me hacen recomendar a un cliente que siga buscando. No son letales por separado, pero combinadas son un riesgo serio.
Cero referencias verificables o referencias que no contestan al teléfono. Si nadie puede confirmar que ha trabajado con la persona, asume el peor caso.
Presupuestos sospechosamente baratos. Cuando alguien ofrece un proyecto al 40 % del precio de mercado, una de tres: subestima el alcance, va a sacar el trabajo a juniors sin decirlo, o vas a recibir algo a medio terminar. Y a veces las tres.
Insiste en empezar antes de tener firmado el alcance. Un freelance serio quiere protegerse a sí mismo y a ti con un alcance escrito. Quien se salta esa parte es porque planea reinterpretar el alcance sobre la marcha.
No tiene presencia técnica online — ni repositorio público, ni blog, ni LinkedIn con interacción real, ni comunidad. No es obligatorio, pero un senior con quince años de experiencia normalmente ha dejado huella técnica en algún sitio.
Habla en términos absolutos de tecnología: "siempre uso microservicios", "nunca uso ORMs", "todo lo hago con Vertical Slice". La realidad del software es contextual, y un senior lo sabe.
Banderas verdes que pasan desapercibidas
Y al revés, estas son señales positivas que muchos clientes no valoran lo suficiente cuando entrevistan candidatos.
Hace preguntas incómodas sobre tu negocio en la primera llamada. No solo pregunta por el stack técnico, también por el modelo de negocio, los stakeholders, las decisiones tomadas, las que están abiertas. Eso indica que va a integrarse, no solo entregar código.
Dice "no sé" cuando no sabe. Sin defensividad, sin inventar. Esto es muy difícil de fingir y es uno de los marcadores más fiables de seniority real.
Tiene un proceso de trabajo definido y te lo explica sin que se lo pidas. Sprints, demos, despliegues, cómo registra horas, cómo comunica bloqueos. Eso es señal de que ha trabajado profesionalmente y sabe cómo es una colaboración sana.
Cuando le explicas tu idea, te devuelve preguntas que no te habías planteado. Un senior bueno levanta riesgos y dudas que tú deberías estar pensando pero no estás. Si solo asiente y dice "perfecto, eso se puede hacer", probablemente no ha entendido el alcance — o no quiere entenderlo para no asustarte con el presupuesto.