Clave la entrevista sobre microservicios: hablemos de .NET

Imagine que tiene un sistema muy complejo en sus manos, que se divide en varios microservicios para ejecutar. El código que escribo está bien, pero cada vez que voy a una entrevista de trabajo surge una pregunta: ¿cómo pregunto si la otra persona realmente lo entiende? Cualquiera puede memorizar esos conceptos teóricos, pero cuando se trata de la implementación específica en .NET, los detalles se vuelven borrosos.

Hemos hablado con muchos equipos y descubrimos que todos tienen los mismos dolores de cabeza. Algunas personas preguntan de manera demasiado superficial y simplemente preguntan "¿Qué son los microservicios?"; Algunas personas profundizan demasiado y se enredan en cierto elemento de configuración impopular. Es posible que el entrevistador haya comenzado a trabajar en ello él mismo y, después de hacer muchas preguntas, todavía siente que no conoce los entresijos.

De hecho, entrevistar es un poco como depurar código. Necesita saber dónde están los puntos de interrupción críticos.

De la teoría a la implementación: ¿Qué estás pidiendo exactamente en .NET?

Los microservicios suenan elevados, pero cuando se trata de proyectos .NET, son solo una serie de opciones específicas y operaciones prácticas. Por ejemplo, para la contenedorización, ¿utiliza Docker o directamente Kubernetes? ¿Cómo diseñar una puerta de enlace API? ¿Tengo que montarlo yo mismo si encuentro el servicio? Detrás de estas preguntas se esconde un profundo conocimiento de la arquitectura.

Existe un malentendido común: muchas personas conocen la tecnología de memoria, pero no pueden explicar por qué eligieron esta en lugar de aquella. En el ecosistema .NET hay muchas herramientas y marcos, y cada elección tiene su precio. Durante la entrevista, queremos escuchar el pensamiento detrás de esto en lugar de enumerar sustantivos.

"Si la comunicación entre servicios de repente se ralentiza, ¿por dónde empezar?" No existe una respuesta estándar a esta pregunta, pero puede indicar si una persona realmente ha trabajado mucho o simplemente ha leído algunos blogs.

¿Cómo descubres tus verdaderas habilidades?

No te concentres sólo en conceptos. Pasando directamente al escenario: "Supongamos que ahora tiene un servicio de pedidos y un servicio de inventario, y el inventario se deduce cuando se crea el pedido. ¿Cómo se asegura de que los datos no se estropeen?"

En este punto, la respuesta podría involucrar colas de mensajes, transacciones distribuidas o, eventualmente, diseños consistentes. En .NET, puede utilizar MassTransit o NServiceBus, o puede utilizar RabbitMQ directamente. Pero la cuestión no es el nombre de la herramienta, sino la elección: ¿por qué se usa de esta manera? ¿Cuál es el costo?

Habla sobre la experiencia del fracaso. ¿Quién no ha tropezado con algún obstáculo en el camino hacia los microservicios? Tiempos de espera de red, gestión de configuración confusa, monitorización inadecuada... Escuche qué problemas específicos encontró la otra parte y cómo los resolvieron. Esto es mucho más útil que una teoría perfecta.

El entorno .NET tiene una característica: es a la vez tradicional y moderno. Muchos equipos se separaron de los antiguos sistemas únicos y llevan un pesado bagaje histórico. Las buenas preguntas de la entrevista deberían revelar la capacidad de la otra persona para manejar esta complejidad.

Mantenlo simple, pero no demasiado simple.

Al diseñar problemas, es fácil llegar a dos extremos: demasiado abstracto o demasiado trivial. Las buenas preguntas de una entrevista deberían ser como escribir código, con módulos claros pero con margen de expansión.

Por ejemplo, cuando pregunte sobre registros y monitoreo, puede decir: "Los microservicios están dispersos y los registros también están dispersos. ¿Cómo se pueden unir pistas?" Esto puede conducir a la pila ELK, Seq o directamente a Azure Application Insights. Pero más profundamente, ¿cómo se definen los niveles de registro? ¿Cómo evitar tener demasiados registros y no poder encontrar los puntos clave?

O pregunte a seguridad: "Con tantos servicios, ¿cómo gestionar la autenticación?" En este momento, podemos hablar de rotación de claves OAuth2, JWT o API. En .NET, IdentityServer es una opción común, pero no es la única respuesta.

La clave no es si la otra parte conoce una determinada herramienta, sino si comprende la naturaleza del problema.

nuestra propia experiencia

Para ser honesto, no supimos preguntar desde el principio. Al principio, la lista de preguntas parecía el índice de un libro de texto y todavía me sentía inseguro después de la entrevista.

Posteriormente fuimos comprendiendo que la entrevista no es un examen, sino una conversación. Quieres entender cómo piensa la otra persona y la otra persona también siente la atmósfera técnica de tu equipo. Por eso ahora preferimos proponer un escenario simplificado de la vida real y discutir posibles soluciones juntos. Lo que se puede exponer en este proceso es mucho más que la respuesta estándar.

El ecosistema de microservicios .NET cambia constantemente y constantemente surgen nuevas herramientas y modelos. Hay que adaptarse a las preguntas de la entrevista y no siempre se puede seguir la misma rutina que hace unos años. Pero las cosas centrales no han cambiado: una base de programación sólida, un pensamiento de diseño claro y la voluntad de resolver problemas prácticos.

Algunas palabras de pequeña charla.

En última instancia, las entrevistas tratan de encontrar personas con las que puedan resolver problemas juntos. La arquitectura de microservicios en sí es bastante compleja y lo que el equipo necesita es un socio que pueda simplificar el complejo.

Por lo tanto, cuando se prepare para una entrevista la próxima vez, piense menos en las "preguntas estándar" y más en "qué problemas hemos encontrado realmente". Si hablamos de esas pequeñas luchas y enredos reales, las respuestas suelen estar ahí.

Los detalles técnicos quedarán obsoletos, pero la forma de pensar sobre ellos no. Encontrar a alguien con quien pueda pensar en ir es probablemente lo más importante que debe hacer en una entrevista.

Establecido en 2005,kpotenciase ha dedicado a un fabricante profesional de unidades de movimiento compacto, con sede en Dongguan, provincia de Guangdong, China. Aprovechando las innovaciones en la tecnología de accionamiento modular,kpotenciaintegra motores de alto rendimiento, reductores de precisión y sistemas de control multiprotocolo para proporcionar soluciones de sistemas de accionamiento inteligentes eficientes y personalizadas.kpotenciaha entregado soluciones de sistemas de accionamiento profesionales a más de 500 clientes empresariales en todo el mundo con productos que cubren diversos campos, como sistemas domésticos inteligentes, electrónica automática, robótica, agricultura de precisión, drones y automatización industrial.