¿Qué tan importante es ser sintácticamente correcto durante una entrevista? [cerrado]

Al pedirle a un candidato de la entrevista que escriba un programa en la pizarra, ¿espera que el candidato escriba un código que sea sintácticamente correcto?

Tenía dos candidatos, uno de los cuales escribió un programa sintácticamente correcto, pero la lógica no estaba a la altura, y el otro tenía la lógica mejor escrita pero la sintaxis era una mierda.

Estoy a favor del primer candidato.

Yo preferiría a la persona que pudo razonar sobre el problema, encontrar una buena solución y luego explicarme su solución. Incluso si su lógica no fuera del 100%, si estuvieran en el camino correcto y estuvieran razonando el problema, haciendo las preguntas correctas y siguiendo el camino correcto, ese sería mi ganador.

Cuando desarrolla código en el trabajo, tiene muchas herramientas (IDE, compiladores, análisis estático, pruebas unitarias, prueba de integración y procedimientos de prueba de aceptación) para encontrar errores en la sintaxis y la lógica. Si está escribiendo en una pizarra blanca, no tiene estas herramientas y está obligado a cometer errores en la sintaxis (olvidando el nombre de un método, un punto y coma, una llave), y puedo perdonar eso.

Mi única pregunta para usted: ¿Por qué sus candidatos escriben código real en la pizarra, en lugar de centrarse en algoritmos, estrategias de diseño y pensamiento lógico? Los lenguajes de programación cambian, la resolución de problemas no.

Yo favorecería al segundo candidato. La lógica puede ser difícil ( muy difícil, a veces) para acertar exactamente . La sintaxis puede ser muy fácil de entender cuando el IDE y el compilador y otras herramientas variadas ayudan.

Es posible que el primer candidato nunca active un error de compilación, pero si su código a menudo falla en todo tipo de casos límite extraños (y menos extraños), su conocimiento de dónde colocar un punto y coma no vale tanto.

Dependiendo de los errores sintácticos reales, supongo que preferiría el segundo candidato , porque la verificación de la sintaxis generalmente es mejor dejarla en las máquinas .

Errores como la falta de punto y coma, el olvido de corchetes, el olvido de comas en listas de argumentos, etc., incluso los errores no sintácticos, como cambiar el orden de los argumentos al llamar a una función, generalmente quedan atrapados por el resaltador de sintaxis, el compilador o cuando el código se ejecuta la primera vez , todas las cosas que uno usa habitualmente, pero no están disponibles en la pizarra.

Sin embargo, hay algunos errores que, aunque técnicamente solo son errores de sintaxis, muestran un malentendido más profundo.

Como un ejemplo un tanto artificial para transmitir el punto: considere un programador de Python que prefija todas sus variables con $, o escriba el ciclo for como for list as item. Técnicamente, ambos son errores de sintaxis, pero incluso con una exposición limitada a Python, uno debería saber qué ocurre con los caracteres legales y el bucle for. Sería una buena suposición que el candidato conoce php (¿o perl?) Y trata de farolear sobre sus habilidades en python

Preferiría el segundo candidato, en la teoría de que una pizarra tiene más impacto en la sintaxis que en la lógica, y que los errores de sintaxis son más fáciles de corregir: el IDE o el compilador generalmente pueden hacerlo.

He estado escribiendo SQL y CSS (los lenguajes más simples y básicos que conozco) durante casi 13 años, y no siempre recuerdo la sintaxis.

Mi amigo (también desarrollador) trabaja para un fondo de cobertura, nunca puede recordar la sintaxis de una declaración de inserción.

Ambos terminamos en W3CSchools , creo que deberíamos estar avergonzados (él tiene un título y yo tengo un doctorado).

Sin embargo, para ser honesto, creo que tenemos nuestras prioridades correctas. La sintaxis no es una habilidad importante.

Pocos pensamientos sobre los errores de sintaxis ... Me preguntaba si habías dejado claro a ambos que la sintaxis debe ser correcta. A veces las personas suponen que el pseudocódigo está bien.

Además, si alguien reclama años de experiencia en un idioma y no puede corregir la sintaxis básica, debe dudar de la afirmación.

Los errores de sintaxis pueden variar, por lo que si alguien olvida el nombre de un método, está bien (para mí), pero si alguien no sabe cómo referirse a un método en una clase (notación de puntos) o no conoce un pensamiento básico como la sintaxis para un clase simple, entonces es probable que esta persona no haya usado el idioma durante mucho tiempo.

Para el tipo que no obtuvo la sintaxis correcta, ¿cree que sus errores podrían haberse solucionado fácilmente con el editor de idioma apropiado? Si es así, voto por él.

Creo que lo que estoy pensando aquí es que los errores de sintaxis son aceptables dentro de los límites.

Un programador asistente junior o incluso una herramienta de software podría encontrar y corregir una sintaxis incorrecta si la lógica es buena. Mala lógica ... cualquier solución es mucho menos segura. Todos los programadores lo arruinarán. Escogería a los que son más fáciles de detectar y arreglar.

A menos que el problema sea sutil y la mayoría de las preguntas de la entrevista no lo sean, el primer candidato será descalificado. Es mucho más fácil aprender la sintaxis del lenguaje que el diseño de algoritmos. Contrataré a un programador con un historial de trabajo exitoso en varios idiomas, incluso si no tiene experiencia en mi tecnología actual. Esta no es la mejor estrategia si necesito hacer algo hoy, pero si necesito hacer muchas cosas en los próximos doce meses, siempre elegiré la habilidad general sobre la experiencia específica.

La comprobación de sintaxis es para qué sirve un compilador. Un compilador no puede mejorar su lógica, pero puede decirle cómo corregir su sintaxis. Eso significa que en cualquier trabajo en el que escriba código utilizando un compilador, la lógica es inherentemente mucho más valiosa que ser sintácticamente correcta.

Las entrevistas son siempre situaciones incómodas; puede decir esto porque cuando se va, inmediatamente piensa en todas las cosas que debería haber dicho, o las respuestas correctas a las preguntas y las cosas que quería preguntarles pero olvidó. Entonces, dado esto, esperar que el código perfectamente escrito sin errores de sintaxis no sea realista.

Además, sus expectativas de código perfecto (¡en una pizarra!) Pueden no coincidir con los entrevistadores; por ejemplo, en una entrevista a la que asistí me pidieron que escribiera una clase, lo cual hice, solo para que el entrevistador me detuviera al no poner en un constructor de copia. Entonces escribí uno en, que no hizo nada más que establecer a = b, pero eso fue suficiente para satisfacerlo. Mis expectativas sobre el problema no requerían un copiador, por lo que lo dejé como algo ajeno al problema que se estaba resolviendo: no esperaba tener que escribir código de compilación totalmente compatible (según sus estándares de codificación ocultos), simplemente mostrar Mi comprensión de la solución. (A este mismo entrevistador tampoco le gustó mi solución, no era como lo habría hecho, así que obviamente me equivoqué, suspiro).

Si desea el código de trabajo de un entrevistado, dele un compilador. Entonces no te quejes cuando te facturen :)

Entonces, busca a la persona que sabe lo que está haciendo, no la que puede repetir las palabras pero no entiende el significado.

Durante una entrevista, el entrevistador está más interesado en ver su

1. Enfoque del problema
2. Habilidad utilizada para resolver el problema y la
3. Tiempo necesario para dar una solución adecuada.

Sin embargo, la sintaxis no es tan importante, pero ocupa un lugar destacado al resolver un problema, con grandes errores en la sintaxis que no puede esperar que impresione al entrevistador.

La lógica y la sintaxis adecuadas combinadas juntas pueden ayudarlo en una entrevista.

Un error pequeño o menor nunca le costaría mucho si la lógica es lo suficientemente buena.

Más allá puede haber IDE disponible que fácilmente podría hacer la sintaxis incluso de cualquiera en forma adecuada. Pero usar qué método, dónde y cuándo, y lo más importante , POR QUÉ , solo lo conocería un tipo con la lógica y el conocimiento adecuados del tema real.

Espero e insto a que proporcione algo más que una pizarra o un bloc de notas para escribir el código.

Yo iría con el segundo candidato. ..

Bueno, algunas personas quieren grandes desarrolladores de Java, grandes desarrolladores de C #, grandes desarrolladores de C ++, etc. Si ese es tu caso, entonces ve con A y más poder para ti. Una preocupación que tendría es que si no pueden razonar para resolver el problema, ¿cómo puede esperar que razonen y resuelvan sus problemas comerciales?

Otras personas solo quieren grandes desarrolladores que puedan trabajar en cualquier idioma que se requiera. Piensan / modelan el problema y luego lo implementan en cualquier idioma. Si de repente decides que .NET apesta y cambias a Java o viceversa, estos son los desarrolladores que no saldrán ni se negarán a aprender. Además, si obtiene algún tipo de paquete de automatización / paquete de cálculo que tiene un lenguaje propietario y necesita algunas tareas automatizadas, estos son los tipos de desarrolladores que pueden hacerlo. Ejemplo de la vida real ... Necesitaba descifrar un lenguaje de secuencias de comandos patentado y personalizado para un paquete de software de mapeo para extraer códigos postales para regiones dibujadas personalizadas para un antiguo empleador. Otro ejemplo ... mi empleador actual tiene un sistema de administración de propiedad que contiene un lenguaje personalizado para escribir informes ... En cualquier caso,

También en la pizarra hay una presión / nerviosismo adicionales, por lo que nadie está en su mejor momento. Además, dudo mucho que cuando codifiques siempre lo consigas perfecto. Sospecho que compila o simplemente ejecuta y encuentra algunos errores. Además depende del idioma. C es lo suficientemente pequeño como para que probablemente pueda memorizar la mayoría de las bibliotecas de lenguaje / núcleo (aunque no lo requeriría). Java / C # tiene bibliotecas tan grandes (con cambios tan frecuentes) que no se puede memorizar la biblioteca.

También saber múltiples idiomas puede trabajar en su contra. C # y Java interfieren entre sí. Pero conocer múltiples idiomas también puede ampliar su perspectiva, especialmente si conoce un lenguaje de script y un lenguaje funcional además de C # / Java.

Sin embargo, si ambos candidatos resuelven el problema con la lógica correcta, el tipo con la sintaxis correcta probablemente tenga una ventaja. Si uno resuelve el problema y no lo hace, entonces personalmente iría con el tipo que puede resolver el problema.

Aún así, si alguien afirma ser un experto en Java y no puede declarar una matriz de uso de una declaración if o un bucle while, puede estar mintiendo. Pero podría entender si alguien es un experto en Java pero ha estado usando mucho C # últimamente e intenta hacer Map o algo ... También si entras en detalles de la biblioteca, o alguien hace myArray.length en lugar de myArray .Length o string.length () / string.Length / string.length en lugar de string.length () ... Cosas menores que perdonaría. O si olvidan el orden de argumento de alguna llamada a la biblioteca. O un error tipográfico / punto y coma aquí o allá ...

No tomaré ninguno de ellos.

Una buena sintaxis es inútil si el programador no es bueno para resolver problemas. Y una sintaxis pobre para un idioma dado significa que el candidato no se siente cómodo con ese idioma en particular, tal vez por falta de experiencia directa.

De todos modos, la lógica es mucho más importante que la sintaxis.

Eso, como siempre, depende. Si los errores de sintaxis son relativamente menores, los ignoraría. Si son terriblemente enormes, les prestaría atención y trataré de inferir por qué están allí.

Creo que los errores lógicos son peores que los errores de sintaxis, estos últimos casi siempre pueden detectarse mecánicamente, los primeros no tanto (depende, en cierta medida, del idioma que esté escribiendo, algunas clases de errores lógicos son detectados por un tipo suficientemente avanzado inferencia y verificación).

Definitivamente dependería de la posición para la cual es la entrevista, y probablemente también del idioma.

Trabajar en C ++, tener un chico tartamudeando en la sintaxis da miedo. C ++ está lleno de rincones oscuros, las trampas yacen básicamente en todas partes. Un tartamudeo en la sintaxis significa una pobre exposición al lenguaje, y los principiantes en C ++ cometen muchos errores (por no decir que otros no lo hacen de vez en cuando).

Para responder a su pregunta, entonces:

• Si necesito ocupar un puesto de desarrollador simple, tomaría al tipo con una buena comprensión de la sintaxis de C ++. No brillará, pero no debe provocar demasiadas catástrofes.
• si necesito ocupar un puesto de desarrollador principal, tampoco lo tomaría. Se supone que un desarrollador principal tiene experiencia y lógica.

Solo hay una advertencia: las personas reconocen su falta de experiencia. Idealmente, las personas deberían codificar en el idioma de su elección, o pseudocódigo si así lo prefieren (por ejemplo, los estudiantes).

Historia verdadera, todavía olvido la sintaxis de los eventos de C # cuando tengo que escribirlos a mano. Sucede en entrevistas a veces. No tengo el problema cuando codifico en un teclado.

Elija el tipo que puede codificar, no el que no puede pero puede recordar la sintaxis.

Cuando escribo código en papel / pizarra, incluso para una entrevista de trabajo, básicamente omito una gran parte de la sintaxis. No uso puntos y comas, evito llamadas a métodos, etc. Es más probable que escriba una oración que explique 4 líneas de código realmente básico que el código en sí. Realmente, uso un pseudocódigo similar a php, y hablo sobre lo que estoy haciendo, mientras lo hago, y escribo comentarios rápidos para explicar las cosas que paso por alto (que, en teoría, no son nada realmente importante para el programa)

Mi objetivo al codificar en una entrevista es mostrar cómo resuelvo el problema, no dictar algo que un mecanógrafo podría ingresar al Bloc de notas y haber ejecutado.

Larga historia corta: creo que deberías considerar por qué el primer programador tenía una sintaxis horrible. Muy bien podía saberlo, pero lo consideró irrelevante para la entrevista y prefirió centrarse en las partes de este trabajo que son difíciles (lógica y resolución de problemas).

La persona que no puede satisfacer lógicamente la respuesta no está calificada. Hay demasiadas personas en nuestra industria que producen código basura que cumple pero que en realidad no hace lo que debería hacer ni maneja errores o casos extremos.

La segunda persona puede o no estar descalificada según el tipo y la cantidad de errores y la dificultad de lo que espera que escriban. En términos de SQL (el lenguaje en el que escribo), la persona que no puede recordar la sintaxis de una unión explícita no está calificada para un trabajo que requiere que consulte una base de datos, sin excepciones; el que no recuerda cómo utilizar un CTE recusivo (pero que sabe que existen y trata de usar uno) no lo es. En otras palabras, esperaría que la sintaxis sea más correcta para el código básico que escribe todo el tiempo, pero no para las cosas que se hacen solo ocasionalmente y no para la sintaxis compleja.

Si estaba considerando a una persona que conocía tenía excelentes calificaciones en un área relacionada pero solo un conocimiento mínimo de mi lenguaje específico, probablemente también sería más indulgente con los errores de sintaxis. Prefiero contratar a un gran desarrollador de Oracle que a un desarrollador mediocre de SQl Server para un trabajo de SQL Server (por supuesto, una gran persona de SQL Server sería lo mejor) y no esperaría que esa persona conozca la sintaxis de SQL Server si pudiera mostrarme cómo hazlo en Oracle. Lo mismo con las personas Java y C #, la persona con excelentes habilidades para resolver problemas supera a la que tiene excelentes habilidades de lenguaje, pero la que tiene ambas gana cada vez (a veces son difíciles de encontrar).