"Desarrollador senior" entrevistado por preguntas junior, o: ¿dónde está la carne? [cerrado]

Desarrollador senior son solo un par de palabras, pueden significar cualquier cosa dependiendo de lo que la empresa quiera que signifiquen. Ignórelos excepto como una pauta general y concéntrese en lo que se paga. Esa es la verdadera prueba de lo que están buscando.

He trabajado para una empresa en la que todos parecían ser desarrolladores senior o ingenieros senior, excepto las señoras de la limpieza y los conductores.

Dos cosas aquí.

1. Te sorprendería saber cuántos desarrolladores "senior" no pueden hacer ni siquiera lo básico. En mi última gran ronda de reclutamiento de desarrollo, tal vez el 75 % del grupo falló en la primera entrevista real, y comenzamos a generar entusiasmo, no porque fuera un gran indicador positivo, sino porque atrapó a muchos que ni siquiera podían hacer eso. Muchos desarrolladores senior se vuelven así al estar allí durante varios años, pero no han progresado en sus habilidades, por lo que estas preguntas son necesarias.
2. Habiendo dicho eso, ¿qué es un "mayor" de todos modos? No diría automáticamente que las habilidades tecnológicas son la diferencia de un rol junior, pero lo que esperaría son habilidades más blandas: ser capaz de administrar su tiempo (y tal vez el de un junior); ser capaz de ver a través de una tarea/historia con el negocio de principio a fin y tratar (o escalar) los problemas según corresponda; y poder ser mentor de un joven en lo anterior.

Lo que también esperaría es un nivel diferente de discusión en torno a las preguntas que menciona, tal vez algunas opiniones más sobre por qué son buenas/malas/feas y conducen a historias de guerra que me dan confianza en sus habilidades en lugar de una respuesta de libro de texto.

Esas no son realmente "preguntas de Java", son "preguntas de OOP" y "cualquier pregunta de lenguaje de programación". Entonces, si quiere decir que sabía las respuestas a estas preguntas al trabajar con algún otro lenguaje OOP, entonces, bueno, bien por usted.

Creo que preguntas como esa, en lugar de preguntas sobre los detalles de la sintaxis de Java o la API, son una buena señal. Da a entender que la empresa se da cuenta de que la marca de un buen desarrollador de software es que comprende conceptos que trascienden lenguajes específicos. Me preocuparía si una empresa me hiciera preguntas como "¿cuál es el tercer parámetro de la función foo en la clase de barra". Si no lo recuerdo, puedo buscarlo en un minuto o dos. Pero si no sé qué es la recolección de basura, es una larga historia.

Dale al entrevistador un poco de holgura. Llegar a las preguntas de la entrevista es un asunto complicado. ¿Tu problema es que las preguntas son demasiado fáciles? Si es así, bien por ti. Esas preguntas dejarían perplejo a un buen porcentaje de desarrolladores con los que me he encontrado. Si puede responderlas todas correctamente, eso probablemente lo coloque en al menos el 50% superior, tal vez mejor. Desea preguntas que sean lo suficientemente difíciles como para poder distinguir a los candidatos, pero a menos que les esté dando una prueba de 20 páginas, no desea eliminar a un candidato porque no sabía la respuesta a una pregunta difícil. Quizá si le hubieras pedido diez más, los habría conseguido todos. Puede saber mucho no solo de la respuesta, sino también de cómo responde el candidato. Obviamente, si no tiene idea, eso es un inconveniente. Pero si recita una definición de libro de texto, eso puede indicar que conoce las palabras de moda, pero en realidad no sabe cómo funciona todo. (Una vez me quemé cuando contraté a un tipo que podía recitar todo tipo de términos técnicos y definiciones en la entrevista, pero que resultó no ser capaz de completar las tareas más simples. Sí, podía nombrar todos los marcos y idiomas y productos, pero cuando le pedimos que escribiera una pantalla con dos campos de entrada y la guardara en una base de datos, no tenía ni idea). Me impresiona cuando alguien puede explicar un concepto con claridad y confianza.

Ah, y preguntar por hechos oscuros me parece bastante inútil. Hace años, un entrevistador me preguntó qué datos había en un inodo de Unix. Lo sabía, de hecho, lo sabía mejor que él, pensó que el nombre del archivo estaba en un inodo, pero si no lo hubiera sabido, ¿y qué? Solo lo supe porque un día leí sobre eso. No creo que haya usado ese conocimiento al escribir un programa.