Qué hace un Scraper Developer: perfil, descriptor y qué evaluar al contratar

Cuando una empresa dice que necesita "alguien que saque datos de internet", todavía no tiene un descriptor. Tiene una necesidad de información y varios riesgos mezclados: una fuente que cambia, datos duplicados, una operación que se cae de madrugada y reglas de uso que nadie revisó.

Un Scraper Developer diseña y mantiene sistemas para obtener, estructurar, validar y entregar datos desde fuentes web autorizadas o permitidas. También puede aparecer como web scraping engineer, data acquisition engineer, desarrollador de automatización o desarrollador de software con foco en datos. El título importa menos que el mandato: convertir una fuente externa cambiante en datos útiles, trazables y operables.

Como base de competencias transversales, revisa el Diccionario de Cargos — scraper developer. Para el rol de software más amplio, la ficha de desarrollador de software complementa habilidades generales. Luego aterriza el perfil al tipo de fuente, dato y decisión que necesita tu empresa.

Qué hace un Scraper Developer en la práctica

El scraping no es copiar y pegar una página ni correr un script una vez. Un sistema serio conecta cuatro responsabilidades:

1. Adquisición: entiende la fuente, prioriza API o exportación cuando exista y define un acceso permitido, medido y respetuoso de límites.
2. Extracción y normalización: transforma contenido variable en campos consistentes, detecta cambios de estructura y conserva suficiente evidencia para rastrear el origen.
3. Calidad y entrega: deduplica, valida reglas básicas, maneja valores faltantes y deja los datos disponibles para el equipo que los usa.
4. Operación: agenda ejecuciones, monitorea fallas, distingue un cambio de sitio de un problema interno y comunica impacto antes de que una decisión se tome con datos vencidos.

El valor del rol no está en evadir controles, ocultar tráfico ni perseguir información restringida. Está en construir adquisición de datos útil y responsable, con límites claros y una ruta de mantenimiento.

Scraper Developer, Data Engineer, analista de datos y backend: no los mezcles

En una startup una persona puede cubrir más de una columna. Aun así, no es buena idea entrevistar a un analista como si fuera responsable de confiabilidad de un pipeline, ni a un backend como si la experiencia con una API fuera igual a sostener decenas de fuentes cambiantes.

Antes de abrir la búsqueda: define la fuente y la decisión

El mejor filtro se escribe antes de publicar el aviso. Responde estas preguntas con el área dueña del problema:

• ¿Qué decisión habilitarán esos datos y con qué frecuencia?
• ¿Cuáles son las fuentes autorizadas, cuáles tienen API o exportación y cuáles requieren revisión legal o contractual?
• ¿Qué tipo de información queda fuera de alcance, especialmente si involucra datos personales, acceso autenticado o restricciones de uso?
• ¿Cuánto atraso, error o dato faltante tolera el proceso?
• ¿Quién será dueño de aprobar cambios de fuente, priorizar mantenimiento y consumir el resultado?

Un desarrollador no puede resolver una ambigüedad de gobernanza con una librería. Tener estas respuestas permite diseñar una solución proporcional y evita convertir el cargo en una invitación a improvisar.

Cómo armar el descriptor de cargo

Usa la plantilla de descriptor de cargo para escribir un mandato verificable:

1. Propósito: "disponibilizar semanalmente precios normalizados de fuentes autorizadas para decisiones de abastecimiento" es mejor que "hacer scraping".
2. Alcance de fuentes: número y tipo de sitios, APIs, archivos, idioma, volumen estimado y nivel de cambio esperado. No hace falta publicar datos sensibles; sí describir la complejidad.
3. Stack y entregables: lenguaje, orquestación, base de datos, alertas, pruebas, documentación y canal de entrega. Declara lo existente y lo que puede proponer.
4. Calidad: reglas de validación, deduplicación, frescura, muestreo y trazabilidad de origen.
5. Cumplimiento: acceso permitido, límites de tasa, manejo de credenciales, retención y escalamiento a legal/seguridad. No escribas "bypassear bloqueos" como requisito: no es una capacidad que la empresa deba pedir.
6. Operación: define guardias, nivel de respuesta ante fallas y quién toma decisiones cuando una fuente cambia o deja de estar disponible.
7. Nivel de seniority: diferencia a quien implementa un extractor guiado de quien puede diseñar la arquitectura, priorizar deuda y conversar con legal, producto y datos.

Qué evaluar antes de contratar

Un desafío que consiste en descargar una página estática mide muy poco. Para evaluar el oficio sin incentivar prácticas problemáticas, plantea una fuente de prueba controlada, una API pública o un conjunto de HTML preparado por tu equipo.

Pide que la persona explique cómo abordaría:

• Un esquema de datos y normalización para registros incompletos o cambiantes.
• Límites, reintentos, errores, logs y alertas sin generar carga innecesaria sobre la fuente.
• Detección de una modificación en el contenido o estructura de la fuente.
• Validación de calidad antes de entregar una tabla a otra área.
• Trazabilidad: de qué fuente salió cada dato, cuándo se obtuvo y con qué versión de parser.
• Qué haría si no existe permiso claro, aparecen datos personales o la alternativa correcta es una API, acuerdo comercial o consulta a legal.

La conversación posterior importa tanto como el código. Busca a alguien que pueda decir "esto no lo automatizaría todavía" cuando la fuente, el propósito o el permiso son inciertos. Ese criterio protege al negocio mejor que una respuesta espectacular a una prueba aislada.

Señales de alerta

• Promete datos "de cualquier sitio" sin preguntar por autorización, condiciones de uso o finalidad.
• Piensa solo en extracción y no en calidad, mantenimiento u observabilidad.
• No diferencia una API disponible de una página diseñada para una persona.
• Normaliza datos personales sin poder explicar minimización, acceso, retención y responsables.
• El aviso no tiene dueño de datos ni presupuesto para mantener fuentes que inevitablemente cambiarán.

El problema no siempre está en el candidato. Si la empresa no sabe qué fuente puede usar o qué decisión alimentará el dato, aún no está contratando un rol técnico: está postergando una definición de negocio.

Cuándo conviene headhunting TI

Este perfil suele ser más escaso cuando mezcla ingeniería de software, datos y experiencia con una industria regulada o fuentes complejas. Un aviso genérico de "Python + scraping" atrae volumen, pero no necesariamente a quien puede construir una operación confiable y conversar con los responsables correctos.

Un proceso de headhunting permite mapear especialistas y perfiles adyacentes contra el mandato real. Después, una prueba técnica situada, referencias y evaluación psicolaboral de finalistas ayudan a separar habilidad puntual de criterio operativo y colaboración.

Preguntas frecuentes

¿Qué lenguajes debe manejar un Scraper Developer?

Python y JavaScript/TypeScript son frecuentes, pero el lenguaje no define el nivel. Importan más el modelado, el manejo de HTTP y APIs, parsers, persistencia, pruebas, observabilidad y la capacidad de trabajar con límites claros.

¿Necesito un Scraper Developer de tiempo completo?

Depende de cuántas fuentes tienes, cuán rápido cambian, el volumen, la criticidad y cuánto trabajo posterior de datos existe. Una necesidad puntual puede resolverse como proyecto; una fuente que alimenta precios, riesgo, ventas u operaciones suele requerir dueño técnico continuo.

¿Se puede evaluar con un repositorio público?

Puede complementar la conversación, pero no reemplaza un caso situado. Un repositorio muestra estilo; no necesariamente muestra cómo decide ante una fuente cambiante, datos sensibles, alertas o una restricción de uso.

¿Qué pasa si la fuente deja de permitir el acceso?

La respuesta responsable es detener o rediseñar la integración y evaluar alternativas autorizadas: API, exportación, acuerdo con el proveedor o una fuente distinta. El descriptor y la operación deben prever ese escenario desde el inicio.