Cómo entregar una prueba técnica en GitHub: README, pruebas y decisiones de alcance
Quick Overview
Guía de entrega con un laboratorio original de inventario: el archivo fixtures/events.json existe localmente pero queda fuera del primer commit por una regla de exclusión. El clon falla con salida2; una revisión corregida incluye el dato y produce A=5/B=1 y diez tests correctos en un clon nuevo. Registra hashes, archivos seguidos y límites de alcance. Git local y CPython3.12.14; sin creación de repositorio GitHub, prueba de permisos remotos ni Actions.
La aplicación funciona en tu carpeta y los tests pasan. Clonas el repositorio en otro directorio, ejecutas el mismo comando y falta el archivo de entrada. Los datos necesarios nunca formaron parte del commit, aunque estuvieran presentes en tu carpeta.
Para entregar una prueba técnica en GitHub, verifica lo que recibe la otra persona: archivos seguidos por Git, instrucciones reproducibles, resultados esperados y límites de lo implementado. Este artículo usa un mini proyecto descargable con una entrega incorrecta y otra corregida. Puedes preparar la defensa con las preguntas Software Engineer de PracHub.
Hechos oficiales: GitHub documenta README, archivos ignorados y detección de secretos; Python documenta el runner de pruebas. Informes de candidatos: los registros de PracHub sirven para practicar, sin predecir una evaluación. Observaciones propias: ejecutamos dos clones de un repositorio Git local. No creamos un repositorio GitHub ni probamos sus permisos, Actions o recepción por un evaluador. Confirma canal, privacidad, herramientas y plazo en tu invitación antes de enviar la entrega.
Confirma qué significa entregar en tu invitación
Un enlace a GitHub puede referirse a un repositorio, una rama, un commit o un pull request. No son objetos intercambiables. Identifica cuál pide el enunciado, si debes conservar un repositorio inicial y cómo se concede acceso. Si también existe un formulario de entrega, confirma si el enlace debe enviarse allí.
Respeta la visibilidad y los permisos que exige la invitación. Una tarea puede contener material que la empresa no autoriza a redistribuir. Comprueba las instrucciones antes de cambiar visibilidad o publicar datos, y utiliza entradas sintéticas en tus ejemplos. Este artículo no proporciona una política común a todos los procesos.
Identifica la revisión que vas a entregar para que sus resultados puedan reproducirse. Si entregas una rama que continúa cambiando, el enlace por sí solo no identifica qué versión comprobaste. Conserva el hash de la revisión y el recibo del canal indicado. Un commit local no demuestra que otra persona tenga acceso al repositorio remoto.
Confirma también el uso de documentación, herramientas de IA y código ajeno. Si se permite asistencia, mantén las atribuciones solicitadas y prepara una explicación de las decisiones. Que GitHub pueda alojar el proyecto no establece qué ayudas admite una evaluación concreta.
Reproduce el fallo que tu carpeta local oculta
Nuestro proyecto lee un JSON con stock A igual a 3 y B igual a 1. Procesa tres eventos: e1 retira dos unidades de A, e2 añade cuatro y el último repite e1 con el mismo contenido. La salida correcta es A igual a 5, B igual a 1, dos eventos aplicados y un duplicado omitido.
El archivo fixtures/events.json existe en la carpeta del autor. En la primera revisión añadimos por error fixtures/ a .gitignore. El comando local sigue funcionando, pero Git no incorpora ese archivo nuevo al commit. Al clonar esa revisión, el programa no encuentra la entrada y termina con código 2.
La corrección elimina esa regla e incorpora los datos sintéticos. Creamos otro commit, lo clonamos en un directorio distinto y ejecutamos las órdenes del README. La salida coincide y los diez tests pasan. delivery-checks.json conserva ambos hashes, los comandos y sus resultados ejecutados.
| Observación ejecutada | Revisión incorrecta | Revisión corregida |
|---|---|---|
| Archivo en carpeta del autor | Existe | Existe |
| Archivo seguido por Git | Falta | Incluido |
| CLI desde clon limpio | Código 2; error de entrada | Código 0; A=5 y B=1 |
| Tests desde clon corregido | No ejecutados | Diez pasan |
La comparación distingue una solución local de una entrega reproducible. No prueba otros sistemas operativos, una versión diferente de Python ni una instalación desde Internet. La ejecución registrada utiliza CPython 3.12.14 y Git local, sin dependencias externas.
Haz que el README permita reconocer el resultado correcto
Documentación oficial: GitHub presenta el README como un lugar para explicar el proyecto y cómo usarlo. En una entrega, traduce esa orientación en órdenes concretas y resultados observables. Un comando sin indicar desde dónde ejecutarlo puede funcionar en un directorio y fallar en otro.
El README del ejemplo declara Python 3.9 o posterior, ausencia de paquetes externos y ejecución desde la raíz. La versión realmente comprobada se registra aparte; no afirmamos haber probado cada versión admitida. Las dos órdenes principales son:
python3 inventory.py fixtures/events.json
python3 -m unittest -v
Explica qué debe verse: JSON con A=5, B=1, applied=2 y duplicates=1; después diez tests correctos. Un evaluador puede así distinguir un programa vacío, una ejecución parcial o una ruta equivocada sin reconstruir tu intención a partir del código.
Documenta también el fallo esperado. El CLI devuelve 2 y un mensaje en stderr ante un archivo ausente, JSON inválido o una infracción del contrato. No produce un JSON de éxito en esos casos. El programa no modifica el archivo original ni conserva estado tras finalizar.
Si tu prueba necesita instalación, base de datos o variables, explica esos pasos con valores de ejemplo seguros. No añadas instrucciones para servicios que no utilizas. En nuestro proyecto, .env.example aclara que no hacen falta credenciales ni variables; no oculta una configuración privada necesaria para arrancar.
Relaciona los tests con las decisiones de alcance
Documentación oficial: unittest permite organizar y ejecutar pruebas de Python. El runner no decide qué comportamiento importa. Elegimos diez tests que cubren la conciliación, preservación de entrada, errores del contrato y salidas del CLI; el número no representa un umbral de contratación.
El replay idéntico debe omitirse. Un mismo identificador con otro delta debe rechazarse. Un SKU desconocido y un delta booleano también fallan. Una retirada que deja stock negativo se rechaza en ese punto, aunque una reposición posterior pudiera compensarla: el orden del archivo forma parte de nuestro contrato.
Esas reglas deben aparecer en la explicación y en las pruebas. Si decidieras permitir stock negativo temporal, tendrías que cambiar la decisión, el código y su test. Un comentario como «mejorar validaciones» no permite identificar qué comportamiento se ha implementado realmente.
Las comprobaciones del CLI observan código de salida, stdout y stderr. Complementan las pruebas de la función: una función correcta no garantiza que el comando de la entrega lea el archivo adecuado o informe un fallo de manera reconocible.
No uses una captura verde como única prueba. Conserva el comando, la revisión y la salida que produjeron ese resultado. Tampoco añadas un porcentaje de cobertura que no has medido; aun medido, necesitaría una explicación de los riesgos que los tests sí ejercitan.
Comprueba qué archivos forman parte de la revisión
Documentación oficial: las reglas de archivos ignorados ayudan a excluir archivos de los commits, pero no dejan de seguir automáticamente uno que ya estaba incorporado. En nuestro fallo, la entrada era nueva: la regla impedía añadirla. Identifica cuál de esas situaciones estás investigando antes de cambiar la configuración.
La revisión corregida sigue siete archivos: README, programa, tests, reglas de exclusión, ejemplo de configuración sin secretos, decisiones y datos sintéticos. El clon contiene esos mismos bytes. Tras ejecutar programa y pruebas, git status --porcelain queda vacío; las cachés de Python están excluidas.
Un estado limpio tampoco significa que tu proyecto sea correcto. Solo describe la relación observada entre esa carpeta y Git. En el primer caso, la carpeta podía parecer preparada mientras el archivo ignorado permanecía fuera del commit. Por eso combinamos lista de archivos, clon y ejecución.
Revisa si una imagen, una migración o un archivo de datos depende de una ruta local fuera del commit. Si el proyecto necesita una imagen o una migración, debe formar parte del mecanismo documentado de preparación. Una ruta que apunta a tu escritorio no es un recurso portable para el evaluador.
Trata los secretos y la privacidad como requisitos de la entrega
Documentación oficial: GitHub describe la detección de secretos como una protección frente a credenciales expuestas, incluida la revisión del historial. La disponibilidad y la configuración de funciones dependen del repositorio. No afirmamos haber ejecutado un escaneo GitHub sobre este laboratorio.
No incluyas contraseñas, tokens, cookies ni datos personales para facilitar la demostración. Usa datos sintéticos y describe cómo proporcionar una configuración cuando sea necesaria. Una plantilla debe mostrar nombres y formatos, sin contener una credencial que haya funcionado realmente.
Añadir .env a .gitignore no revoca un secreto ya publicado ni borra su historial. Si detectas una exposición real, atiende la credencial afectada con el responsable y el procedimiento correspondiente; cambiar únicamente el último archivo no demuestra que el acceso anterior haya desaparecido.
Nuestro paquete no contiene secretos y no utiliza autenticación. Esa afirmación describe los archivos creados para el ejercicio, no una certificación de seguridad ni una prueba de permisos remotos. No confundas la privacidad de un repositorio con autorización para compartir material de la evaluación.
Vincula la evidencia al commit que vas a enviar
La revisión verificada comienza por 88837ba; el hash completo está en COMMIT.txt. En el laboratorio comprobamos que HEAD del clon coincide con ese hash antes de ejecutar. Los resultados corresponden así a una revisión identificable, en lugar de una mezcla entre archivos guardados y cambios pendientes.
El archivo delivery-checks.json conserva el hash defectuoso y el corregido, los comandos, salidas y lista seguida por Git. Es un recibo externo del experimento. No forma parte del propio commit probado, igual que COMMIT.txt; documentar esa distinción evita fingir que un commit contiene una evidencia generada después de crearlo.
El ZIP portable incorpora los siete archivos seguidos y esos dos recibos. No incluye .git, credenciales ni una dirección de repositorio remoto. Puedes ejecutar el proyecto descomprimido, pero repetir la historia de commits requeriría crear tu propio repositorio; el paquete no pretende ser una copia del historial.
Para una entrega real, verifica el enlace y el acceso mediante el mecanismo permitido. Anota a quién corresponde revisar y qué canal confirma la recepción. No consideres que el evaluador recibió la prueba solo porque tú puedes abrir tu propia cuenta.
Defiende una decisión sin convertir una limitación en una función
Nuestro registro de alcance elige JSON local y estado en memoria para concentrarse en la entrega. La deduplicación por identificador dura una ejecución. No implementa reservas, backorders, retención durable, varios procesos ni un servicio de inventario desplegado.
En una conversación, puedes explicar por qué esa frontera hizo posible una reproducción pequeña. También debes aceptar qué requisito la invalidaría. Si el enunciado exige reanudar después de un reinicio, la tabla en memoria no cumple; escribir «añadir persistencia después» no transforma ese requisito obligatorio en opcional.
Distingue un requisito no implementado de una ampliación propuesta. Para cada pendiente, indica la consecuencia y el siguiente cambio que comprobarías. «No admite escrituras concurrentes» permite discutir una prueba y un almacenamiento; «es escalable» sin otra evidencia oculta una garantía que todavía no has construido.
Estas preguntas verificadas sirven para ensayar cambios de contrato y su defensa. Son registros de práctica, no tareas anunciadas para un proceso concreto.
| Pregunta PracHub verificada | Decisión que puedes defender |
|---|---|
| Implement inventory allocation with backorders | Qué cambia si la falta de stock genera una asignación pendiente. |
| Design scalable inventory system and avoid races | Por qué un proceso secuencial no demuestra ausencia de carreras. |
| Design an inventory system | Dónde termina el CLI y empieza un servicio con almacenamiento. |
| Design matrix-operations HTTP service and test strategy | Qué evidencia añadirías al convertir el programa en una API. |
| Design an Extensible Expense Rule Engine | Cómo documentar una nueva regla sin ocultarla entre detalles del framework. |
Continúa con las preguntas Software Engineer. Elige una modificación, escribe qué resultado cambiaría y qué test lo demostraría. Antes de enviar tu propia prueba, vuelve al commit exacto y sigue sus instrucciones desde otra carpeta: la entrega debe sostener la explicación que has preparado.
Comments (0)