remarks cref c#

cref - remarks c#



¿Qué conocimiento de C#debo tener? (9)

¿Cinco meses sin ningún conocimiento de boxeo? Mi querido, querido, muchacho. Dudaría estar en tu posición. ¿Por qué? Recuerdo esos días felices en los que yo, como usted ahora, carecía igualmente de algunos de los conocimientos básicos de las herramientas de mi oficio. Pero, no desesperes, muchacho! Tienes tiempo y ganas de aprender. ¡Permítanos, de inmediato, dispensar algún conocimiento que pueda usar para su beneficio futuro! Huzzah!

Lea CLR Via C # cover to cover. Agarra un libro de Linq (no puedo recomendar ninguno de los de mi cabeza). Escribe una aplicación usando WPF (para el xaml). Esas tres cosas que creo que te darán el mayor provecho en este momento.

Una pregunta muy abierta. He estado programando en C # durante los ú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 el boxeo''. Dada mi experiencia, no tenía idea de lo que quería decir el chico. No hace falta decir que la entrevista no fue tan bien. Otras preguntas fueron ''¿por qué no se recomienda usar una ArrayList de int '', ''dime lo que sabes sobre el enhebrado'', etc.

Realmente no quiero que esto vuelva a suceder, así que estoy planeando pasar un tiempo leyendo (y practicando) más en C #. Entiendo que la mejor manera de aprender es codificar, pero la codificación no me hubiera ayudado realmente a responder la pregunta sobre el "boxeo", por ejemplo.

No te estoy pidiendo que respondas las preguntas técnicas anteriores. De hecho, ahora conozco su respuesta cuando fui directamente a Google después de la entrevista y es cómo me di cuenta de que mi conocimiento de C # es algo limitado.

Mi pregunta es: en su opinión, ¿qué conocimiento debe 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 hay necesidad de entrar en detalles. Hacer una investigación sobre lo que enumere será un buen ejercicio para mí.

Algo similar le sucedió a mi pareja que tomó un examen de manejo. El policía del estado dijo "haz una rotonda" y ella no sabía de qué estaba hablando. Ambos pensamos que una rotonda es un tipo de trazado de carretera con un gran círculo, no una vuelta en U, como quiso decir el instructor. Así que sé lo que quieres decir.

Programación de entrevistas de trabajo varían enormemente. Algunas personas piensan que realmente no se puede juzgar bien a un programador en una entrevista y están dispuestos a darle una oportunidad a cualquiera que dé una buena impresión. Otros son cosas extenuantes que solo pasarían aquellos que estaban demasiado calificados para la posición, y probablemente se sorprenderá de la frecuencia con la que recibe una llamada de esos.

Debería decir que si un entrevistador puede ser engañado haciéndole creer que alguien tiene más experiencia con .NET / C # cuando visita una página web, el entrevistador está fallando. Yo mismo entrevisté 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. Incluso si hubieran memorizado las respuestas a todas las preguntas en el blog de Scott Hanselman, aprendería mucho sobre qué tan cómodos están con el idioma, así como sobre cómo resolver problemas. Estoy buscando un desarrollador, no un socio para Trivial Pursuit, .NET Developer Edition.

Dicho esto, mantenerse al día con blogs como el de Hanselman es una manera fantástica de mantenerse al día con la jerga. Podría codificar C # en un vacío durante años, comprender completamente la ventaja de una Lista <int> fuertemente tipada sobre ArrayList, pero nunca usar el término "boxeo". Pero es mucho más lento en una entrevista preguntar: "Describa la ventaja de iterar a través de una Lista <int> en lugar de una ArrayList de int", de lo que es preguntar: "Hábleme del boxeo". Además, investigar las respuestas a las preguntas de la entrevista .NET de Hanselman (especialmente si explora los detalles y pregunta "¿Por qué?") Lo hará un mejor desarrollador. Así que por supuesto, sigue leyendo Hanselman.

Y una nota más ... Si le pregunto a alguien si una Cadena es un tipo de referencia o un tipo de valor, y simplemente dicen "Hmmm ... Tipo de referencia", no voy a ser tan feliz como lo haría si la respuesta fue: "Hmmm ... Tipo de referencia, pero esa es una pregunta interesante". "¿Por qué es eso?", Digo ... "Porque la cadena se implementa de modo que la cadena es inmutable, lo que le permite hacer cosas con ella como usarla de forma segura como una clave hash. O pasarla a un método, sabiendo el valor no se puede cambiar. Entonces, en cierto modo, las cadenas pueden actuar de manera muy similar a los tipos de valor ... "Y esa sería una gran conversación, que me lleva a preguntar:" Entonces, dime más sobre por qué las teclas 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 de manera regular una vez que el entrevistado se convierta en mi compañero de trabajo. Y eso es algo que definitivamente estoy buscando.

Espero que alguien que vaya a un trabajo profesional en C # sepa:

  • Genéricos y colecciones genéricas.
  • Interfaces (general)
  • Interfaces (específicas), a saber:
    • IDisponible: cómo se integra en el lenguaje y por qué.
    • IEnumerable: incluye métodos de extensión comunes, bloques de iteradores y ejecución diferida
  • Descripción general de la serialización en .Net (tal vez no lo haya hecho, pero entienda qué es y sepa dónde buscar en la jerarquía y la documentación del espacio de nombres)
  • Descripción general de Xml en .Net (igual que la serialización)
  • Visión general de los conceptos de subprocesos (igual que xml / serialización). Puntos de bonificación por comprender por qué la mayoría de las colecciones seguras para hilos 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, webforms o MVC
  • Sea capaz de responder algunas preguntas sencillas sobre clases comunes específicas en .Net BCL: es decir, desde System.Data (¡piense en consultas parametrizadas!) Y System.IO (secuencias de archivos, ruta).
  • Recolección de basura: cuándo debería llamar a GC.Collect (sugerencia: casi nunca) y por qué

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

Pedí

Microsoft® .NET Framework Application Development Foundation

Que cubre un montón de terreno relacionado con C #

También mirando C # en profundidad

Lee algo de esto ya. Tiene una gran información de un autor de alta calidad.

En profundidad está a la venta también a través del blog Jon Skeet.

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 consistía en cuidar las cuentas y asegurarse de que todo funcionara. Lo que vi fue que estaba tratando de calcular / calcular grandes números y calcular (adiciones / multiplicaciones básicas ...).

Después de notarlo, le pregunté: papá, si todo lo que tienes que hacer es sumas y multiplicaciones básicas, ¿por qué molestarse en estudiar hasta la graduación?

Su respuesta fue: Si bien no tiene que usar todo el conocimiento que ha adquirido, ese conocimiento lo ayudará a tomar decisiones aprendidas.

Llegando a su pregunta: si bien no tiene que usar todo el conjunto de conceptos, saber que existen le ayudará a tomar buenas decisiones mientras codifica.

Mi sugerencia, junto con las demás publicadas, sería tratar de pasar algún tiempo en todos los días.

Buena suerte.

También depende de la función. Si esto fue anunciado como un rol de jnr, entonces una pregunta de subprocesamiento es un poco difícil ... a veces las agencias / empleadores tienen expectativas poco realistas.

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

El mejor consejo que puedo dar para las entrevistas es no preocuparse demasiado por las cuestiones técnicas. En cambio, en una entrevista, enfócate en las habilidades de resolución de problemas. Si no sabes algo, no trates de ocultarlo, solo admítelo. Si crees que sabes, está bien decir "No estoy seguro, pero creo que es esto". Y tampoco te desconciertes: en ese momento, generalmente el entrevistador te dará una pista. Esto no es solo darte la respuesta, es otra parte de la prueba: para ver si, dado un empujón en la dirección correcta, puedes extrapolar desde allí.

Para las preguntas del boxeo / ArrayList / int, si estuviera entrevistando y usted no entendiera el boxeo, le daría una descripción básica de lo que hizo el boxeo. Entonces te preguntaría, sabiendo lo que te acabo de decir, por qué piensas que usar ints en un ArrayList puede ser una mala idea.

Una cosa que llegará lejos en cualquier entrevista es centrarse en los requisitos, el resultado deseado y las condiciones de contorno o los casos de borde. Como la mayoría de las preguntas de programación de la entrevista se ubican en la categoría "escribe este método", asegúrate de obtener la siguiente información correcta:

1) Las entradas al método 2) La salida esperada del método 3) Casos de borde y borde.

Esto suena ridículamente básico, pero es sorprendente cómo muchos desarrolladores, incluso los que tienen experiencia, no se molestan en pensar en estas cosas. El código resuelve un problema: si no entiende el problema correctamente, no puede resolverlo correctamente.