¿Cuáles son algunas de las habilidades de programación más esotéricas que has visto en un candidato?

Tengo dos respuestas a esta pregunta, pero ninguna se refiere a las habilidades de programación de los candidatos que he entrevistado. Comenzaré conmigo mismo:

Estuve entrevistando en un lugar que me daba problemas de programación todo el día. Dio la casualidad de que un entrevistador me pidió que resolviera un problema que me había dado el entrevistador anterior que acababa de hablarme. Me tomé un minuto para evaluar lo que debía hacer e hice lo honesto y le dije que alguien ya me había hecho esa pregunta hoy. Claramente no esperaba ese tipo de respuesta porque ahora tenía que evaluar qué hacer.

Decidió darme otra pregunta. “Si una roca estuviera en un bote en un pequeño lago, ¿subiría o bajaría el nivel del agua después de ser empujada por la borda?” Solo lo miré incrédulo. Podría protestar porque ese problema no tenía nada que ver con el trabajo que la compañía me pediría que hiciera, pero eso podría responder a cualquiera de las otras preguntas técnicas que me dieron durante el día.

Afortunadamente, era un estudiante de Física antes de cambiarme a Ciencias de la Computación, así que tengo experiencia en resolver tales problemas. Decidí intentar responder la pregunta, a pesar de que habían pasado unos 15 años desde que tuve que resolver algo como esto. Empecé a hablar sobre el problema. Suponga que la densidad de la roca es mayor que la densidad del agua para que no flote. Cuando la roca está en el bote, la cantidad de agua que desplaza es equivalente al peso de la roca. Cuando la roca está en el agua, la cantidad de agua que desplaza es equivalente al volumen de la roca. La cantidad de agua desplazada con la roca en el bote es mayor que cuando la roca está en el lago. Así, el nivel del agua del lago bajaría cuando la roca se empuja por la borda.

El entrevistador parecía impresionado de que pude resolver el problema frente a él. Luego trató de colarse en un problema de programación preguntándome si alguna vez tuve que usar un puntero vacío como argumento o un argumento de retorno a una función C. Le dije que nunca tenía que hacer eso y dejó de seguir con la pregunta. (Por supuesto, ahora sé sobre punteros opacos a estructuras que mantienen el estado, así que por favor abstente de decirme esto) No sé si estaba impresionado porque fui honesto sobre la pregunta original o si pude resolver la segunda pregunta. Tal vez mi honestidad lo conmovió tanto que tal vez no le habría importado si resolvía la segunda pregunta y, de todos modos, estaba recibiendo su aprobación. En cualquier caso, terminé consiguiendo el trabajo.

La segunda historia era de un compañero de trabajo que tenía suficiente de la carrera de ratas de programación y decidió hacer otra cosa. Decidió encontrar trabajo en Wall Street. Al parecer, los trabajos allí requerían candidatos que fueran rápidos en matemáticas. La habilidad esotérica de mi compañero de trabajo era contar cartas.

Para aquellos no iniciados en el conteo de cartas, es un método para rastrear qué cartas se han repartido de una baraja de cartas para obtener una ventaja en algunos juegos de cartas. Esto es especialmente útil en juegos de cartas de casino como el blackjack. Para más detalles, lea el libro Trayendo abajo la casa: la historia interna de seis estudiantes del MIT que tomaron Vegas por millones: Ben Mezrich: 9780743225700: Amazon.com: Libros

Entonces, mi amigo va a la costa este para entrevistarse y le preguntan qué les mostraría para demostrar su velocidad en matemáticas. Saca una baraja de cartas y anuncia que puede contar cartas. Baraja el mazo y le pide al entrevistador que elija una tarjeta y la guarde. Luego, mi compañero de trabajo da la vuelta al mazo y mira cada carta en el mazo en aproximadamente 5 segundos y dice el palo y el valor de la tarjeta del entrevistador (como una jota de picas). Probablemente hizo esto muchas veces para convencer al entrevistador de que su habilidad es genuina.

Consiguió el trabajo en el acto.

Nos dijo que después de unirse a la compañía, el entrevistador lo sentó y le pidió que le enseñara cómo contar cartas.

Entrevisté a un tipo que realmente preguntó si podía escribir sus respuestas en Brainfuck. Le habría dejado seguir adelante solo por el valor de novedad, pero el trabajo que estaba solicitando requería profundas habilidades de programación nativas, y la lista de lenguajes apropiados para demostrarlo es bastante corta.

Otro tipo en realidad enumeró 5 años de APL en su currículum. En los primeros tiempos, por lo que no fue un caso temprano en una carrera muy famosa.

Sin embargo, en general, los lenguajes de juguete arcaicos o marginales no son nada realmente especiales.

Un solicitante era un experto increíblemente detallado en programación para el procesador Cell … cinco años después de que había perdido relevancia.

Otro tipo conocía todos los códigos de operación para alguna línea de procesador Ti MIPS del que nunca había oído hablar.

Un tipo que presentó una solicitud para una empresa para la que trabajé (pero no para mi equipo) fue uno de los principales autores de la arquitectura sproc de SGI. Recibió una oferta, pero tomó una diferente en otro lugar.

Pero la habilidad más esotérica que encontré nunca fue la de un candidato, sino con el tipo al que entrevisté para mi primer trabajo de programación.

¿Conoces ese viejo chiste sobre arreglar errores con una aguja magnetizada? En realidad, tenía esa habilidad como requisito de trabajo para uno de sus primeros proyectos en su carrera, trabajando para nada menos que Freeman Dyson …

A falta de crear IA con un sándwich de queso a la parrilla o programar con hormigas y un suministro suficiente de queso, no se vuelve mucho más esotérico que eso.

No es realmente un candidato, sino un compañero de trabajo.

Llevo más de 10 años trabajando en una empresa de telecomunicaciones y durante los primeros cinco trabajé en el departamento de TI prepago. Y todo dependía de un sistema, construido en Java, que se conectaba a una plataforma prepaga e hacía todo tipo de cosas cruciales, como aprovisionamiento, recarga, etc.

Entonces escuché esta historia (que luego se confirmó): cuando esta compañía estaba a punto de lanzarse, no teníamos (por supuesto) ningún sistema del que hablar, pero ya sabíamos qué plataforma prepaga usaríamos. Entonces, este tipo (solo) tuvo la tarea de construir un middleware para que todos los demás sistemas de TI pudieran interactuar con esa plataforma. Entonces comenzó a leer un poco sobre la documentación y escribió algunas líneas de código. En un momento le dijeron que no obtendría una plataforma de prueba, lo que básicamente significa que tendría que codificar “a ciegas” sin poder realizar incluso las pruebas más básicas. Y así lo hizo. Pasé 6 meses codificando a ese monstruo, solo, solo con la documentación para ayudarlo.

Entonces llega la plataforma. Hace una configuración básica (IP, puertos, etc.), la ejecuta y … ¡bam! – Se conecta por primera vez. Todo parece funcionar. No solo se conectó, sino que todas las operaciones básicas (que luego usaría en mi trabajo todos los días durante cinco años), también funcionaron. Este tipo escribió una aplicación middlware humongua sin acceso a lo que estaba integrando, y la primera vez que se ejecutó, funcionó a la perfección. Eso me voló la cabeza.

No era un candidato (un compañero de trabajo) y no programaba per se, pero trabajé con un tipo que podía y regularmente depuraba el firmware ROM’d en MCU cuando obtuvimos el primer Silicon (Motorola, Tokyo Design Ops) bajo un microscopio. Cada vez que un cliente cambiaba un proveedor por nosotros (digamos que Sony o Canon decidieron usar nuestro equipo frente a otro como el H16), era casi seguro que el producto que se lanzó a la fabricación fue parcheado después de haber dejado las manos del desarrollador del firmware del cliente. , por lo que no teníamos acceso al código real (ensamblado) que realmente se estaba ejecutando. Cada vez que esto se convirtiera en un problema, sacaría la tapa del chip del competidor en el último lanzamiento del producto del cliente (más bien disolver, en realidad, un chip suele ser un contenedor sellado), ponerlo bajo el microscopio y mirar lo que realmente era corriendo. Tenía aproximadamente 25,000 veces más paciencia que yo …

Entrevisté a un tipo que podía hacer aritmética (sumar, restar, multiplicar y dividir) en octal, en su cabeza, en cuantos de 32 bits y en matemática MMU en su cabeza. Puedo hacer hechizos en mi cabeza, pero no octal, y esto fue fascinante (resultó que había pasado un montón de tiempo en los sistemas DEC-10 y DEC-20 como estudiante universitario, lo que al menos tenía sentido , pero no disminuyó la habilidad).

La parte matemática de MMU fue alucinante. Tomaría una dirección virtual local y le diría de memoria del último estado de la MMU dónde estaría en la memoria física. Eso fue mucho más que impresionante.

No me impresiona fácilmente y esto me dejó con la mandíbula en el suelo, y una llamada de pánico a RR.HH. para que NO deje que este tipo se escape …

¿Candidato? Realmente no. Una vez vi a un codificador que escribió todo su C ++ usando diseños lógicos en un archivo. Había miles de líneas de código y cientos de variables. No usó ningún comentario. Debido a lo lógicamente que lo había presentado, pudo ajustar el código después de estar alejado de él durante 5 años. Tenía el código dividido en secciones en su mente y fue capaz de continuar donde lo dejó como si fuera una siesta.

Una vez tuve una tarea de prueba para un puesto de analista de datos. Esa tarea de prueba, como todas las demás tareas de prueba para mi equipo, tenía que estar codificada. El análisis en sí no fue especialmente complejo. Estaba principalmente interesado en saber que el candidato tenía la capacidad de ejecutarlo programáticamente, pero la parte realmente importante era el enfoque estadístico del problema.

Al igual que con todas las tareas de prueba de análisis de datos, había un conjunto de datos, algunas instrucciones y algunas preguntas que quería ver respondidas.

Uno de los candidatos me envió lo que solo puedo describir como algo muy cercano a un artículo científico completo. Las docenas de páginas o más se llenaron de análisis, tablas, diagramas y anotaciones. Las tramas fueron simplemente increíbles en complejidad y profundidad. ¡El código que produjo el documento fue mucho mejor que el que producen la mayoría de los analistas cuando se esfuerzan mucho!

No he visto tanta calidad desde entonces. No en los papeles que leo, las tareas de prueba que recibí. Puedo garantizar que ninguno de los trabajos que realicé estuvo ni siquiera cerca del nivel de ese documento.

Desafortunadamente ese papel brillante hizo todo excepto responder las preguntas. Hasta el día de hoy no sé por qué alguien haría tanto esfuerzo para no completar una tarea.

Tengo un poco de experiencia programando en Quipper, un dialecto de Haskell para manejar computadoras cuánticas. También QScript, el lenguaje de Google Quantum Computing Playground (y tengo varios programas publicados en mi perfil allí).

Según las predicciones más optimistas, pasarán alrededor de 20 años hasta que comience a tener sentido poner eso en mi CV, LOL 😀