Primera entrevista técnica junior: qué practicar y cómo explicar lo que aún no sabes

Tu función devuelve la etiqueta correcta y el test está verde. Sin embargo, también ha modificado la lista que recibió. En una primera entrevista técnica junior, encontrar esa diferencia y explicarla con una prueba permite mostrar tu razonamiento con una entrada, una salida y el estado que debía conservarse.

Para prepararte, confirma el formato y las herramientas permitidas de tu evaluación y practica un ciclo pequeño: predecir una salida, seguir los datos, corregir el fallo y defender un test. Aquí trabajarás con un laboratorio original de tareas y etiquetas. Incluye un ejercicio descargable y preguntas verificadas para continuar en la sección de Software Engineer de PracHub.

Hechos oficiales: las fuentes de Python y GitHub respaldan los mecanismos que se citan. Informes de candidatos: los registros de práctica de PracHub no predicen tu próxima entrevista. Propuestas propias: el ejercicio, las respuestas ilustrativas y el criterio de repaso son originales. No tenemos informes del mismo proceso que permitan afirmar un formato, una duración o un nivel exigido por todas las empresas.

Averigua qué tendrás que hacer antes de ampliar el temario

La invitación y la persona responsable de la selección pueden aclarar si vas a escribir código, depurar un repositorio, explicar un proyecto o realizar una entrega en casa. Comprueba lenguaje, entorno, materiales permitidos y forma de ejecutar o entregar. Una descripción vaga como «entrevista técnica» no resuelve esas preguntas.

Si falta información, pide una aclaración concreta: «¿Trabajaremos sobre código existente o empezaré con un editor vacío?». Esa respuesta cambia la práctica útil. Para leer un repositorio necesitas localizar el punto de entrada y reproducir un fallo; para un ejercicio aislado necesitas interpretar restricciones y construir una solución.

Esta recomendación no describe una ronda observada en una empresa. Te ayuda a reducir la incertidumbre de tu propia invitación. No deduzcas que tendrás una prueba SQL porque aparece una base de datos en la oferta, ni que no habrá código porque el puesto se presenta como junior.

Después elige una tarea que permita observar tu dificultad actual. Si puedes escribir un bucle pero no explicar por qué cambia una entrada, repetir sintaxis no resuelve el bloqueo. Nuestro laboratorio sirve para observar precisamente esa diferencia; no sustituye un temario ajustado a la vacante.

Escribe el contrato antes de ejecutar el ejemplo

Tenemos dos tareas: a, con la etiqueta draft, y b, sin etiquetas. La función debe devolver una nueva colección que añada review a la tarea a. La colección original debe conservarse. También queremos que modificar posteriormente las etiquetas devueltas de b no cambie las etiquetas de b en la entrada.

El ejercicio supone identificadores únicos y filas con dos campos: id, una cadena, y tags, una lista de cadenas. Si no existe el identificador solicitado, se lanza KeyError. Estos límites evitan convertir una práctica de alias en un validador de cualquier JSON posible. No los atribuyas a una regla general de Python.

Antes de leer la corrección, escribe dos expectativas: la salida de a será ['draft', 'review'] y la entrada de a seguirá siendo ['draft']. Son observaciones diferentes. Si solo miras la primera, puedes aceptar una función que incumple el contrato del llamador.

También distingue «nuevo resultado» de «copia independiente». Crear otra lista exterior no demuestra que sus elementos o sus listas interiores sean distintos. Vas a comprobar qué sigue compartido: esa referencia explica por qué el llamador ve un cambio que no pidió.

Predice por qué una copia superficial no basta

Esta versión parece razonable porque llama a copy() antes de añadir la etiqueta. Sigue la referencia que usa cada línea, sin dar por hecho que «copiar» significa duplicarlo todo.

def broken_tag(tasks, task_id, tag):
    result = tasks.copy()
    for task in result:
        if task['id'] == task_id:
            task['tags'].append(tag)
            return result
    raise KeyError(task_id)

Hecho documentado: la documentación de copy distingue asignación, copia superficial y copia profunda. La asignación enlaza un nombre con un objeto; una copia superficial construye un contenedor nuevo que conserva referencias a los elementos. El tutorial de listas describe list.copy() como una copia superficial.

En nuestro caso, result y tasks son listas exteriores diferentes, pero ambas apuntan a los mismos diccionarios. El diccionario de a apunta a una sola lista de etiquetas. Al hacer append, la función modifica esa lista compartida. Tanto la salida como la entrada muestran ahora draft y review.

Una explicación útil sería: «La copia solo separa la colección exterior. La mutación ocurre en una lista interior que sigue compartida». No necesitas recitar direcciones de memoria. Dibuja las referencias o comprueba identidades con is, y relaciona ese dato con el cambio observable.

Corrige solo lo que exige el modelo de datos

La solución del laboratorio crea nuevos diccionarios y nuevas listas de etiquetas para todas las tareas. Las cadenas pueden compartirse porque no las modificamos. Copiamos también b, aunque no sea la tarea seleccionada, porque el contrato exige independencia ante una modificación posterior del resultado.

def tag_task(tasks, task_id, tag):
    result = [
        {'id': task['id'], 'tags': task['tags'].copy()}
        for task in tasks
    ]
    for task in result:
        if task['id'] == task_id:
            task['tags'].append(tag)
            return result
    raise KeyError(task_id)

No presentes esta comprensión como una copia universal. Si mañana aparece un campo metadata con más listas, este código lo descartaría; si las etiquetas pasan a ser objetos mutables, copiar su lista exterior no los aísla. La corrección es válida para la estructura declarada, y debe revisarse cuando cambie.

El laboratorio también comprueba que deepcopy aísla estos datos ordinarios. Eso permite comparar otra opción, pero no prueba que cualquier conexión, archivo o clase se pueda duplicar de una manera útil. Elegir una copia profunda sin conocer el modelo puede ocultar una pregunta pendiente sobre qué debe compartirse.

En la entrevista, defiende la relación entre requisito y cambio. «Copio cada lista de etiquetas porque podrá modificarse por separado» es más preciso que «uso deepcopy porque es más seguro». Si el requisito solo pidiera leer datos, quizá no necesitarías copiar nada.

Elige una prueba que detecte el fallo original

El archivo results.json registra 18 comprobaciones ejecutadas con Python 3.12.14. Algunas documentan el defecto y otras verifican la corrección. No son 18 escenarios de producción: inspeccionan listas, diccionarios e identidades dentro de un proceso, sin red, base de datos ni framework.

La primera fila no diferencia las implementaciones. La segunda detecta el incumplimiento que queríamos reparar. El archivo de resultados incluye expresamente una aserción del retorno que pasa con la función incorrecta: muestra por qué un test verde puede ser insuficiente sin afirmar que los tests sean inútiles.

Conserva una copia del estado previo para comparar valores y comprueba una modificación posterior del resultado. La primera prueba observa lo ocurrido durante la llamada; la segunda observa el aislamiento que prometiste después. Comprobar únicamente que las listas exteriores son distintas no cubre ninguna de esas dos garantías completas.

Añade las fronteras declaradas: identificador ausente, entrada vacía y repetición desde la entrada original. La función lanza KeyError en los dos primeros casos y conserva los datos. La repetición empieza otra vez desde draft; no acumula cambios ocultos entre llamadas.

Explica el coste con la cantidad de datos que copias

Si hay n tareas y t etiquetas en total, la corrección recorre las tareas y copia sus listas de etiquetas. Para este modelo, el trabajo crece con n más t, y el almacenamiento adicional también. Decir solamente «O(n)» oculta que una tarea puede contener muchas etiquetas.

Esta descripción cuenta referencias y elementos del modelo; no es una medición de latencia. El laboratorio no demuestra cuánto tardará con un millón de tareas ni compara implementaciones en distintos intérpretes. No añadas un tiempo inventado para que la explicación parezca más técnica.

Si te piden reducir copias, vuelve al requisito. Compartir las tareas no seleccionadas podría ahorrar trabajo, pero perdería la independencia posterior que exigimos para b. Otra alternativa sería devolver datos inmutables o documentar una vista compartida. Ambas cambiarían el contrato y necesitarían otras pruebas.

Puedes proponer esa alternativa aunque todavía necesites comprobar cómo implementarla. Explica qué comportamiento conservarías, cuál cambiarías y qué ejemplo usarías para comprobarlo. El razonamiento sigue siendo revisable aunque todavía no hayas elegido una biblioteca.

Responde lo que no sabes con una frontera verificable

Una respuesta honesta identifica qué parte dominas, qué falta y cómo lo comprobarías. Por ejemplo, ante «¿copiarías también una conexión a la base de datos?», puedes decir: «He probado listas y diccionarios de este ejercicio. No he verificado el comportamiento de una conexión. Revisaría el ciclo de vida y la API del controlador antes de proponer una copia».

Es una respuesta ilustrativa, no el testimonio de un candidato contratado. Tampoco garantiza una valoración positiva. Su utilidad consiste en impedir que una observación local se convierta en una promesa sobre objetos que nunca has probado.

Si no recuerdas una función, separa sintaxis y enfoque: «Quiero construir una lista de etiquetas independiente; no recuerdo el nombre exacto de este método. ¿Puedo consultar la documentación o prefieres que lo escriba con un bucle?». La consulta depende de las reglas de la evaluación. No uses una herramienta sin confirmar que está permitida.

Cuando recibas una pista o una aclaración, vuelve a explicar qué cambió. Si necesitaste que alguien señalara la lista interior, anótalo en el repaso. Describir el ejercicio como resuelto sin ayuda borraría justo la información que necesitas para elegir la siguiente práctica.

Presenta un proyecto con pruebas de tu contribución

Elige una decisión pequeña que puedas mostrar en tu propio proyecto: un fallo reproducido, una validación añadida o un test que antes faltaba. Explica la situación, tu intervención y la evidencia disponible. Si trabajaste en equipo, identifica la parte compartida y la parte que escribiste tú.

Documentación oficial: GitHub describe el README de un repositorio como un lugar para orientar sobre el proyecto y su uso. Para preparar tu explicación, añade el comando real de ejecución, la entrada del fallo y la limitación conocida. Es una propuesta para tu entrega, no una lista oficial de criterios de contratación.

Una evidencia del laboratorio sería el código anterior junto con el estado de entrada antes y después. En tu proyecto usa tus resultados reales. No transformes «el test pasa en mi equipo» en «reduje errores en producción», ni atribuyas una mejora de rendimiento si no has conservado una medición comparable.

El descargable incluye una plantilla para ordenar esas pruebas. Si falta un enlace al cambio, un comando reproducible o un resultado, marca ese dato como pendiente. Una limitación explícita permite preparar una comprobación siguiente; rellenarla con una cifra aproximada inventada hace que la historia sea difícil de defender.

Cambia la siguiente práctica según el bloqueo observado

Si fallaste al predecir la salida, dibuja referencias antes de ejecutar otra variante. Si detectaste la mutación pero no elegiste una prueba, escribe primero el estado que debe conservarse. Si el código funciona y la explicación se vuelve confusa, practica la secuencia contrato, referencia compartida y evidencia de la corrección.

Estas cinco preguntas verificadas permiten variar el ejercicio. Sus títulos completos identifican registros de práctica; no representan un temario junior universal ni una predicción de preguntas por empresa.

Continúa en las preguntas Software Engineer con una entrada distinta. Guarda qué esperabas, qué ocurrió y qué ayuda necesitaste. Esa evidencia permite decidir qué practicar después y explicar lo que sabes sin ocultar lo que todavía necesitas verificar.

Sources and Further Reading

• Python: estructuras de datos y métodos de listas
• Python: copias superficiales y profundas
• GitHub Docs: acerca del README de un repositorio