Es lo principal que busco si le pido a alguien que escriba el código durante una entrevista.
Es inaceptable en la industria del software tener un algoritmo que funcione correctamente “la mayor parte del tiempo”. En el grupo donde trabajo ahora, la mayoría de los errores que pasan a las pruebas de producción se deben al manejo inadecuado de los casos de esquina. (En el mundo RTOS donde vivo, los casos de esquina a menudo se llaman “condiciones de carrera”, pero el concepto es el mismo. Si algo puede romper su código, eventualmente lo romperá).
Por lo menos, si está codificando en la pizarra, debe señalar los casos de esquina y preguntarle al entrevistador si es necesario manejar los casos de esquina. Si puede señalar los casos de esquina y describir cómo los manejaría, incluso si realmente no escribe el código para hacerlo, todavía está muy por delante de un candidato que escribió un código ajeno a la esquina casos y luego se da vuelta y dice: “Creo que esto funcionará”.
- ¿Los entrevistadores técnicos explican la confusión resultante de hablar y pensar en un idioma no nativo?
- ¿Lógica detrás del programa para verificar si el número es palíndromo o no?
- ¿Cuál es su enfoque para las entrevistas de codificación de crack en empresas de primer nivel sin ser bueno en la programación competitiva?
- ¿Por qué apesta la programación visual?
- Cómo quejarme de mi compañero de cuarto que está engañando en sus entrevistas telefónicas de Google
También tenga en cuenta que en el mundo real, es mucho mejor que los casos de esquina bloqueen el programa en lugar de comportarse incorrectamente. (Los bloqueos del programa se notan y se corrigen rápidamente; los datos corruptos a veces no se notan hasta que es demasiado tarde). Como entrevistador, tengo esto en cuenta. Si su función C falla cuando pasa un puntero NULL, estoy de acuerdo con eso. Solo documentalo apropiadamente. Pero si su función C trata silenciosamente el número de entrada 4294967295 como -1, eso podría ser un gran problema.