¿Por qué el uso de abstracciones (como LINQ) es tan tabú? [cerrado]

60

Soy un contratista independiente y, como tal, entrevisto 3-4 veces al año para nuevos conciertos. Ahora estoy en medio de ese ciclo y me rechazaron por una oportunidad, aunque sentí que la entrevista salió bien. Lo mismo me ha pasado un par de veces este año.

Ahora, no soy un chico perfecto y no espero ser una buena opción para cada organización. Dicho esto, mi promedio de bateo es más bajo de lo habitual, por lo que cortésmente le pedí a mi último entrevistador algunos comentarios constructivos, ¡y él respondió!

Según el entrevistador, lo principal era que parecía inclinarme demasiado hacia el uso de abstracciones (como LINQ) en lugar de hacia algoritmos de menor nivel y de crecimiento orgánico.

En la superficie, esto tiene sentido; de hecho, también tiene sentido que los otros rechazos tengan sentido porque también parloteé sobre LINQ en esas entrevistas y no parecía que los entrevistadores supieran mucho sobre LINQ (a pesar de que eran .NET chicos)

Así que ahora me queda esta pregunta: si se supone que debemos estar "parados sobre los hombros de gigantes" y usar abstracciones disponibles para nosotros (como LINQ), ¿por qué algunas personas lo consideran tan tabú? ¿No tiene sentido sacar el código "de la plataforma" si logra los mismos objetivos sin costo adicional?

Me parece que LINQ, incluso si es una abstracción, es simplemente una abstracción de los mismos algoritmos que uno escribiría para lograr exactamente el mismo fin. Solo una prueba de rendimiento podría decirle si su enfoque personalizado fue mejor, pero si algo como LINQ cumplió con los requisitos, ¿por qué molestarse en escribir sus propias clases en primer lugar?

No quiero centrarme en LINQ aquí. Estoy seguro de que el mundo JAVA tiene algo comparable, solo me gustaría saber por qué algunas personas se sienten tan incómodas con la idea de utilizar una abstracción que ellos mismos no escribieron.

ACTUALIZAR

Como señaló Euphoric, no hay nada comparable a LINQ en el mundo Java. Entonces, si está desarrollando en la pila .NET, ¿por qué no siempre intenta usarla? ¿Es posible que las personas simplemente no entiendan completamente lo que hace?

Matt Cashatt
fuente
8
Creo que no sabes qué es la "abstracción", porque LINQ no tiene nada que ver con eso.
Eufórico
8
"Estoy seguro de que el mundo JAVA tiene algo comparable" En realidad, LINQ es una de las pocas cosas que tiene .NET y Java no.
Eufórico
42
@ Eufórico: ¿LINQ no abstrae el trabajo de nivel inferior de tareas como la clasificación y el filtrado, por ejemplo? Estoy bastante seguro de que habría algún código adicional detrás, objectCollection.Where(oc=>oc.price > 100)por ejemplo. ¿No sería eso un uso de una abstracción? Quizás puedas decirme lo que me estoy perdiendo aquí. . .
Matt Cashatt
37
Siempre existe la posibilidad de que simplemente no entiendan LINQ y no vean el valor de aprenderlo. Los aspectos funcionales de escribirlo son muy diferentes de la programación imperativa. Como contratista, en el año 2009 he visto desarrolladores Java "senior" que no entienden SQL lo suficiente como para escribir consultas avanzadas, por lo que pasan semanas optimizando el código que trae todos los datos al lado de Java y los filtra con código Java en lugar de tener la base de datos haciéndolo. La ignorancia es rampante en la industria del desarrollo de software.
18
Si entiendes LINQ pero tus entrevistadores no, eres mejor que ellos. Pon tus ojos más altos.
Jay Bazuzi

Respuestas:

74

No creo que sea objetable el uso de abstracciones per se. Hay otras dos posibles explicaciones. Una es que todas las abstracciones tienen fugas en un momento u otro. Si da la impresión, correcta o no, de que no comprende los fundamentos subyacentes, eso podría reflejarse mal en una entrevista.

La otra explicación posible es el efecto fanboy. Si habla con entusiasmo sobre LINQ y lo menciona repetidamente en una entrevista con una compañía que no lo usa y no tiene planes actuales para hacerlo, da la impresión de que no estaría satisfecho o incluso disgustado por trabajar con tecnologías más antiguas. También puede dar la impresión de que su entusiasmo por un producto lo ha cegado a las alternativas.

Si realmente cree que sería feliz en una tienda no LINQ, trata de preguntarle acerca de lo que no usan, y adaptar sus respuestas en consecuencia. Muéstreles que, si bien prefiere LINQ, es competente en el uso de las herramientas disponibles.

Karl Bielefeldt
fuente
44
@MatthewPatrickCashatt No puede editar y continuar en el depurador dentro de los métodos que contienen instrucciones linq. No es suficiente un desvío que no lo uso; pero fue la razón principal por la que dudé en hacerlo por un tiempo.
Dan Neely
3
+1, especialmente para el segundo párrafo. Me aplica totalmente, ya que sería completamente infeliz trabajar en un código C # sin poder usar LINQ.
Arseni Mourzenko
55
También está el hecho de que con frecuencia hay un impacto en el rendimiento además de la abstracción con fugas. Está cambiando la facilidad de uso por la precisión, y esa pérdida de precisión con frecuencia incluye detalles que acelerarían las cosas. Y cuanto más alejado esté de la fuente, más detalles perderá y mayor será la probabilidad de que esos detalles sean importantes para el rendimiento.
jmoreno
66
+1 pero también puede funcionar al revés. Si alguien me dice que no me contrataron porque uso Yacc para construir analizadores en lugar de rodar el mío, entonces no es un lugar en el que quiera trabajar de todos modos.
Spencer Rathbun
55
@MatthewPatrickCashatt: esta respuesta (y mi comentario al respecto) no son específicos de LINQ, sino declaraciones generales. Pero para LINQ, aquí hay un extracto de C # 4.0 / 5.0 en pocas palabras, que habla sobre problemas de rendimiento con LINQ. Volviendo a las generalidades: en muchos casos el éxito en el rendimiento valdrá la pena, 5% +/- es irrelevante. Pero a veces será más grande y otras, incluso .1% es inaceptable. Si no cree que pueda haber un problema, o que el rendimiento sea solo para empresas como Google ...
jmoreno
29

Algunos programadores .NET, particularmente aquellos que provienen de un fondo clásico de VB / ASP o C ++, no les gustan las cosas nuevas como LINQ, MVC y Entity Framework.

Según lo que he observado, es probable que los ex VB'ers de este grupo sigan utilizando capas de acceso a datos y otro código originalmente escrito hace más de 10 años. También usarán palabras de moda antiguas como "n-tier" y similares, y realmente no entenderán nada más allá de .NET Framework 2.0 ni quieren aprender nada al respecto.

Los C ++ tienden a ser programadores académicamente orientados que aman codificar algoritmos geniales, incluso si eso significa reinventar la rueda. Odian depender de cualquier cosa que no hayan entregado ellos mismos. Algunas de estas personas también se deleitan en hacer que los entrevistados se sientan inferiores, especialmente aquellos con antecedentes menos tradicionales.

Es probable que te encuentres con organizaciones como esta cuando estés entrevistando. Pero también se encontrará con algunos que están usando métodos más nuevos. No dejes que algunas malas entrevistas te desanimen.

jfrankcarr
fuente
2
Gracias jfrankcarr. Sospeché que este podría ser el caso: ¡había preguntas sobre abrir y cerrar datareaders!
Matt Cashatt
2
+1 por llamar a MVC "cosas nuevas". Me hizo reír a carcajadas. Ha existido desde los años 70. Es posible que haya querido decir MVVM, que es esencialmente MVP (una variante de MVC) que utiliza enlaces.
14
@ GlenH7 Creo que estaba bastante claro por contexto que se refería al producto "ASP.NET MVC", no al concepto básico de Modelo-Vista-Controlador.
Carson63000
44
@ GlenH7 - Estaba hablando completamente dentro del contexto de la línea de productos .NET y Visual Studio y las palabras de moda de los productos de Microsoft.
jfrankcarr
66
Dios mío, ¿hay realmente tiendas que piensen en Linq como "nuevo"? Ya ha existido por más de 4 años. Puedo entender no haber alcanzado a los que esperan tareas, o el uso de dynamic/ ExpandoObject/ etc., o no preocuparme por Azure y todas las demás cosas de la nube ... Incluso puedo entender continuar usando la vista de WebForms de la vieja escuela motor en MVC o Web Forms en sí, o escribir código WPF / WinRT sin MVVM ... pero Linq? Si aún no lo ha descubierto, es hora de dejar su trabajo como desarrollador de .NET.
Aaronaught
16

Microsoft tiene una larga historia de presentar nuevas tecnologías y luego olvidarse de ellas 5, 10 o 20 años después. LINQ podría parecer otro para algunas personas. Notarán que Microsoft no puede desaprobar SQL, pero LINQ podría estar siguiendo a Silverlight . Por lo tanto, podría estar viendo paranoia como resultado de una experiencia dura, o simplemente personas que han sido dejadas atrás por la tecnología moderna y que se resienten de ella.

RalphChapin
fuente
12
Honestamente, aunque veo el punto básico, no creo que Linq vaya a desaparecer pronto. Linq2SQL, sí, lo desaprobaron en favor del EF mucho más potente. Pero Linq en sí mismo es la base de tantas otras novedades brillantes en los últimos 3 lanzamientos de .NET que, si lo desaprobarían, estarían deshaciendo la mitad de su nueva tecnología de capa de persistencia como Azure y EF, por no mencionar prácticamente todos los ORM. por ahí y un montón de procesamiento de listas en memoria además.
KeithS
66
espera ... "aterrorizado de alejarse de la tecnología antigua y anticuada, porque funciona" ... WTF. Hemos llegado al punto en que las cosas de trabajo que se prueban, prueban, son comprensibles y mantenibles, y maduras NO son buenas.
gbjbaanb
77
@ gbjbaanb - No. Pero, como anécdota, ¿le gustaría que un médico diagnostique sus dolores en el pecho con una radiografía de tórax porque ese método es 'probado, probado, comprensible' o desearía una resonancia magnética de resonancia magnética que sea más nueva, pero que venga con una resolución más alta , mejor pronóstico y más información? Nadie dice alejarse de los principios clásicos aquí; todo lo contrario. Verá, LINQ (como ejemplo) se basa en esos principios. Creo que, como otros han mencionado, es el aprendizaje de las partes lo que hace que LINQ y su uso adecuado causen los momentos 'WTF' como el suyo.
Matt Cashatt
2
@MatthewPatrickCashatt: depende, si el médico no ha sido entrenado para leer los resultados de fMRI, tomaría la radiografía en lugar de hacer que adivine un diagnóstico. Si me enfermaba en un remanso, preferiría tener un médico que pudiera diagnosticar nada más que un estetoscopio que no pudiera hacer frente sin lo último en herramientas más recientes.
gbjbaanb
2
@MatthewPatrickCashatt Entiendo tu punto, pero un factor de equilibrio es que no quieres seguir cada tendencia solo porque es más nueva. Felizmente seguiré una nueva tecnología que encaja en una de dos categorías. 1. Me emociona y estoy dispuesto a pasar mi tiempo libre en ello. 2. Demuestra ser realmente mejor y parece que durará lo suficiente como para que valga la pena la inversión. Las tendencias que no encajan en una de las dos categorías son una apuesta en el mejor de los casos.
TimothyAWiseman
15

¿No tiene sentido sacar el código "de la plataforma" si logra los mismos objetivos sin costo adicional?

Siempre hay un costo extra.

La curva de aprendizaje para las cosas listas para usar siempre está ahí. El dolor de recibir actualizaciones (y dependencias) siempre está ahí. La incapacidad de atornillar las tripas siempre está ahí.

Para LINQ, el primero solo se aplica realmente. Muchas personas consideran que el código de aspecto 'extraño' es difícil de leer y más difícil de depurar. La sintaxis tipo sql es prácticamente una persona no grata en cada concierto profesional que he trabajado desde que salió. LINQ to SQL (y otras fuentes de datos) tienen varias trampas y opciones de optimización limitadas.

Estos son los argumentos generales contra herramientas de terceros y LINQ específicamente. Dicho todo esto, LINQ es una herramienta muy útil y debería preferirse en la mayoría de las situaciones. El llanto no inventado aquí, y las abstracciones no deben ser favorecidas, huele fuertemente a la disonancia cognitiva .

No saben / no pueden aprender LINQ, pero son "obviamente" buenos desarrolladores, por lo que LINQ no debe valer la pena. Es una trampa común.

Telastyn
fuente
1
Buenos puntos. Acuerde los costos que menciona y es una buena aclaración. Sin embargo, en términos más generales, el desarrollo de clases de cosecha propia con las que ningún empleado nuevo puede estar familiarizado porque no existen fuera de la organización presenta los mismos desafíos además del costo del desarrollo primario.
Matt Cashatt
2
@MatthewPatrickCashatt - Oh, por supuesto. Ese código interno debería, por lo tanto, casi siempre ser más esfuerzo para la misma victoria, pero no necesariamente. Como muchas otras cosas, el costo / recompensa debe ser estimado y la mejor práctica preferida , no seguida a ciegas.
Telastyn
@Telastyn El código interno también es bueno, ya que sabes lo que hace y puedes solucionarlo en cualquier momento. Además, puede optimizar para circunstancias específicas en función de su propio uso, no un promedio de todos.
Hawken
13

Otra cosa que debes considerar es que tu entusiasmo por una nueva tecnología genial simplemente puede hacer que las personas se sientan incómodas y no te quieran. No los estás "empoderando", porque eres tú quien conoce esta tecnología, no ellos. Incluso si ellos mismos no se dan cuenta, pueden estar buscando candidatos que refuercen lo que ya han invertido tanto tiempo.

Desea presentar una actitud que diga: "Lo que sea que esté haciendo, quiero ayudarlo a lograrlo", en lugar de dar un subtexto que diga: "Puede que esté haciendo las cosas mal, y tenerme cerca demostrará eso."

John Wiegley
fuente
+1 - además de decirles lo que sabes, pregúntales qué están haciendo y en qué se especializan.
Kirk Broadhurst
12

Mi opinión sobre esto (y TBH, supongo porque ninguno de nosotros puede decir lo que pensaban esos entrevistadores) es que a menudo vas a una entrevista para explicar por qué deberían contratarte para encajar con su equipo, su forma de trabajar .

Puedes ser el desarrollador perfecto, un dios del código de inicio de rock, pero eso no significa absolutamente nada si lo que quieres hacer (enfatizado por hablar en exceso y con demasiado entusiasmo sobre algunos gubbins de tecnología genial) simplemente les dice acerca de ti, y que no lo harías encajan con lo que quieren. Si tienen un sistema de acceso a datos antiguo, que no puede actualizarse por cualquier razón, no necesitan a alguien que haya olvidado cómo mantenerlo. Si están desarrollando cosas nuevas y realmente quieres poner esa nueva tecnología genial en todas partes, entonces es obvio que tendrán un gran problema con el mantenimiento de código futuro y / o la capacitación del personal.

Como profesional independiente, este es un problema mucho mayor que si estuvieran contratando a un permie. Con un permiso permanente, la capacitación y el desarrollo de nuevas formas de trabajo no son malas, dentro del alcance del código y las prácticas existentes: estará allí durante mucho tiempo para mejorar las cosas. Con un profesional independiente, realmente no le importa lo que quieres, estás allí solo para hacer su trabajo de la manera en que quieren que se haga, y no es tu trabajo hacer otra cosa. (en desacuerdo - conviértase en un empleado permanente)

Probablemente no tenga nada que ver con LINQ en sí, rechacé a un candidato que apareció y le explicó cuánto mejor se escribiría todo en Haskell. Nosotros no hacemos Haskell. Lo mismo se aplica a cualquier tecnología que no sea utilizada por la compañía, generalmente no es un problema si la mencionas como algo bueno. El problema surge cuando eres demasiado entusiasta y entusiasta.

gbjbaanb
fuente
2
Estoy de acuerdo con esto, pero he notado que hay muchas más personas que usan esta actitud para descartar buenas ideas que simplemente no entienden (por ejemplo, pruebas, patrones de diseño, ORM). Entonces, si bien estoy de acuerdo en que ser una buena opción para el equipo es algo bueno, es importante darse cuenta de que podría ser mejor que el resto del equipo y que debería encontrar personas con ideas afines en las que no sea malo saber bien abstracciones
Wayne Molina
1
@WayneM seguro, pero el OP es un profesional independiente, por lo que realmente no importa si es un dios de la codificación, a menos que estén preparados para contratarlo permanentemente para mantener el código que el resto del equipo no entiende (hmm) entonces él necesita hacer lo que ellos quieren, no lo que él quiere.
gbjbaanb
1
@WayneM del mismo modo, mucha gente usaría algo similar a lo que acaba de decir para promover sus ideas sobre las de otra persona (confiando en que con quién están hablando simplemente no lo entiende). Al final, ambas partes están sesgadas, pero el OP se trata de ser contratado, no de ganar la gran guerra de bricolaje / abstracción. Todos tendrán su propia opinión, pero alguien tiene que superarla; Supongo que no será el empleador en este caso. :(
Hawken
10

Hay una preocupación válida que he escuchado de aquellos que no usan Linq, y es una que tomo muy en serio: "El hecho de que no pueda ver la implementación no significa que no sea costosa".

Tome el siguiente fragmento:

var resultList = inputList.Where(i=>otherInputList.Count(o=>o.Property == i.OtherProperty) > 0);

Los iniciados por LINQ aquí son estremecedores. ¿Por qué? Porque el hecho de que este código se vea agradable y elegante no significa que no sea terriblemente ineficiente. Count (), con un predicado, evalúa cada elemento de su padre enumerable y resume las veces que el predicado devuelve verdadero. Entonces, esto no solo es N ^ 2 (cuando inputList y otherInputList tienen una cardinalidad N aproximadamente igual), es el peor caso absoluto N ^ 2; CADA elemento de otherInputList se recorre para CADA elemento de entrada. En cambio, el primer paso es usar Any () en lugar de Count, porque eso es realmente lo que quieres saber, y se cerrará tan pronto como se sepa que la respuesta es "sí". Configurar un HashSet que almacena valores distintos de otherInputListObject.OtherPropertypodría ayudarte también; el acceso se convierte en O (1) en lugar de O (N),complejidad del peor de los casos en lugar de la complejidad cuadrática del mejor de los casos .

Por lo tanto, vemos que estos métodos elegantes y agradables tienen costos importantes detrás de ellos, y si no sabe cuáles son esos costos, puede codificar fácilmente un algoritmo de complejidad O (mi GD) en el administrador de archivos central de alto rendimiento de su posible empleador o la página principal del portal de aterrizaje la próxima vez que necesiten un ajuste. Despidiéndote después de hacer eso no deshace lo que hiciste, pero no contratarte si piensan que lo harías lo evitaría. Entonces, para evitar esto, debes demostrar que están equivocados; discuta qué hacen esos métodos (lo que significa que debe conocerse a sí mismo) y su complejidad, y cómo llegar a la respuesta en un tiempo eficiente (NlogN o mejor).

Otra preocupación es el viejo argumento "Cuando tu única herramienta es un martillo". Ponte en el lugar del entrevistador que entrevista a este fanático de Linq. Al candidato le gusta Linq, quiere usarlo, piensa que es lo mejor. Incluso podría parecer que el candidato no podría codificar sin él, ya que todos los problemas de programación dados se resolvieron con Linq. Bueno, ¿qué pasa cuando no se puede usar? Todavía hay un montón de código .NET 2.0, que si se actualizara requeriría actualizaciones dolorosas para servidores, estaciones de trabajo de usuarios, etc., todo para que pueda usar sus sofisticados métodos de extensión. Como entrevistador, trataría de hacer que demuestre que puede codificar una clasificación eficiente o usar los métodos de clasificación 2.0 si fuera necesario, sin importar cuánto esté de acuerdo con usted en que las bibliotecas Linq y los métodos de extensión similares son bastante dulce. Es posible que un entrevistador que no ve el punto ni siquiera se moleste en intentar que muestre aptitud para cualquier otra cosa; Asumirán que no lo tienes y seguirán adelante.

KeithS
fuente
¿Por qué no escribirías tu consulta como var resultList = inputList.Select(i=>i.Property).Intersect(otherInputList.Select(o=>o.Property));? Es posible que haya fallado eso, pero mi punto es que LINQ tiene mejores formas de ejecutar la consulta que mencionas anteriormente (.Join () es otra forma). Me doy cuenta de que hay formas de usar LINQ que pueden no ser tan competentes como otras formas, pero eso no significa que tenga que confiar en esas malas implementaciones.
Matt Cashatt
44
@MatthewPatrickCashatt No creo que su punto sea tanto para afirmar que LINQ siempre es ineficiente, aunque siempre se puede superar una consulta LINQ dada, algunos usos dan un mejor rendimiento por hora de desarrollador que muchos enfoques que no son LINQ. Por el contrario, puede ser relativamente fácil escribir una consulta LINQ que sea ineficiente y no darse cuenta, porque las ineficiencias no son tan evidentes.
Jon Hanna
3
@ JonHanna: Tal vez más al punto, el valor de una abstracción se reduce enormemente si uno debe examinar qué código está "realmente haciendo" para determinar qué escenarios poco comunes pero plausibles podrían causar que el rendimiento sea mucho mayor de lo esperado. Si cambiar de una estructura de datos a otra hará que el código se ejecute 10,000 veces más lento, la capacidad de realizar dicho cambio sin alterar ningún otro código puede no ser siempre algo bueno.
supercat
1
@supercat: sí y no. El hecho de que el conocimiento de cómo se hace algo en una implementación de terceros es fundamental para comprender las implicaciones de rendimiento y evitar ineficiencias, no significa que las bibliotecas que encapsulan estas herramientas tengan menos valor. Son las dos caras de la misma moneda; conozca la naturaleza de la implementación, y puede usarla con unas pocas teclas en lugar de una hora haciendo las suyas. Pero, tienes que conocer ambos lados, y el fanático estereotipado de Linq que piensa que es perfecto, nada de malo, úsalo para todo lo que probablemente no.
KeithS
@KeithS: Una cosa que creo que tanto falta en Java y .net es un medio estándar para preguntar a los objetos o colecciones varias cosas sobre sí mismos. Por ejemplo, el código que recibe una colección enumerable podría beneficiarse al saber si el número de elementos y / o la secuencia de elementos existentes podría cambiar, si se sabe que el número de elementos es finito o infinito (o no se sabe de ninguna manera), y si la colección sabe de manera inherente cuántos elementos contiene. Las tecnologías como LINQ a menudo tienen que hacer suposiciones sobre cosas que pueden o no ser correctas, y ...
supercat
10

Este se hizo un poco largo, pero podría ser útil para alguien, así que lo dejaré ser.

En realidad encontré algo similar, pasando por un poco más de 20 entrevistas el mes pasado (una combinación de teléfono y cara a cara). Definitivamente sucedió algo inesperado que no pude identificar.

Sin embargo, una de las cosas que noté fue que las cosas que generalmente han sido el punto central de los ciclos de entrevistas de los últimos cinco o seis años decididamente no se discutieron ni se les dio poca importancia. Cosas como los fundamentos del análisis / diseño de OOP, patrones (diseño y arquitectura, ambos), algunas de las características .net más avanzadas / orientadas a la abstracción (incluidas lambdas o LINQ específicamente, genéricos, serialización / enlace de datos y similares), e incluso el Por lo general, tema candente de la metodología preferida (a nadie parecía importarle mucho lo ágil frente a la cascada o qué sabor de ágil) y las herramientas o la elección de ORM o los medios preferidos de colaboración o gestión de control de fuente. En algunos casos no se menciona en absoluto, en casi todos los casos aparentemente no preocupan.

Lo que sí recibió atención, en múltiples entrevistas y en varias empresas no relacionadas en industrias no relacionadas, fue en este sentido:

  • Una extraña fijación en convenciones anticuadas / anticuadas y limitaciones de "volver a la edad de piedra". Como desarrollar una aplicación web primitiva en VS2003 con una lista de restricciones absurdas que prohíben aún más el uso de características explícitas dentro de esa era de .net ... como si eso fuera un indicador real de la capacidad de un desarrollador moderno ... la capacidad de recordar El paradigma y las limitaciones de hace 9 años quedaron paralizados por limitaciones poco realistas / arbitrarias. Otro lugar fue muy obstinado sobre el tema de las colecciones personalizadas, alrededor de las colecciones pregenéricas. Otro lugar creó una muestra de código de un modelo de clase que garabateé porque no utilicé constructores en cascada (parecían ignorar el soporte para la inicialización de propiedades en la declaración, que era suficiente para la necesidad).

  • Enfoque extremo en detalles de implementación específicos en un microcosmos y / o ajustes de configuración, incluso en el caso de tecnologías que se enfocan en ser independientes de la plataforma o el protocolo (es decir, el punto principal NO debe fijarse en una implementación específica o uso particular, sino más bien sobre reutilización / reutilización / extensibilidad / según la integración necesaria).

  • Disponibilidad para especificar / supervisar / revisar el código / y, de lo contrario, desconectar el trabajo hacia y desde un equipo off-shore, y habilidades no relacionadas con la codificación relacionadas con hacerlo.

  • Uso de versiones específicas de productos / plataformas / módulos / etc. Hasta un grado a veces absurdo; "Entonces ... ¿has usado las versiones 1, 2 y 4? Pero no 3, ¿eh? Hmmm ... {anota tu currículum con" no v3 !!!} ". El grado de uso no parecía importar; solo que ha usado o no ha usado algo en absoluto , y lo específico que están pidiendo también ... ninguna sustitución parecía contar, incluso de un producto de la competencia más ampliamente utilizado y con más funciones.

  • Un enfoque mucho mayor en "qué tan bien encajará en nuestro equipo" sobre "si realmente es bueno como desarrollador de software" o "¿tiene las habilidades y la experiencia para agregar valor a la empresa y ayudarnos a ofrecer una calidad producto "o incluso" eres un idiota peligroso que entrará y destrozará la tienda ". En algunos casos, mi currículum simplemente se tomó como un hecho, e incluso la llamada "pantalla técnica" o entrevista técnica fue una evaluación de la personalidad mucho más que una evaluación de habilidades. Incluso para puestos de contrato a corto plazo en los que estaría allí y volvería antes de que hayan cambiado dos temporadas.

  • Esta vez, las empresas parecían centrarse mucho menos en resolver problemas técnicos específicos, comenzar nuevos proyectos de desarrollo de campo verde o grandes 2.0, o llevar un producto específico al mercado para capitalizar una tendencia u oportunidad emergente, o las grandes patadas iniciales habituales . Un tema repetitivo que noté al menos en 15 de los lugares fue que un pequeño grupo de 3-5 desarrolladores, en su mayoría sobrevivientes del colapso del mercado en 08, pudieron elaborar un producto en el transcurso de los últimos 3 años más o menos. y encontraron cierto éxito o su empresa en su conjunto está en auge y están contratando a nuevas personas para mantenerse al día con las crecientes demandas de características o para abordar / superar los defectos de diseño que incorporaron en estos sistemas, o para hacerse cargo de las plataformas antes mencionadas para liberar hasta el equipo central que lo creó para hacer "otros proyectos".

Pero ... si hay algo que sé sobre este negocio es que es cíclico. La próxima vez que busque un nuevo concierto, no me sorprenderá si el juego ha cambiado una vez más. Solo tiene que permanecer mentalmente flexible, escuchar activamente, evitar hacer declaraciones absolutas si son innecesarias, pero tampoco ser una comadreja y no parecer unidimensional (usted viene como un idiota o un fanático, ni deseable) o como demasiado bueno (puede ser amenazante y costarle un concierto).

Simplemente ajuste su enfoque e intente dar una respuesta más mesurada la próxima vez ... mencione algunas formas diferentes en que podría abordar un problema ... pero incluso si se trata de un conocimiento memorístico, actúa como si realmente estuviera pensando en ello y razonándolo en el acto. Parece más humilde y menos intimidante o ofensivo de esa manera.

Por supuesto, la ley de Murphy siendo lo que es, la siguiente entrevista después de que deje de ser "un apasionado de mi actual tipo de tecnología favorita" y adoptar una postura más equilibrada / barba de acariciar es el concierto que le han metido te fuese el loco fanático ;)

Experiencia reciente similar
fuente
6

Creo que está sacando una conclusión falsa, porque su conjunto de muestras es demasiado limitado. Aunque he visto una buena cantidad de tiendas de TI con fuerte aversión a cualquier cosa "no inventada allí" 1 , ninguno de ellos descalificaría a los candidatos en función de sus preferencias en la pila de tecnología: estaban legítimamente convencidos de que podían enseñar al candidato correcto a usar sus bibliotecas locales.

Dudo seriamente que la compañía haya prohibido el uso de LINQ directamente. Lo más probable es que quisieran que les mostraras tus habilidades a un nivel más profundo.

Por ejemplo, una forma de averiguar si conoce sus tablas hash es pedirle que implemente una primitiva en una pizarra. Este simple ejercicio revela una sorprendente cantidad de datos sobre su conocimiento al revisor: él aprende instantáneamente si sabe acerca de los códigos / iguales de hash, y lo que sabe sobre las colisiones de hash. Al mismo tiempo, es difícil imaginar que alguien en su sano juicio vuelva a implementar una tabla hash, porque Microsoft hizo un buen trabajo en ello. Lo mismo ocurre con muchos algoritmos, como ordenar y buscar: a los entrevistadores a menudo les gustaría saber si su experiencia es suficiente para comprender las interacciones de bajo nivel, en lugar de verificar que tiene un conocimiento práctico de las bibliotecas .NET.

Es casi seguro que insistirán en que use implementaciones de biblioteca en lugar de la suya una vez que lo contraten para trabajar para su empresa. Pero durante la entrevista lo empujarían hacia el código de bajo nivel para obtener una mejor comprensión de sus verdaderas habilidades.


¡ Una tienda llegó a construir su propia herramienta de construcción bastante primitiva!

dasblinkenlight
fuente
2
Todos sus puntos están bien formulados, pero debería darle algo de color en la última entrevista: el entrevistador insistió en que LINQ estaba "en desuso". Le pregunté: "no quiere decir que MS ya no va a invertir en Linq-to-SQL, sino que Linq-to-Entities estará cerca" y su respuesta fue que quiso decir lo que dijo: LINQ está "en desuso" así que no, no creo que él supiera demasiado sobre LINQ o insistiría en su uso.
Matt Cashatt
1
@MatthewPatrickCashatt Si alguien confundió LINQ por LINQ2SQL en términos de la tecnología en desuso, habría inventado una excusa tonta para abandonar la entrevista antes de tiempo, y nunca volví a llamar a esa compañía. Si ese fuera el caso, deberías estar feliz de que no te
contraten
1
100% seguro de que ese era el caso. De hecho, no pude resistirme a enviarle algunos enlaces para ponerlo en el camino correcto en el tema, no como un golpe porque no conseguí el concierto, sino porque realmente me sentí avergonzado por él y esperaba poder hacerlo. ayudarlo a no cometer el mismo error dos veces;).
Matt Cashatt
44
Entonces esto parece tener menos que ver con la pila de tecnología y más con el hecho de que lo corrigió. A la gente no le gusta que la corrijan. Es solo la naturaleza humana. Cuando las personas toman decisiones como la contratación de personas, el 99% irá con su intuición. Pasan por si les hiciste sentir emociones positivas o negativas o no. Corregirlo puede haberle hecho sentir emociones negativas. Y luego asocia esa negatividad con la situación.
codificador
1
No sé cómo funcionan las tablas hash internamente. Pruebas técnicas profundas como esa arrojan a personas con una formación práctica que son buenas candidatas. Requerir que las personas tengan un conocimiento de bajo nivel que nunca usarán me parece innecesario. ¡Los principios de diseño se han vuelto mucho más importantes!
Tjaart
4

Creo que estás haciendo algunas generalizaciones locas del tipo "Vi una vaca negra en Escocia, así que todas las vacas escocesas son negras".

Si te entrevistara, me decepcionaría si no pudieras responder mis preguntas linq.

Sin embargo, Linq es complicado, mucha gente lo ve como vudú, lo cual es injusto, ya que en realidad es muy simple y aún más inteligente.

Ian
fuente
3

Para jugar al abogado del diablo, la razón es que muchos desarrolladores simplemente no se preocupan por las cosas nuevas y piensan que todo tiene que resolverse con herramientas propias (generalmente inferiores). No hay nada de malo en usar abstracciones. Demonios, generalmente no hay una buena razón para no usar esas abstracciones.

Parece que se entrevistó con un desarrollador pobre que no se mantiene al día con las cosas y adopta el enfoque de martillo y clavo para todo. Estos son los tipos de desarrolladores que no saben nada sobre herramientas útiles de código abierto como NUnit, o NHibernate, o los diversos contenedores de IoC; los que intentan resolver cada problema con un proceso masivo almacenado en la base de datos; los que no saben absolutamente nada sobre MVC a pesar de estar fuera desde hace varios años.

Wayne Molina
fuente
Puede lanzar LINQ en un grupo de palabras de moda que contenga Nhibernate, etc. No haría eso. En realidad, creo que las palabras de moda ejemplifican nuestra incapacidad para explicar las abstracciones en expresiones adecuadas.
AndreasScheinert el
Estás hablando de "estar al día", creo que lo inverso sería mucho más apropiado. Muchos conceptos útiles se han descubierto y utilizado en el pasado, por ejemplo, DSL. Depende de nosotros mejorar nuestra comunicación y comprensión de conceptos tales como que no necesitamos inventar nuevas palabras de moda para conceptos antiguos.
AndreasScheinert el