Un principiante creó un bot en Go para preparar entrevistas: voz, 860 preguntas y 25–35 MB de memoria

Una situación conocida: has leído una docena de artículos sobre el runtime de Go, tienes en la cabeza una mezcla confusa de slices, el planificador GMP y el análisis de escape, y en la entrevista se te traba la lengua. El autor de este proyecto trabaja de día en un taller mecánico y estudia desarrollo backend por las noches. Resolvió el problema con código: creó un bot de Telegram que hace preguntas técnicas, escucha respuestas de voz y las evalúa sin concesiones.

Por qué usar voz y por qué descartar Whisper

La idea del proyecto es que en una entrevista nadie pide un ensayo: hay que hablar. Por eso, el bot acepta específicamente mensajes de voz. El primer intento con Whisper en local fracasó: en un VPS barato sin GPU, cada mensaje de audio llevaba el uso de la CPU al 100%.

El autor pasó a Deepgram en la nube, con el modelo Nova-2. Un mensaje de voz de Telegram en formato OGG/Opus se procesa en menos de un segundo. La jerga técnica rusa, con términos como «goroutines», «mutex» o «genéricos», no se convierte en un galimatías, algo fundamental para un bot así. La conclusión práctica es sencilla: si no tienes GPU y el proyecto es pequeño, alojar tu propio sistema de reconocimiento de voz suele salir más caro que usar una API ya disponible si cuentas el tiempo y los quebraderos de cabeza.

Cómo evitar que el modelo te dé siempre la razón

El principal problema de los evaluadores basados en LLM es la adulación. Pregunta «¿Qué te parece mi respuesta?» y casi con seguridad recibirás un «¡Muy bien, excelente!», aunque la respuesta haya sido floja. El autor reunió una base de 860 preguntas sobre 85 temas y añadió a cada una criterios de referencia, key_points. El prompt obliga a DeepSeek, que utiliza a través de la API de Groq Cloud, a recorrer la lista: comprobar cada criterio, poner una nota del 1 al 10, enumerar las omisiones y ofrecer un análisis breve y exigente, sin cumplidos.

Un ejemplo del proyecto: el candidato dice que «un slice duplica su tamaño cuando se queda sin capacidad». Pero no menciona el umbral de 256 elementos ni la nueva fórmula introducida en Go 1.18+. Sin una lista de criterios, el modelo podría dar fácilmente esa respuesta por válida. Con ella, señala exactamente qué ha faltado.

La técnica sirve para muchos otros casos. No pidas al modelo que «evalúe»: dale una rúbrica con puntos obligatorios. Lo mismo funciona para comprobar automáticamente revisiones de código, respuestas de soporte o pruebas técnicas.

Repaso espaciado, simulacros de entrevista y tropiezos

Memorizar preguntas una tras otra no sirve de mucho, así que el autor añadió repetición espaciada. En Redis se crea una cola de sesión para cada usuario. Una respuesta con 8–10 puntos envía la pregunta al final de la cola. Si la nota es inferior a 6, la pregunta reaparece al cabo de un par de pasos. Todos los intentos se guardan en PostgreSQL y se utilizan para elaborar estadísticas. También hay un modo de simulación de entrevistas: eliges un nivel, desde becario hasta sénior, recibes 10 preguntas con preguntas de seguimiento sobre la marcha y obtienes un veredicto final de Hire o No Hire con un análisis de los errores.

Los tropiezos fueron los habituales en cualquier bot de Telegram:

• Marcado HTML. Si el modelo devuelve código sin comillas invertidas u omite una etiqueta de cierre, Telegram rechaza el mensaje. El autor escribió un sanitizador que detecta código Go mediante palabras clave y sintaxis (package, func, :=) y lo envuelve automáticamente en etiquetas pre/code, escapando los caracteres necesarios.
• Pulsaciones dobles. Pulsar rápidamente un botón inline genera dos callbacks seguidos, lo que provocaba una condición de carrera en Redis con dos sesiones en paralelo. Se soluciona desactivando los botones mediante EditReplyMarkup antes de realizar consultas pesadas a la base de datos.
• Seguridad del despliegue. Los contenedores se ejecutan con un usuario específico, appuser, en lugar de root. En docker-compose.prod.yml están activados read_only: true y cap_drop: ALL, y los directorios del sistema se montan en tmpfs.

Qué puedes aprovechar de este proyecto

La pila tecnológica incluye Go 1.23, telebot.v3, PostgreSQL 16 a través de pgx/v5, Redis 7 y Docker Compose, con una estructura basada en Clean Architecture. Según el autor, en producción el bot consume 25–35 MB de memoria, arranca en una fracción de segundo y funciona en un servidor de 200 rublos al mes. Para un servicio ligero que se dedica sobre todo a llamar a API externas, es un buen argumento a favor de Go.

También hay limitaciones. Es el proyecto personal de un principiante, y el propio autor pide a desarrolladores con experiencia que revisen el código y la arquitectura. No hay datos sobre hasta qué punto las notas del modelo coinciden con las de un entrevistador humano. Tampoco se aportan métricas de calidad del reconocimiento de voz ni del análisis de las respuestas, de modo que su «exigencia» solo puede juzgarse por la descripción del prompt.

Aun así, el artículo resulta útil como recopilación de soluciones prácticas. Para la voz, utiliza reconocimiento en la nube si no tienes GPU. Para obtener una evaluación sincera de un LLM, dale una lista de criterios en vez de pedirle su opinión. En un bot de Telegram, protégete desde el principio frente a las pulsaciones dobles y el marcado HTML defectuoso. El código fuente es abierto: github.com/powood/Tg_GO_Mentor, y el bot está disponible como @go_SikkiMentor_bot.