¿Qué conocimiento de C# debería tener?

Question

Una pregunta muy abierta. He estado programando en C# para el últimos 5 meses haciendo pequeños proyectos que completé con éxito.

Hoy fui a una entrevista para un papel de C#. La primera pregunta fue 'Cuéntame sobre boxeo'. Dada mi experiencia, no tenía idea de a qué se refería el tipo. Huelga decir que la entrevista no fue tan bien. Otras preguntas fueron 'por qué no es recomienda el uso de un ArrayList de int', 'dime lo que sabes sobre enhebrar', etc.

Realmente no quiero que esto vuelva a suceder, así que estoy planeando dedica algo de tiempo a leer (y practicar) más sobre C#. I entiendo que la mejor manera de aprender es mediante la codificación, pero la codificación no me hubiera ayudado realmente a responder la pregunta sobre 'boxeo', por ejemplo.

No le pido que responda las preguntas técnicas anteriores. De hecho, ahora sé su respuesta, ya que fui directamente al Google después de la entrevista y así es como me di cuenta de que mi conocimiento de C# es algo limitado.

Mi pregunta es: en su opinión, ¿qué conocimiento debería tener cualquier desarrollador de C#? Idealmente, sería mejor si pudiera categorizarlo (conocimiento básico que cualquier persona debería tener sin excepción , conocimiento avanzado, conocimiento experto, etc.). No es necesario para entrar en detalles. Hacer investigación sobre lo que sea que liste será un buen ejercicio para mí.

Answer 1

Aquí hay una buena lista: What Great .NET Developers Ought To Know.

Answer 2

puede encontrar mucho en este tema:

Good C# Interview Questions for a Senior Dev Position

Answer 3

Cinco meses sin ningún conocimiento de boxeo? Querido, cariño, muchacho. Yo dudaría en estar en tu posición. ¿Por qué? Recuerdo aquellos días felices en los que, como tú, carecía del conocimiento básico de las herramientas de mi oficio. ¡Pero no te desesperes, muchacho! Tienes tiempo y ganas de aprender. Permítanos, de inmediato, proporcionarle algunos conocimientos que puede usar para su beneficio futuro. ¡Hurra!

Lea CLR Via C# cubierta a tapa. Coge un libro de Linq (no puedo recomendar ninguno por la parte superior de mi cabeza). Escriba una aplicación usando WPF (para el xaml). Esas tres cosas, creo que le darán el mayor impulso por su dinero en este momento.

Answer 4

Lea C# Programming Guide y C# Reference en MSDN.

Answer 5

yo esperaría que alguien va a dar un C# trabajo profesional para saber acerca de:

• genéricos y colecciones genéricas
• Interfaces (general)
• Interfaces (específicas), a saber -
  • IDisposable: cómo está integrado en el lenguaje y por qué
  • IEnumerable: incluidos los métodos de extensión comunes, bloques de iteradores, d ejecución diferida
• general de serialización en .Net (tal vez no lo habría hecho, pero entender lo que es y saber dónde buscar en la jerarquía del espacio de nombres y documentación)
• general de XML en .Net (igual como serialización)
• Descripción general de los conceptos de subprocesos (igual que xml/serialización). Puntos de bonificación para comprender por qué la mayoría de las colecciones seguras para subprocesos no lo son.
• Han utilizado delegados/lambdas anónimos en al menos un proyecto y, por lo tanto, también tienen una idea básica sobre los cierres.
• cómodo explicando algunos conceptos básicos de al menos uno de WinForms, WPF, formularios web, o MVC
• Ser capaz de responder a algunas preguntas fáciles en clases específicas comunes en .NET BCL: es decir, de System.Data (piensa consultas parametrizadas!) y System.IO (filestreams, path).
• La recolección de basura: ¿cuándo debe llamar GC.Collect (pista: casi no) y por qué

Answer 6

depende también de la función. Si esto se publicitó como un rol de jr, entonces una pregunta de enhebrado es un poco difícil ... a veces las agencias/empleadores tienen expectativas poco realistas.

Answer 7

Hidden Features of C#

Esta pregunta/tema hacen más fácil su trabajo.

Answer 8

Mi experiencia personal de hace mucho tiempo cuando estaba en la escuela.

Fui a ver a mi padre a trabajar en un banco. En ese momento, la mayor parte de su día se ocupaba de las cuentas y de asegurarse de que todo funcionara. Lo que vi fue que estaba tratando de contar/calcular números grandes y calcular (adiciones/multiplicaciones básicas ...).

Después de notarlo, le pregunté: Papá, si todo lo que tienes que hacer son adiciones y multiplicaciones básicas, ¿por qué te molestas en estudiar hasta la graduación?

Su respuesta fue: Si bien no tienes que utilizar todo el conocimiento que has adquirido, ese conocimiento te ayudaría a tomar decisiones aprendidas.

Respondiendo a su pregunta: Si bien no tienes que utilizar todo el conjunto de conceptos, saber que existen te ayudaría a tomar buenas decisiones mientras codificas.

Mi sugerencia junto con las demás publicadas sería intentar pasar el tiempo con stackoverflow todos los días.

Buena suerte.

Answer 9

Algo similar le sucedió a mi pareja haciendo una prueba de manejo. El policía estatal dijo, "hacer una rotonda" y ella no sabía de qué estaba hablando. Los dos pensamos que una rotonda es un tipo de trazado de carretera con un gran círculo, no un giro en U, como quería decir el instructor. Entonces sé a qué te refieres.

Las entrevistas de programación de trabajo varían enormemente. Algunas personas piensan que no se puede juzgar bien a un programador en una entrevista y están dispuestos a darle una oportunidad a cualquiera que cause una buena impresión. Otros son cosas extenuantes que solo superarían los que están sobrecalificados para el puesto, y probablemente te sorprenda la frecuencia con la que recibes una llamada de ellos.

Answer 10

Esto es algo que he estado reflexionando mucho últimamente. Usando C# en abundancia pero no estoy seguro de lo que me estoy perdiendo.

pedí

Microsoft® .NET Framework Application Development Foundation

que cubre mucho terreno en relación con C#

también mirando C# in Depth

Lea algunos de esto ya. Tiene buena información de un autor de alta calidad.

A fondo está en venta también a través de Jon Skeet de blog

Answer 11

Tendría que decir que si un entrevistador puede ser engañado en el pensamiento de que alguien tiene más .NET/C# experiencia por él o ella visita una página web, a continuación, el entrevistador está fallando. También he entrevistado a varias personas, y realmente me gusta el enfoque de darles un problema fácil de entender para resolver y pedirles que escriban un código en una pizarra blanca. Incluso si hubieran memorizado las respuestas a cada pregunta en el blog de Scott Hanselman, aprendería mucho sobre lo cómodos que están en el idioma, y ​​sobre cómo resolver problemas. Estoy buscando un desarrollador, no un socio para Trivial Pursuit, .NET Developer Edition.

Dicho esto, estar al día con blogs como Hanselman's es una forma fantástica de mantenerse al día con la jerga. Puede codificar C# en el vacío durante años, comprender completamente la ventaja de una Lista fuertemente tipada <int> sobre ArrayList, pero nunca utilizar el término "boxeo". Pero en una entrevista consume mucho más tiempo preguntar: "Describa la ventaja de iterar a través de una Lista <int> en lugar de una ArrayList de int", que preguntar "Hablar del boxeo". Además, investigar las respuestas a las preguntas de entrevista de .NET de Hanselman (especialmente si exploras los detalles y preguntas "¿Por qué?") Te hará un mejor desarrollador. Entonces, por supuesto, sigue leyendo a Hanselman.

Y una nota más ... Si le pregunto a alguien si un String es un tipo de referencia o de valor, y simplemente dice "Hmmm ... Tipo de referencia," no voy a ser tan feliz como lo haría si la respuesta fuera "Hmmm ... Tipo de referencia, pero esa es una pregunta interesante". "¿Por qué es eso?", Digo ... "Porque la cuerda se implementa para que la cuerda sea inmutable, lo que le permite hacer cosas con ella de forma segura usarla como una tecla hash. O pasarla a un método, sabiendo el valor no se puede cambiar. De alguna manera, las cadenas pueden actuar como tipos de valores ... "Y esa sería una gran conversación, llevándome a preguntar:" Cuéntame más sobre por qué las claves hash deben ser inmutables ... "

No es solo la diferencia entre responder correctamente una pregunta 50/50 y toda la información adicional en la segunda respuesta. Tener una conversación inteligente con un entrevistado me lleva a pensar que tendré conversaciones inteligentes como esa una vez que el entrevistado se convierta en mi compañero de trabajo.Y eso es algo que definitivamente estoy buscando.

Answer 12

Un buen entrevistador no lo va a interrogar en trivialidades. Es por eso que tenemos Google. Un buen entrevistador encontrará áreas que no conoce y le hará preguntas allí, ya que es el mejor lugar para descubrir cómo reacciona cuando se enfrenta con algo que no le gusta.

El mejor consejo que puedo dar para las entrevistas es no preocuparse demasiado por los trivios técnicos. En cambio, en una entrevista, concéntrese en las habilidades para resolver problemas. Si no sabes algo, no intentes esconderlo, solo admítelo. Si crees que sabes, está bien decir "No estoy seguro, pero creo que es esto". Y tampoco se desconcierte: en ese momento, generalmente el entrevistador le dará una pista. Esto no es solo darle la respuesta, es otra parte de la prueba: ver si, dado un empujón en la dirección correcta, puede extrapolar desde allí.

Para las preguntas boxing/ArrayList/int, si estuviera entrevistando y no entendiera el boxeo, le daría una descripción básica de lo que hizo el boxeo. Luego le preguntaría, sabiendo lo que acabo de decirle, por qué podría pensar que usar Ints en una ArrayList podría ser una mala idea.

Una cosa que irá muy lejos en cualquier entrevista es centrarse en los requisitos, el resultado deseado y las condiciones de contorno o casos límite. Como la mayoría de las preguntas de la entrevista de programación entran en la categoría "escribir este método", asegúrese de obtener la siguiente razón:

1) Las entradas al método 2) El resultado esperado del método 3) de contorno y los bordes de los casos .

Esto suena ridículamente básico, pero es sorprendente cuántos desarrolladores, incluso aquellos con experiencia, no se toman la molestia de pensar en estas cosas. El código resuelve un problema: si no comprende el problema correctamente, no puede resolverlo correctamente.