¿Por qué la pregunta "da cinco cosas que odias de C #" es tan difícil de responder durante una entrevista? [cerrado]

En el podcast 73 , Joel Spolsky y Jeff Atwood discuten, entre otros temas, "cinco cosas que todos deberían odiar sobre su lenguaje de programación favorito":

Si está satisfecho con su cadena de herramientas actual, entonces no hay razón para cambiar. Sin embargo, si no puede enumerar cinco cosas que odia de su lenguaje de programación favorito, entonces sostengo que aún no lo sabe lo suficientemente bien como para juzgarlo. Es bueno estar al tanto de las alternativas y tener un ojo crítico saludable para lo que sea que esté usando.

Siendo curioso, hice esta pregunta a cualquier candidato que entrevisté. Ninguno de ellos pudo citar al menos una cosa que odian de C # ¹.

¿Por qué? ¿Qué es tan difícil en esta pregunta? ¿Es debido al contexto estresante de la entrevista que los entrevistados no pueden responder esta pregunta?

¿Hay algo en esta pregunta que lo hace malo para una entrevista?

Obviamente, no significa que C # sea perfecto. Tengo una lista de cinco cosas que odio de C #:

• La falta de un número variable de tipos en genéricos (similar a paramspara argumentos).
  Action<T>,
  Action<T1, T2>,
  Action<T1, T2, T3>,
        ⁞ En serio ?!
  Action<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15, T16>
  

• La falta de soporte para unidades de medida, como en F #.

• La falta de propiedades de solo lectura. Escribir un private readonlycampo de respaldo cada vez que quiero una propiedad de solo lectura es aburrido.

• La falta de propiedades con valores predeterminados. Y sí, sé que puedo inicializarlos en el constructor sin parámetros y llamarlo desde todos los demás constructores. Pero no quiero hacerlo.

• Herencia múltiple. Sí, causa confusión y no la necesita en la mayoría de los casos. Todavía es útil en algunos casos (muy raros), y la confusión también se aplica (y se resolvió en C #) a la clase que hereda varias interfaces que contienen métodos con el mismo nombre.

Estoy bastante seguro de que esta lista está lejos de estar completa, y hay muchos más puntos para resaltar, y especialmente mejores que los míos.

^{¹ Algunas personas criticaron algunos ensamblados en .NET Framework o la falta de algunas bibliotecas en el marco o criticaron el CLR. Esto no cuenta, ya que la pregunta era sobre el lenguaje en sí, y si bien podría aceptar una respuesta sobre algo negativo en el núcleo de .NET Framework (por ejemplo, algo así como el hecho de que no hay una interfaz común para TryParse, por lo tanto, si desea analizar una cadena a varios tipos, debe repetirla para cada tipo), una respuesta sobre JSON o WCF está completamente fuera de tema.}

Si tuviera que adivinar:

1. Algunos programadores carecen de una exposición lingüística diversa. Es difícil ver las cosas mal con el lenguaje cuando no sabes que existen cosas mejores.

2. Algunos programadores son simples monos de código. Apenas analizan los problemas frente a ellos, y mucho menos algo así como cómo su lenguaje de programación podría ser mejor.

3. Pocas personas son particularmente críticas. Ven beneficios y características, no deficiencias. Es difícil para ellos cambiar a ese modo de pensar si la entrevista no va de esa manera.

4. Al menos por aquí, ser demasiado crítico es visto como un defecto de personalidad fatal. En lugar de ser "ese desarrollador perspicaz que siempre está buscando mejores formas de hacer las cosas" (como algunas áreas en las que he vivido), son "ese imbécil que odia todo". Incluso las personas que pueden pensar en cosas que odian en el idioma pueden diferir en una entrevista para parecer menos mordaces.

Me imagino que la pregunta es tan difícil de responder durante una entrevista porque es:

1. Realmente inesperado

2. Requiere mucho pensar y pensar de una manera muy diferente a la utilizada durante una entrevista,

3. Es difícil responder en general en un corto período de tiempo (a menos que esté preparado antes de la entrevista).

1. Es inesperado

Las preguntas inesperadas son realmente difíciles, especialmente en un contexto estresante. Imagine el siguiente diálogo durante una entrevista:

- ¿Cuál es la diferencia entre HashSet<T>y List<T>?
- El hashset está optimizado de manera que la búsqueda de un elemento sea muy rápida. Por ejemplo, si está usando set.Contains()un ciclo muchas veces, mover la setlista de la lista al hashset puede acelerar las cosas.
- ¿Cómo se crea una propiedad de solo lectura?
- Uso un campo marcado como readonlycampo de respaldo para una propiedad que solo tiene un captador.
- ¿Cuál es el uso de sealed?
- Lo usas para clases que no deben ser heredadas.
- ¿Cuál es la última vez que has visto a un dentista?
- ¡¿Qué?!

2. Requiere mucho pensamiento diferente

Cuando se le hacen preguntas generales de tipo entrevista, está utilizando su memoria para recordar lo que aprendió de los libros o de su práctica sobre el lenguaje y el marco. Puede pensar un poco para encontrar una respuesta, pero no demasiado.

Por otro lado, la pregunta sobre las cinco cosas que odias requiere un pensamiento más profundo. No puedes recordar algo que has aprendido de los libros y no puedes encontrar nada por analogía. En lugar de ser pasivo, debes ser crítico y encontrar lo que podría ser desagradable en el lenguaje que usas.

3. Requiere tiempo

Francamente, tengo mi lista de cinco (en realidad más) cosas que odio de C #, pero lo pensé durante un largo período de tiempo. Algunas cosas son de la era de .NET Framework 2; La mayoría de los problemas que enumeré para .NET Framework 2 ya no son válidos porque se eliminaron, algunos con LINQ y todo este material de programación funcional, otros con programación dinámica. No estoy seguro si, sin preparar esta pregunta, sería capaz de encontrar los cinco elementos durante una entrevista.

Creo que es difícil por la palabra cinco . Y en menor grado, por la palabra odio .

Cinco ? ¿Qué pasa si solo se te ocurren cuatro? ¿Has fallado en responder la pregunta? ¿Qué pasa si tienes más de cinco? Ahora, en el acto, tienes que descubrir cuáles son los mejores cinco para usar.

Odio es una palabra muy negativa. Es el tipo de negatividad que se les dice a las personas que eviten en las entrevistas. Por otra parte, creo que sería sonar extraño a mucha gente a tener esa cantidad de cosas que "odio" sobre un lenguaje que va a pasar toda la programación de los días en algunas personas, incluso podría pensar que es una pregunta con trampa:. Si realmente no vienen con cinco cosas, serán descalificados por odiar demasiado a C # para programar bien. Desafortunadamente, este tipo de pregunta capciosa perversa no es desconocida en las entrevistas.

En cambio, podría preguntar ¿Qué mejoraría de C # si fuera por usted? Esto le permite al entrevistado responder con cualquier cantidad de cosas. Esta frase también cambia la negatividad de la palabra "odio" por el relativamente positivo "mejorar".

• La mayoría de los candidatos no están tan involucrados con más de un idioma o paradigma para contrastar . No he trabajado con otro lenguaje orientado a objetos durante más de 5 años, y en el que había estado trabajando (PowerBuilder), tenía muchode peeves con. La mayoría de los chicos recién salidos de la universidad son (o piensan que son) cosas interesantes en uno, tal vez en dos idiomas, y han recibido "exposición" a tres o cuatro más (lo que significa que completaron al menos una tarea que lo requiere pero menos de un semestre completo) por supuesto estudiándolo). Eso no es suficiente conocimiento o experiencia para saber realmente qué hay de malo en el idioma. Consigue un trabajo en el mundo real, y ese enfoque se reduce considerablemente; aprendes mucho más sobre el idioma que te da el sueldo que cualquier otro, y en el proceso, aceptas lo que el idioma no hará, o lo hace de una manera extraña, hasta el punto en que no puedas recordar haciéndolo de manera diferente.

• La mayoría de los candidatos expertos en C # que lo comparan con Java / C / C ++ están bastante contentos con él . C # se diseñó desde cero para hacer muchas cosas mejor que Java (eventos, devoluciones de llamada, biblioteca de gráficos, trabajo de base de datos). Java a su vez fue diseñado para ser más fácil de usar y, por lo tanto, más centrado en el código correcto, que C ++. Todavía tengo que encontrarme con un programador de C # que quiera volver a C ++ en cualquier entorno en el que el rendimiento vertiginoso y el control a nivel de circuito cercano no sean necesidades críticas.

En otras palabras, See-Sharpers lo tiene bastante bien, considerando todo.

Aquí está mi lista:

• Declaraciones de Lambda no observables / evaluables . Las llamadas a métodos con nombre se pueden conectar a QuickWatch de VS. Así pueden las expresiones. Pero lambdas? No (al menos no en VS2010). Hace que la depuración de cadenas de Linq sea una verdadera tarea.

• Los valores de parámetros opcionales para tipos de referencia que no sean cadenas solo pueden ser nulos . Si estuviera creando una pila de sobrecarga, es posible que desee utilizar otros valores predeterminados. Es posible que pueda predeterminar un valor basado en una propiedad o expresión simple basada en otro parámetro. Pero no puedo Por lo tanto, el valor de no tener que crear una pila de sobrecarga (que es menor con un asistente de refactorización como ReSharper para manejar la repetitiva) disminuye cuando las opciones para los parámetros opcionales son tan drásticamente limitadas.

• C # se está volviendo lo suficientemente viejo como para tener serios problemas de código heredado . El código escrito originalmente para 1.1 haría que cualquiera que estuviera acostumbrado a 4.0 se estremeciera de horror. Incluso el código 2.0 se pierde mucho. Al mismo tiempo, han aparecido bibliotecas de terceros que hacen que cosas como ADO.NET parezcan lamentablemente primitivas (y gran parte del "modelo conectado" de ADO.NET ahora es un gran antipatrón). Sin embargo, para la compatibilidad con versiones anteriores, .NET coquetea con el soporte para todo este código viejo y malo, sin atreverse a decir algo como "ArrayList fue una manera horrible de hacerlo, lamentamos haberlo introducido y estamos tomando fuera; use List en su lugar y si absolutamente necesita una lista de diferentes tipos, declare como List<Object>.

• Reglas de declaración de cambio seriamente limitadas . Probablemente una de las mejores cosas que podría decir sobre PowerBuilder es que la instrucción Choose Case (equivalente a cambiar) permitió expresiones booleanas basadas en la variable. También permitió que las declaraciones de cambio no se cumplieran incluso si tenían código. Entiendo las razones por las que no se permite ese segundo (es más probable que se haga de manera no intencional que a propósito), pero de todas maneras sería bueno escribir una declaración como esta:

  switch(someInt)
  {
      case < 0: //all negative values enter here
         //...
         break;
      case 0: 
         //...
         break;
      case 1:
         //...
         //no break; continue through to the code for > 1
      case > 1 // all positive values enter here (including 1)
         //...
         break;
  }

• Sin interfaz INumeric . Si es un número, puedes hacer cálculos matemáticos con él. En muchos casos, el método real no tiene que preocuparse exactamente de qué tipos están conectados; La precisión es responsabilidad de quien llama. Sin embargo, no es posible crear un método genérico o una clase que solo acepte tipos de números como GTP.

Sugeriría que parte del problema es el miedo a dar una mala respuesta: usted dice que odia a X, el entrevistador ama a X o cree que su razón para odiar a X es idiota, y dice que cree que está bien puede parecer la opción menos controvertida.

También es probablemente algo en lo que la mayoría de las personas realmente no han pensado mucho; tienen problemas actuales y problemas pasados, los problemas pasados ​​causados ​​por el lenguaje han terminado y la gente piensa principalmente en la solución y no en el problema, ya que eso fue más significativo, y pocos tendrán un problema actual causado por el idioma.

Para una entrevista, pediría solo 1 o 2, pero estoy de acuerdo, si no puede nombrar ninguna limitación de la herramienta que usa, entonces probablemente no lo sepa muy bien. Hacemos esta pregunta exacta sobre SSIS y realmente ayuda a separar el trigo de la paja; Todos los que hemos contratado que respondieron bien a esta pregunta se convirtieron en un gran empleado. Necesitamos personas que tengan conocimientos avanzados, no alguien que lo haya visto un par de veces. Y apuesto a que eso es lo que quieres también.

Creo que es una pregunta válida y el hecho de que muchos no pudieron responderla es solo un ejemplo de cuán pobres son en realidad muchos de los candidatos para puestos de trabajo. Si alguien no es lo suficientemente analítico como para poder resolver algunas limitaciones de la herramienta, ¿cómo van a ser lo suficientemente analíticas como para resolver problemas de programación difíciles?

Todo se reduce a lo que dijiste falta de experiencia en profundidad con C # y / o falta de exposición a otros idiomas. Entrevisté a varios desarrolladores que se consideraban senior y que no podían responder algunas preguntas que incluso un rasguño leve en la superficie de C # debería haberles revelado.

Sin cavar lo suficiente, no vas a llegar a los límites del idioma y desearías que se hubieran ido. Mis cinco mejores en caso de que alguien se pregunte

1. Los objetos inmutables requieren mucha ceremonia para crearse (a diferencia de un lenguaje funcional donde los objetos son inmutables por defecto).
2. La metaprogramación es difícil de hacer. Compare el tipo emitir con las macros Lisp. (Los servicios del compilador ayudarán mucho con esto en el futuro).
3. Los métodos de extensión son excelentes ... las propiedades de extensión y los operadores de extensión (específicamente los operadores implícitos y explícitos) serían mejores.
4. Los Casts explícitos se resuelven en tiempo de compilación en lugar de tiempo de ejecución.
5. No Sequence Matching es mucho más limpio que la sobrecarga de funciones.

Pienso en su ronda sobre la forma en que dice; Si crees que está roto, probablemente no entiendas por qué está como está. Puede haber un agujero en su conocimiento.

Irónicamente, los entrevistadores que piensan que están citando a "el gran Joel" al usar eso como una pregunta de entrevista probablemente están perdiendo el punto.

Pueden ser reacios a responder porque pueden tener la impresión de que si pueden enumerar 5 cosas que odian de un idioma, el entrevistador podría darse la vuelta y decir 'Oh, estamos buscando' ninjas 'de C # y usted no parece que le guste el idioma 'o' ¿Por qué solicitó el trabajo si no le gusta el idioma? '.

Los entrevistados están bajo mucha presión para mantenerse positivos durante las entrevistas.

Porque los idiomas dan forma a la forma en que pensamos . Al usar C # todos los días, ha tomado el hábito de pensar y diseñar su código de una manera que naturalmente resuelva los problemas del lenguaje.

Ahora lo haces sin pensar, sin siquiera saber que lo haces. Por eso es tan difícil señalar cuáles son las cosas malas. Sin duda, el día en que comenzó a aprender C #, encontró muchos problemas, pero ahora ya no los ve. Los hábitos son cosas poderosas. Hábitos de pensamiento, aún más .

El lado positivo de esto es que si le resulta difícil enumerar las fallas en C #, debe ser porque es un buen programador de C #, le gusta el idioma y lo usa más que otros idiomas.

Pero si desea ser más capaz de ver las fallas en C #, debe cambiar su forma de pensar. Aprende más lenguajes de programación y acostúmbrese a ellos. Apunta a los idiomas más diferentes posibles. ¿Estás acostumbrado a la escritura estática? Prueba Python o Ruby. ¿Estás acostumbrado a orientado a objetos e imperativo? Haskell es otro mundo completamente.

Y cuando vuelvas a C #, serás como, "¿Por qué necesito cien líneas de C # para hacer esta cosa simple que es solo una línea en Haskell?". Odiarás muchas cosas sobre C #.

• C # no tiene tipos de referencia no anulables.
• No hay tipos de datos algebraicos.
• Sin interpolación de cadenas.
• La sintaxis es demasiado detallada en todas partes.
• Sin sistema macro.
• La inferencia de tipos es limitada.
• No hay literales regexp.
• Sin tipificación estructural.
• Mal soporte para la inmutabilidad.
• Las estructuras de C # son propensas a errores.
• La biblioteca de colecciones estándar es muy limitada.
• No se pueden definir restricciones en los parámetros de los constructores.
• No se puede programar genéricamente con restricciones en los operadores matemáticos.
• No 'newtype'.
• Sin corte de matriz, sin rango literal.
• Las funciones no enumeran los efectos secundarios que pueden hacer como parte de su tipo. :)

(Por supuesto, ningún idioma puede tenerlo todo. El diseño del lenguaje es extremadamente difícil, y agregar todas las funciones al mismo idioma no puede funcionar. Diferentes herramientas para diferentes propósitos).

Sí, la pregunta es difícil de responder bien, especialmente durante una entrevista. Pero las personas que pueden responderlo prueban que lo han pensado, que tienen alguna perspectiva.