¿Seguiría contratando a un desarrollador de software si él / ella es débil en algoritmos pero tiene un historial exitoso de desarrollo de nivel de producción?

El mundo tiene muy poca paciencia. La gente quiere todo, aquí y ahora. ¿Estás dispuesto a esperar 2,5 segundos más para que se cargue la página de inicio? ¿Está bien si me tomo 30 minutos para generar un informe cuando lo recibe instantáneamente en otro lugar?

A medida que los datos, la población, las opciones, las máquinas, las ideas, la inteligencia artificial y las demandas continúen creciendo, todos los que quieran permanecer en el negocio se verán obligados a operar a escala sin ninguna caída en el rendimiento y la experiencia.

No importa mucho si mis desarrolladores escriben algoritmos logarítmicos, lineales, polinómicos o exponenciales cuando mi tamaño de entrada es, digamos, 10. Pero, mi negocio nunca crecerá 10 veces con un algoritmo exponencial en el back-end.

Matemáticas, estructuras de datos, algoritmos y diseño se han convertido en parte de entrevistas rigurosas por este motivo. Creo que es muy razonable, ya que quiero que mis desarrolladores me ayuden a mantener mi negocio y a crecer exponencialmente.

Definir “débil en algoritmos”. Probado cómo, exactamente?

La verdad es que las decisiones de contratación para roles técnicos que exigen la tenencia profesional no se reducen a la capacidad de escribir una secuencia de Fibonacci en una pizarra blanca durante una entrevista. Los desarrolladores experimentados ganan salarios más altos no por su conocimiento en un lenguaje de programación en particular, sino por la confianza de que son lo suficientemente competentes como para elegir consistentemente el conjunto correcto de herramientas para resolver los problemas frente a ellos. Esto se evidencia específicamente a través de un historial de implementaciones exitosas de código en entornos de producción de alta demanda.

Si tiene la suerte de captar el interés de alguien con la madurez y la experiencia que busca, que también es una buena opción cultural para su organización, ¡CONTRÁTELOS! Los empleados que se quedan desde el descubrimiento de productos hasta las operaciones posteriores al lanzamiento son los que desea en su equipo. Son un hallazgo raro.

Personalmente, un título de CS no tiene valor para mí si el código que escribes nunca verá la luz del día, o si no estarás cerca para apoyarlo cuando lo haga.

Dejaré entrar un secreto.

Durante una entrevista con Microsoft, a todos nos hicieron preguntas relacionadas con estructuras de datos y algoritmos.

Después de descifrar esas entrevistas, esperarías algún trabajo relacionado con eso. Pero la amarga verdad es que estará escribiendo lógica simple sin ningún uso de algoritmos y estructuras de datos la mayor parte del tiempo.

Es posible que ni siquiera necesite un código optimizado. En ciertos casos en los que maneja un gran rendimiento, necesita un código optimizado. Pero eso no significa que contrataría a alguien que escriba código subóptimo. Con la escala, el código optimizado puede ser necesario para reducir los costos.

Definitivamente me gustaría conocer los detalles del proyecto y la escala. Si ha trabajado con éxito en problemas de optimización, definitivamente lo contrataría. No lo rechazaría solo porque no puede recordar algunos algoritmos durante las entrevistas.

He observado un cambio en el proceso de entrevista en las startups. En lugar de centrarse en las estructuras de datos, se centran en los problemas de diseño. Se les da un escenario en el que tienen que encontrar una solución óptima. Creo que es un mejor método de entrevista que simplemente preguntar estructuras de datos y algoritmos.

Seguro.

Como dijo Garry Taylor , es muy poco probable que los tipos de algoritmos que puedes estudiar en la escuela o en los libros desempeñen un papel en tu carrera de desarrollo. La experiencia del mundo real y el éxito comprobado triunfan sobre todo lo demás en el desarrollo de software.

Ahora, ciertamente esperaría que un desarrollador pueda localizar y comprender algoritmos relevantes para el trabajo en cuestión, usar las bibliotecas existentes y / o escribir código para implementar un algoritmo bien descrito o heurístico.

• ¿Necesito un desarrollador para escribir un resumen rápido desde cero? Diablos, no, para eso están las bibliotecas. Esperaría que él / ella sepa cómo seleccionar entre los algoritmos de clasificación disponibles. Incluso podría quitar puntos si alguien intentara volver a desarrollar algoritmos básicos desde cero.
• Para un problema más complicado: bien podría contratar a un experto en la materia que conozca los algoritmos (fórmulas) relevantes para su campo (por ejemplo, contratar a un estadístico para realizar análisis de datos o escribir código de análisis de datos). Podría esperar que un generalista pueda investigar la literatura (por ejemplo, encontrar y elegir entre enfoques alternativos para programar la entrega de paquetes).
• Si nuestro proyecto está a la vanguardia, entonces podría buscar a alguien que sea particularmente experto en investigación y resolución de problemas, que pueda desarrollar nuevos algoritmos y heurística.

En general, no.

Los algoritmos tienden a centrarse en la escala y la eficiencia, que en muchos casos no importan mucho, a menos que se contraten específicamente con el propósito de escalar una eficiencia.

Los algoritmos ayudan a dar una idea de cómo funcionará una pieza de código a escalas más grandes. Sin embargo, no mucho software realmente llega a la escala o encuentra los problemas donde los algoritmos se vuelven muy importantes.

Tal como lo veo, los beneficios de los algoritmos no son tanto saber cómo escribir código eficiente (cómo escribir varios algoritmos), sino más bien asegurarse de que el algoritmo que va a usar (o esté usando) sea lo suficientemente bueno para la escala actual / requisitos de eficiencia del software, y tener algunas ideas sobre a qué nivel de escala ese algoritmo ya no puede ser lo suficientemente bueno.

Por supuesto, todos los algoritmos son bastante aproximados, por lo que las estimaciones también son bastante aproximadas. Si no es lo suficientemente bueno, necesitará los algoritmos de conocimiento que brindan para determinar dónde / cómo hacerlo lo suficientemente bueno o lo suficiente como para decir que no se puede mejorar y que se necesita una solución alternativa (como soluciones aproximadas, almacenamiento en caché, memorización y varias otras técnicas que se utilizarán).

Ninguna persona en su sano juicio rechazaría a un desarrollador experimentado que demostrablemente pueda y pueda poner en producción software que genere ingresos sobre una persona que todavía no tiene un historial pero que ocupa un lugar destacado en codewars.

Algunas compañías tienen ese proceso y son parte del problema. No seas parte del problema, siempre contrata a la persona que hará que el equipo sea productivo lo más rápido posible.

La mayoría de los desarrolladores de software con los que he trabajado durante décadas pueden hacer cosas increíbles, han creado productos que son utilizados por personas de todo el mundo y generan miles de millones de dólares, pero no pueden escribir una lista vinculada desde la memoria. Y aún no he visto que eso sea causa de plazos incumplidos.

Por lo tanto, no hago preguntas de algoritmos en mis entrevistas. De esa manera no excluiré a la persona que puede ser productiva.

Como otras personas mencionaron, depende del nivel de debilidad. Si veo algo que me interesa en el currículum de un candidato, o algo que se destaca como un proyecto importante, me gustaría preguntar al respecto. Puede ganar mucho por la profundidad de su explicación, y generalmente me gusta sondear al candidato con escenarios técnicos hipotéticos.

En cuanto a ser débil en algoritmos, las banderas rojas para mí son:

1. incapacidad para descomponer un problema en subproblemas
2. incapacidad para comprender cuán complejo es un algoritmo (en términos de notación Big O)
3. incapacidad para escribir código claro
4. incapacidad para explicar conceptos clave del idioma elegido, como gestión de memoria o concurrencia
5. completa ignorancia de las estructuras de datos fundamentales

Suponiendo que definamos “historial exitoso de desarrollo de nivel de producción” significa que han producido software demostrable que ha hecho dinero … entonces está perdiendo el tiempo haciendo preguntas sobre algoritmos.

El único lugar en el que las preguntas sobre algoritmos tienen sentido es si está contratando roles que son extremadamente poco comunes. Tal vez necesite que alguien escriba código para un satélite que tiene muy poca memoria, por lo que no puede usar bibliotecas estándar. Tal vez estás tratando de vencer a Google en la búsqueda, por lo que quieres algunas personas que puedan desarrollar nuevos algoritmos de vanguardia. En el otro 99.999% de los casos de negocios, el objetivo es crear software que genere dinero para resolver problemas que se han resuelto anteriormente.

En todo caso, vería que ser “débil en algoritmos” en una entrevista es algo bueno. Las personas que obtienen buenos resultados en las preguntas sobre algoritmos en las entrevistas suelen ser una de dos categorías:

1. Recién salido de la escuela. Inexperto. Es más probable que haga daño que bien sin una estrecha supervisión.
2. Algoritmos estudiados recientemente porque anticiparon que estaban en la entrevista. Eso significa que esta persona pasó tiempo estudiando temas que serán prácticamente inútiles, y probablemente olvidados, después de ser contratados cuando podrían haber pasado su tiempo construyendo algo.

Dado que respeto a los desarrolladores de software que crean y mantienen un software de calidad mucho más que a los desarrolladores que pueden responder preguntas sobre algoritmos bajo presión … Creo que debería estar claro qué camino tomaría si fuera usted.

Definir débil.

Si él / ella no puede recordar la clasificación rápida de la memoria, está bien para mí. No estoy contratando personas para codificar el ordenamiento de burbujas o invertir árboles binarios. Uno siempre puede buscarlo. Y no haré tales preguntas de todos modos.

Pero si él / ella no puede entender su código, o no sabe cuál de los dos códigos es el más eficiente, es una gran bandera roja que me grita. En ese momento, no me preocupará su historial “exitoso”.

Desarrollo sistemas de tiempo crítico. Necesito el código más eficiente. No estoy en el negocio de vender aplicaciones o sitios web. Pero tampoco estoy buscando una memoria humana de algoritmos.

Quiero personas que puedan pensar y encontrar soluciones a problemas difíciles. Dar sentido al código escrito por otros. Depurar código complejo. Construya sistemas que puedan escalar. Acepta errores y aprende de ellos.

Eso requiere conocimiento técnico, habilidades para resolver problemas, habilidades de depuración y una buena disposición para aprender. Bonificación adicional si tienen la experiencia laboral requerida.

No me estoy conformando con nada menos.

¿Qué quieres decir con “débil en algoritmos”? Si quiere decir que no pueden resolver acertijos de algoritmos difíciles bajo presión, entonces, recomendaría contratar a un candidato con habilidades de desarrollo demostradas.

Lo que no aceptaría es la incapacidad:

1. Para poder hacer cosas simples, como insertar un elemento en una lista vinculada

2. Compare y contraste las ventajas de las estructuras de datos existentes y hable sobre ellas en términos de complejidad temporal: no me importa si no puede implementar rápidamente un árbol rojo-negro o una tabla hash en una entrevista. Me importa si usted no se puede describir la diferencia (en términos de complejidad temporal para operaciones comunes) entre tales estructuras.

3. También me gustaría ver el conocimiento de las estructuras disponibles en el idioma de destino que utilizará,

Es importante que me demuestres que eres un consumidor experto de estructuras de datos y algoritmos, no que eres un productor experto de estructuras de datos y algoritmos. Además, el conocimiento de buenos principios de diseño de programación orientados a objetos y genéricos sería importante.

Depende de cómo puedo observar ese historial exitoso.

Si ese registro está disponible para que todos lo vean, como en un gran proyecto de código abierto, entonces la debilidad relativa de los algoritmos no es un problema en absoluto.

Pero si el historial es largo, pero efectivamente desconocido y desconocido para mí … entonces no tengo evidencia de fortalezas para equilibrar las debilidades.

Permíteme reformular esto:

¿Contratarías a alguien que ya haya hecho el trabajo que te gane dinero: crear aplicaciones vendibles que funcionen completamente?

¿O preferiría contratar a alguien que pueda hacer “crucigramas” informáticos, con los que no pueda ganar dinero?

En algún momento, estas cosas de ‘necesitas algoritmos’ realmente necesitan abordarse en las universidades.

Pero esta es solo mi opinión. Entonces, probemos esto:

• Ve a tu tienda de aplicaciones
• Buscar aplicaciones de ‘pérdida de peso’
• Anote cuántos y el modelo de negocio para cada uno (uno fuera, compra en aplicación, compatible con anuncios)
• Ahora, busque aplicaciones de ‘inversión de cadena recursiva’
• ¿Encontrar cualquier? ¿Por cuánto estaban en oferta?

Los algoritmos rara vez, a veces son importantes en algunos campos, brevemente, entre todos los otros trabajos que tiene que hacer. Pero su trabajo remunerado será construir cosas por las que podamos cobrar.

Por lo tanto, siempre sin duda estaré verificando que puedas crear aplicaciones.

Pregunta: ¿Seguiría contratando a un desarrollador de software si él / ella es débil con los algoritmos pero tiene un historial exitoso de desarrollo del nivel de producción?

Tengo una pregunta para la pregunta en sí: ¿qué coño es un desarrollo a nivel de producción?

Si “desarrollo a nivel de producción” significa que el desarrollador construyó un producto exitoso que se ejecuta lentamente y tiene errores, miro algunos otros factores:

1. ¿Se le ocurrió a la persona la idea del producto?
2. ¿La persona diseñó la experiencia del usuario por sí misma?
3. ¿La persona realizó las ventas del producto por sí misma?
4. ¿La persona hizo que el producto y su mercado designado se encontraran y encajaran?
5. ¿La persona construyó un negocio alrededor de este producto?

Si la persona puede dar una respuesta positiva a al menos una de esas preguntas, lo contrataré … como gerente de producto / diseñador de experiencia de usuario / tipo de ventas / tipo de marketing / tipo de desarrollo empresarial y no como desarrollador. Mi empresa también necesita esas otras funciones, al menos tanto como un desarrollador y la persona puede agregar valor en esos campos.

Si la persona da todas las respuestas negativas, no lo contrataré. ¿Sabes por qué? Porque él

1. No gestioné el producto
2. No diseñó su experiencia de usuario
3. No vendió el producto.
4. No comercializó el producto.
5. No hice desarrollo de negocios
6. Todo lo que hizo fue escribir código y construir el software e hizo un trabajo subóptimo.

Puedo contratar a otros tipos que hacen un mejor trabajo al escribir código y contratar gerentes de productos / diseñadores de experiencia de usuario / tipos de ventas / tipos de marketing / tipos de desarrollo empresarial con los que trabajó anteriormente y que tienen productos exitosos que no tienen errores.

Actuando sobre esta información: ¿contrataría al tipo?

Definir débil. El hecho de que alguien falle una pregunta de la entrevista sobre algoritmos no significa que la persona sea necesariamente débil en algoritmos. Me parece poco probable que alguien con un historial exitoso al menos no domine lo básico.

Si el candidato parecía muy débil, comenzaría a cuestionar si el historial reclamado podría ser exagerado.

Mi barra de contratación también dependería mucho de la posición, por supuesto.

Supongo que depende de lo que quieras decir con “registros exitosos de desarrollo del nivel de producción”. Administro un equipo que escribe aplicaciones de iOS. Muchos candidatos que entrevisto creen que enviar una docena de aplicaciones a la App Store los hace deseables, pero a menudo encuentro que ese no es el caso. La capacidad de buscar en Google soluciones que otros han creado y pegarlas rápidamente es una habilidad útil para ciertos tipos de desarrollo, pero no una que valoro mucho ni es una habilidad difícil de adquirir.

El trabajo de un desarrollador de software es resolver problemas y eso implica crear y resolver algoritmos. Si no puede resolver los problemas, ¿por qué lo contrataría para escribir software?

Un historial exitoso de entrega de código de producción es todo lo que DEBE importar para una empresa.

Creo que debería ser más acerca de sus habilidades para discutir proyectos anteriores, decisiones de arquitectura tomadas, el negocio de la empresa y cómo contribuyó que conocer realmente todos los algoritmos de memoria.

No esperaría que alguien con 5 años de experiencia como desarrollador front-end conozca SQL, por ejemplo. La empresa podría usar abstracciones internas, etc. Se trata más de saber que, si llega el momento de usar algo nuevo, el candidato puede corresponder de manera positiva.

Depende del trabajo. Si el trabajo requiere ajustar las estructuras de datos existentes, entonces sí. Sin embargo, la mayoría de estas funciones ya forman parte de la biblioteca estándar y la mayoría de los trabajos dependen de estos estándares, un éxito comprobado en el desarrollo del nivel de producción es muy importante.

El desarrollo a nivel de producción consiste en escribir algoritmos, por lo que no puede ser bueno en uno y malo en el otro.

(Si quiere decir que es malo conocer algún conjunto estándar de algoritmos, de eso no se trata la programación. Un algoritmo es solo un proceso o conjunto de reglas a seguir en las operaciones de resolución de problemas, por lo que todo lo que desarrolle, hasta un programa completo, es un algoritmo)

Depende del trabajo. Una gran cantidad de desarrollo no utiliza ningún algoritmo más complicado que la búsqueda lineal y no hay estructuras de datos mucho más elegantes que una matriz asociativa (es decir, python hash, objeto javascript).

Dicho esto, hay buenos cursos en línea y te abrirá posibilidades si subes de nivel.