Cómo juzgar a un programador de red con solo 5 preguntas

Comencemos por si puede incluso. Cinco preguntas le dan 2 ^ 5 resultados posibles, 32 posibilidades insignificantes. Si hay más de 31 categorías en las que puede estar un programador de red y no un programador de red, entonces la respuesta es no. Lo mejor que puedes hacer es generalizar. Hay demasiados tipos de programadores de red.

Para obtener la máxima información, todas las preguntas deben ser ortogonales. Cada pregunta debe ser creada en el momento para dividir el espacio restante del posible programador de red. Los ultrapuristas de un solo nicho tienden a ser raros, por lo que te queda todo ese espacio como una posibilidad.

Debido a que este enfoque utiliza la bisección para examinar la programación de la red, la primera pregunta tiene que dividir toda la programación de la red en uno de los dos campos. La razón para evitar las preguntas más flexibles que pueden tener muchas respuestas es que nunca se puede distinguir entre la memoria y el razonamiento, los humanos también pueden usar plantillas, los pensadores brillantes no equivalen a codificadores brillantes, y no se puede cuantificar fácilmente ni el pensamiento preciso ni la inspiración. pensando.

Después de haber entrevistado a muchas personas a lo largo de los años, descubrí que la técnica de la entrevista y la preparación cuidadosa indican a alguien que es poco probable que sea dinámico y que tenga un pensamiento rancio. Pero pasarán la inspección básica con gran éxito. Cualquier prueba de codificación, cualquier cosa en la que no importa ser obsoleto, será respondida tan bien como cualquier persona con un proceso de pensamiento creativo, un proceso de pensamiento riguroso pero lógico, o por un proceso de pensamiento completamente lateral. Debe usar pruebas que le darán una conclusión de sí / no para cada modo de pensamiento sobre dónde está su mente, no dónde estaba.

Las mentes frescas pueden manejar lo desconocido. La falta de familiaridad no importa porque todos los problemas se pueden entender. La mente lógica reducirá los compuestos desconocidos a bloques de construcción conocidos. La mente lateral reducirá totalidades desconocidas en patrones conocidos. La mente rancia entra en pánico. Estas no son las preguntas raras que están de moda últimamente, son preguntas muy técnicas. Tienen que ser. Las preguntas extrañas no son necesarias si haces esto.

Entonces, la pregunta uno quiere saber lateral o lógica. Programación en red. Ok, un programa tiene que ser independiente de una variedad de estructuras de red. Los centros de datos generalmente usan múltiples estructuras porque Ethernet no es eficaz en esos lugares, pero no hay nada que indique que todos los centros de datos usen la misma disposición. El programa se escribirá en (idioma de elección para la tienda): ¿cómo se estructura el programa y qué estructuras / objetos / fábricas se necesitan para garantizar que el programa principal sea eficiente y libre de suposiciones específicas de la tela?

Hay cuatro resultados posibles. El resultado uno (una ruta lógica) comenzará divorciando los detalles de la conexión: todas las estructuras, información de socket, etc., del código principal. El código principal utilizará una ID interna para una conexión y no contendrá ningún código relacionado con la red. Práctica estándar de ingeniería de software, los programas no deberían preocuparse por las E / S, sino también por la compartimentación estándar.

El resultado dos (una segunda ruta lógica) comenzará observando el nivel 5 de OSI. Se darán cuenta de que la independencia de la estructura no es posible en el modelo IETF TCP / IP porque ese modelo está diseñado para ser optimizado para un solo tipo de red. Los modelos optimizados son perfectos, en ese contexto, porque obtienes lo mejor de ella. Pero si rompes el contexto, son inútiles. Terminarás pesimizando el programa si lo intentas. Entonces terminan haciendo exactamente lo mismo que el resultado uno, solo trabajando de abajo hacia arriba en lugar de arriba hacia abajo.

El resultado tres es un camino lateral. Si piensa en un diseño como una vía de ferrocarril, puede comenzar en cualquier extremo o en el medio. Hemos tenido los puntos finales, el pensamiento lateral es el tercero. El medio dice que necesitas algo que se case con los tipos de conexión. Aquí es donde probablemente verías fábricas involucradas. Finalmente, finalmente termina igual que uno y dos, el ferrocarril todavía termina exactamente en los mismos lugares y aún recorre el camino más corto.

La opción cuatro se da por vencida o no comprende el problema. Lo que no puede asumir es una topología estática (invalidada por múltiples rutas), punto a punto (invalidado por multidifusión), sockets (RDMA, bibliotecas de redes múltiples), tráfico enrutable (DECNet, SCI) o TCP / IP (Infiniband, SCI , DECNet y ATM pueden admitir esto, pero no es nativo, no estoy seguro acerca de X.25 o AX.25, agnóstico significa que Token Ring necesitaría funcionar), y esto significa asumir que tiene TCP o UDP definitivamente disponible, aunque puede asumir que es confiable y tipos de conexión poco confiables.

No importa si alguien es de arriba hacia abajo o de abajo hacia arriba, si es metódico. Entonces esa es posiblemente su división binaria en el paso dos: ¿son metódicos o no? Si han demostrado un pensamiento metódico, o la pregunta no es aplicable, preguntarías algo más.

En el pensamiento lateral, debe subdividir entre aquellos que son puramente laterales y subdividir los problemas de esa manera, y aquellos que son de modo mixto, que usan el pensamiento lateral para encontrar puntos de partida sólidos y que usan el pensamiento lógico a partir de ahí.

Después de hacer las cinco preguntas, debe tener un Diagrama Estructurado de Jackson, un archivo de encabezado, algún pseudocódigo o código compilable, soporte de sesión (capa 5), ​​lógica reentrante, algunos medios para manejar eventos y colas, algunos medios para manejar sin socket comunicaciones, algunos medios para manejar comunicaciones en tiempo real y algún concepto de conexiones grupales.

En otras palabras, deberían haber llegado al punto en que pudieran implementar dicha biblioteca con un mínimo esfuerzo. La señal de un buen programador, en cualquier campo, es que puede diseñar y escribir un programa desde el principio hasta el final sin tocar un teclado. Los cinco pasos prueban la vitalidad del codificador diseñando y codificando a lo largo de una ruta artificial que aísla una dimensión. El entrevistado debe obtener, con su carta, un CD que contenga su diseño y una versión compilable del código con él como propietario de los derechos de autor, independientemente del resultado, si el diseño es lo suficientemente completo como para terminarlo trivialmente. Haría una buena impresión.

Tienes su diseño y la prueba inequívoca de cinco dimensiones de cada dimensión de habilidad. Ahora es una prueba de seis veces ya que el todo es más que la suma de las partes. Eso sigue siendo solo una división de 64 vías, pero no se puede hacer mucho mejor. Tan pronto como te mueves de lo objetivo a lo subjetivo, o de los valores ordinales / cuantificables a algo no ordenado o no cuantificable (el análisis cualitativo no es bueno), no los estás analizando, solo estás analizando tus emociones. Eso se hace mejor en una oficina de pdoc.

1) Cómo funciona la API no bloqueadora socket_XXX ().
2) ¿Cómo diseñar un servidor de red que pueda manejar múltiples conexiones sin usar hilos, procesos?
3) ¿Cómo soluciona los problemas de conexión de red?
Cómo solucionar problemas de cada API. Por ejemplo, cómo determinar el enlace fallido, connec () falló, lan falló, el proceso del servidor está inactivo, el proceso del servidor no está reaccionando.
4) qué herramientas se utilizarán para determinar problemas de red
5) ¿Qué son los enlaces de red? Cómo funciona la multidifusión y la difusión. qué protocolo usar.
Y la lista continúa.

  1. ¿Qué protocolo central de transporte de Internet rediseñaría?
  1. ¿Qué modificaciones harías?
  1. Sin citar modificaciones existentes en el tablero de dibujo.
  2. Sin hacer referencia a ajustes en la tubería de estándares.
  • ¿Cuál es la mejor manera de maximizar el rendimiento de sincronización de una aplicación de servidor cuando el tiempo de llenado de la solicitud es menor que el tiempo de llegada de la solicitud?
    1. ¿Cómo cambiaría su respuesta si esa suposición fuera falsa?
  • ¿Cómo sería su diseño para un protocolo API?
    1. ¿Por qué su diseño sería mejor o peor que las alternativas estandarizadas actuales?
  • ¿Fue bueno o malo hacer HTTP sin estado?
    1. Explica tu respuesta
  • ¿Cuáles son los mayores obstáculos de la pila para aumentar el rendimiento?
    1. ¿Cómo propondrías resolver los obstáculos?
    2. ¿Es la velocidad de la luz uno de los problemas?
    1. ¿Por qué?
    2. ¿O por qué no?