¿Debo despedir al nuevo desarrollador de backend ya que no conoce AWS y Azure? ¿Son estos conocimientos comunes para todos los desarrolladores de back-end?

Probablemente no.
Voy a hacer algunas suposiciones aquí. Por favor, siéntase libre de corregirlos.

1. No te mintió
2. Se lleva bien con el resto del equipo.
3. Tiene todas las otras habilidades necesarias para el puesto.

¿Qué quieres decir con que no los conoce? ¿Estás diciendo que nunca ha hecho nada con ninguno de ellos? ¿O que no tiene todos los comandos de la consola memorizados? Es una diferencia grande y bastante crucial. Si él nunca ha hecho nada con ninguno de ellos y él expresamente y sin ambigüedades dijo que sí, entonces es posible que desee despedirlo. Salvo esa situación exacta, este es su problema:

Acaba de gastar N para reclutar un candidato. Eso es lo que le pagó al agente si usó uno, su tiempo interno creando PD, entrevistando candidatos, etc. La contratación no es barata y no es rápida. La última vez que contraté a un nuevo desarrollador, me llevó 3 semanas encontrar a alguien que me gustara. Ese desarrollador tenía un período de preaviso de 4 semanas en el antiguo trabajo, más algo de tiempo para negociar el contrato y el salario. En total, apenas 2 meses desde “Necesito un nuevo desarrollador” hasta “Obtengamos su insignia de seguridad”. Sus plazos pueden diferir, pero dudo seriamente de que tenga desarrolladores de backend talentosos con todas las habilidades que desea derribar. diciendo “¡Quiero comenzar mañana!”

Entonces, si continúa con su tipo actual, sus costos son: N + S + C, donde N fue su costo de reclutamiento y S es el costo de ponerlo al día en la base de código y C es el costo de ponerse al día los ecosistemas de nubes que estás usando.

Si decide contratar a un nuevo tipo, sus costos son N + (N – R) + S + O, donde tiene el costo de reclutar de nuevo menos las partes que puede reutilizar (las cláusulas de reemplazo en los contratos de agente, probablemente pueden reutilizar lo mismo PD, etc.) como (N – R) más el costo para ponerlo al día en la base de código (S) más el costo de oportunidad (O) de no tener a nadie trabajando en el proyecto durante 2 meses mientras recluta.

Entonces las Ns y Ss se cancelan, y te quedas con N + OR y C. Lo que nos permite enmarcar la pregunta. Es el costo de reclutar a una nueva persona menos las partes reutilizables de su último esfuerzo de reclutamiento más el costo de oportunidad de que nadie trabaje en el proyecto menos que el costo de poner al día a su desarrollador actual en su ecosistema de nube de elección. Si la respuesta es no, reemplazarlo no tiene sentido comercial. Si la respuesta es sí, entonces reemplazarlo probablemente tenga sentido comercial. Pero una vez que se da cuenta de cuán altos son los costos de oportunidad, llegamos a la conclusión: probablemente no.

¿No es este conocimiento común a todos los ingenieros de backwnd?

Claramente no tienes idea de la tecnología. Por lo tanto, no tiene por qué despedir a alguien. Es una práctica común, por cualquier estúpido y estúpido motivo, esencialmente hacer una lista aleatoria de habilidades en una lista de requisitos de trabajo. Es una práctica estándar usarlo como una guía muy muy aproximada. En otras palabras, no se lee:

El candidato debe tener todas estas experiencias y habilidades.

Pero rathwr

Si ha hecho algo de lo siguiente y / o le interesa el resto, solicítelo.

1. Las empresas generalmente quieren que cualquier persona interesada al menos presente su solicitud. No significa que hayan dominado todo en su lista aleatoria.
2. Los empleados en realidad están buscando habilidades en esta lista que no tienen pero que les gustaría tener experiencia. En general, desea que estas personas presenten su solicitud. Si estoy buscando un ingeniero de Scala, realmente no quiero filtrar a un gran ingeniero de C ++ que esté interesado en el concierto parcialmente como una oportunidad para aprender Scala. Su aplicación, a pesar de que enumera a Scala como un requisito, ¡no se considera deshonesto de ninguna manera!
3. Con una probabilidad casi segura, no podrá permitirse (o incluso encontrar) contratar a alguien que tenga experiencia de nivel experto en toda su lista de requisitos de trabajo al azar. O su lista es bastante corta, en cuyo caso es extraño que tenga este problema. Si tal vez tenía dos elementos en la lista “despliegue en la nube” y “programación oo”, y el título del trabajo es algo así como devops, entonces su frustración es más comprensible, sin embargo, aún es su culpa por no probarlo a fondo.
4. Llegaría a decir que disparar por falta de experiencia simplemente no se hace en Silicon Valley. Aquí parece que tomamos cierto legado de la academia. Claro que hay requisitos previos para la clase, pero una vez que esté inscrito en la clase, tratamos de asumir la mínima cantidad de familiaridad, y algunas compañías van tan lejos como para decir “ok, olvida todo lo que creías saber en la puerta” .
5. Incluso si tienen algo de experiencia, las posibilidades de que esta experiencia se alinee de una manera totalmente útil con lo que necesita también son extremadamente bajas.

Claro, tal vez si estás desesperado podría tener sentido liberar $$ y contratar a un consultor o algo así. Sin embargo, sigue siendo malo y debes hacer todo lo posible para ayudar a este ingeniero a ponerse de pie.

¿Dijo que tenía experiencia con AWS o Azure en su carta de presentación, currículum o solicitud? ¿Le preguntaron sobre AWS o Azure durante una entrevista? En otras palabras, ¿mintió sobre su conocimiento de AWS / Azure?

Dado que asume que esos dos servicios de computación en la nube específicos del proveedor en particular deberían ser de “conocimiento común” para los desarrolladores de back-end, sospecho que no consideró la posibilidad de que, tal vez, no lo sean. La computación en la nube es la gran tecnología compatible con las palabras de moda en estos días, pero no es un requisito para el desarrollo o la implementación web. La gente todavía construye sus propias granjas de servidores, compra servidores virtuales de Rackspace y otros proveedores, o de otro modo se autohospeda, sin tocar proveedores de “nube” como Amazon, Microsoft o Google.

Tal vez este tipo no sea su persona de destino para el despliegue en su equipo, pero aparte de eso, ¿cómo están sus habilidades de desarrollo de back-end?

La industria del software consiste en una amplia gama de tecnologías y sería inconcebible incluso para un experto en AWS o Azure conocer cada comando de la consola o API sin consultar la documentación.

Un mejor enfoque en la ingeniería de software es leer la documentación, ser bueno en la lectura de la documentación y mantener actualizadas las habilidades y el conocimiento general desde un punto de vista arquitectónico y saber cómo, al leer la documentación, aplicar este conocimiento a la tarea en cuestión .

¿Cuál preferiría? ¿Un organismo AWS capaz de hacer todo con el software en 2 minutos planos? O una estrella de rock versátil capaz de ofrecer valor de cualquier manera que su negocio necesite maniobrar ante la incertidumbre (es decir, el futuro).

Piénselo dos veces antes de despedir a alguien en función de lo que sabe, en lugar de lo que es capaz de lograr.

El conocimiento no es común a todos los desarrolladores de back-end.

Si tener ese tipo de experiencia es tan importante en un candidato, ¿por qué no pasó el tiempo para resolver esto antes de hacer una oferta? ¿Por qué falló su proceso de entrevista? ¿Cuáles son las otras fortalezas compensatorias de la persona que te hicieron contratarlas en primer lugar?

Nada de lo que diga en la pregunta sugiere que mintieron, solo que puso un montón de basura en la descripción de un trabajo y luego decidió que la experiencia de AWS o Azure es lo suficientemente importante como para considerar despedir a alguien, pero no lo suficientemente importante como para preguntar en un pantalla del teléfono o entrevista en el sitio.

Tal vez y no

Si estaba claro que la experiencia con la implementación de Azure / AWS (e implementar lo que se ve a continuación) era un requisito y el empleado en cuestión indicó que él o ella había dicho experiencia, entonces probablemente debería hacerlo. Después de todo, es por eso que uno tiene “períodos de prueba”.

La implementación en servicios PAAS como AWS y Azure aún no es tan común. Además de esto, los mencionados proporcionan una amplia gama de servicios que se expanden y evolucionan rápidamente. Azure, con el que estoy más familiarizado, proporciona más de 70. Para Azure puedo implementar aplicaciones web, búsquedas, trabajos web, ML, y muchos otros en mi sueño. Algunos de scripting, algunos usando msdeploy, algunos usando el portal de Azure -ugh-. Sin embargo, si quisieras que implementara los servicios de dominio, tendría que ir a cavar.

En resumen, en la mayoría de los casos, si uno estaba claro por adelantado, estaría de acuerdo en que liberar a dicho empleado nos corresponde, tanto por requisitos como por razones de honestidad. Mirando hacia el futuro, tenga en cuenta que aunque AWS y Azure son términos muy breves que abarcan una amplia gama de servicios y capacidades. Utilizados sin proporcionar especificidad, a menudo son demasiado vagos para ser de utilidad.

¿Por qué un desarrollador de back-end estaría interesado en dos proveedores de nube en particular? Ese sería un trabajo de sysops o devops, en general, e incluso entonces puede ser excelente en cualquier rol sin el conocimiento de esas plataformas en la nube.

Se puede esperar que un desarrollo de back-end en una empresa muy pequeña asuma algunos trabajos de operaciones, pero no es fundamental para el desarrollo de back-end, incluso en ese momento.

Finalmente, ni AWS ni Azure son tan complejos o difíciles de aprender, por lo que sería más barato capacitar a la persona que los despide.

Quiero repetir la respuesta anónima, porque a pesar de lo dura que es, llega al quid de la cuestión:

Claramente no tienes idea de la tecnología. Por lo tanto, no tiene por qué despedir a alguien.

Las respuestas ya dadas lo resumen bien; preste atención a sus consejos dados, es un buen consejo.

¿Te perdiste este punto mientras lo entrevistabas? En caso afirmativo, diría que es su ineficiencia, no la suya.

Puedes despedirlo fácilmente, pero ¿vas a asegurar su futuro empleo? Esto es porque quería que te relacionaras con mi primer párrafo

AWS o Azure no son ciencia espacial, programe un entrenamiento para ese tipo, el beneficio aquí es que él / ella estará contento con la compañía y contribuirá mejor.

Parece un poco injusto si realmente no probaste esas habilidades. Sin embargo, antes de hacer algo, debe descubrir cómo evaluar esas habilidades especializadas. De lo contrario, terminarás en la misma posición nuevamente.

Especifico claramente que necesitamos experiencia en la implementación en la nube en AWS o Azure en nuestra descripción del trabajo

Entonces sí, es posible que desee despedirlos por no cumplir con los requisitos establecidos para el puesto.

pero me pregunto si estos conocimientos no son comunes a todos los desarrolladores de back-end.

No.

Tal vez. Parece que tiene una razón clara que explicará por qué lo despidió, pero la única razón por la que realmente debería despedirlo ahora es si no puede realizar adecuadamente el trabajo para el que fue contratado. No pondría demasiado énfasis en la falta de comunicación de habilidades. Encontrar un ajuste exacto nunca ocurre particularmente cuando está buscando una tecnología específica, no un tipo genérico de habilidad. Muy pocas tecnologías son ubicuas, AWS y Azure definitivamente no se encuentran entre ellas, incluso para los desarrolladores de back-end. Dependiendo de las circunstancias, hay muchas razones que podrían explicar por qué pensó que todavía era un buen candidato para el puesto que no fuera una intención maliciosa de engañar. Si contrataste a un chico sin verificar realmente que sabía algo sobre lo que dijo saber y que sentiste que era crítico con algunas preguntas específicas sobre AWS o Azure, eso revela más de un problema con tu proceso de contratación, entonces puede ser sobre su personaje. Sin embargo, el hecho de que no pueda hacer su trabajo ahora, ciertamente es un delito que se puede disparar.

Sí, deberías despedirlo porque te mintió cuando te dijo que tiene experiencia en este campo. Sin embargo, no asuma que todos los desarrolladores están familiarizados con AWS o Azure, no lo están.