C# devs: how about these interview questions?
-
Ask them, wether they prefer strongly typed or stringly typed code. Edit: That typo was good :-)
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a fucking golf cart.
"I don't know, extraterrestrial?" "You mean like from space?" "No, from Canada." If software development were a circus, we would all be the clowns.I prefer stringently-typed variables, myself.
Software Zen:
delete this; -
kdmote wrote:
How do you inherit a class, and why might you want to?
I think a relative has to die, and that's not fun to think about.
kdmote wrote:
What is the purpose of interfaces, and how are they helpful?
It's all about the interaction, like we're interfacing right now.
kdmote wrote:
Why would you ever want to make a method private or protected?
There are just some things you don't want to have witnesses for
kdmote wrote:
Can you explain what a lambda is, and why you might use one
A lambda is a baby sheepda, and it's used to distract rednecks from noticing your own private methods.
kdmote wrote:
Why might you use a property instead of a regular variable?
You can't do anything without property.
kdmote wrote:
Are you familiar with any "Design Patterns"?
My wife is the seamstress in the house...
kdmote wrote:
Have you heard of the concept of "tight" or "loose coupling",
Yes, but now we're solidly back into that private methods/no witnesses thing.
kdmote wrote:
Have you used a Unit Testing framework?
Yeah, but I found out my unit was just fine.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013:laugh:
Software Zen:
delete this; -
I prefer stringently-typed variables, myself.
Software Zen:
delete this;That's commendable, as long as you don't stringently stringly type. :-)
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a fucking golf cart.
"I don't know, extraterrestrial?" "You mean like from space?" "No, from Canada." If software development were a circus, we would all be the clowns. -
I am conducting a round of interviews this week, looking for a mid-level C# developer. I'm down-selecting some tech questions which are aimed at trying to filter out the "Yeah, I did a C# project a couple years ago" crowd from the "C# has been in my blood for at least a year or two" folks. But selecting appropriate questions is always a challenge. (Just because something is obvious to me, doesn't mean every developer has encountered it. Every project is different and people get exposed to different things. I definitely want to avoid "language trivia.") So here is my first cut of questions. For those of you who are .NET devs, would you agree that somebody with a couple years of solid experience should be able to talk intelligently about most of these topics? (Not all of these are C#-specific.) 1. How do you inherit a class, and why might you want to? 2. What is the purpose of interfaces, and how are they helpful? 3. Why would you ever want to make a method private or protected? 4. When might you use a static class or method? 5. Can you explain what a lambda is, and why you might use one. (Or, alternatively, LINQ?) 6. Why might you use a property instead of a regular variable? (How are they different?) 7. Are you familiar with any "Design Patterns"? Can you name one or two that you have used? 8. Have you heard of the concept of "tight" or "loose coupling", and how does it effect code design? 9. Have you used a Unit Testing framework? If so, how did it (or unit testing in general) benefit your code, if at all? [Note: we have decided not to make the candidates write or debug actual code in the interview, with the possible exception of FizzBuzz. But that is a topic for another thread.]
kdmote wrote:
looking for a mid-level C# developer
Ugh. All those questions a mid-level developer should be able to answer, and you should have been able to glean from their resume / github / LinkedIn that they are capable of answering those questions. Even for mid-level developers, I would stick with questions that are more open ended and tell you about their thinking process. Marc
V.A.P.O.R.ware - Visual Assisted Programming / Organizational Representation Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
-
Pualee wrote:
I still don't know why it is "see sharp".
Because in musical notation "#" indicates a "sharp" note: it's called an "accidental" that raises the pitch of a note by a semitone. Sharp (music) - Wikipedia[^]
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
Oh, I know music, just thinking about the progression of the language: A, B, C, C++ Of course there is D but nobody cared. C++ implied there was something more than C (the ++ operator for instance). By why switch to music for C#? We know the C part came to attract C and C++ developers, but why on earth "sharp"? When using the # character in coding, it was always pound, not sharp (now folks fancy it a hash tag).
-
Oh, I know music, just thinking about the progression of the language: A, B, C, C++ Of course there is D but nobody cared. C++ implied there was something more than C (the ++ operator for instance). By why switch to music for C#? We know the C part came to attract C and C++ developers, but why on earth "sharp"? When using the # character in coding, it was always pound, not sharp (now folks fancy it a hash tag).
Pualee wrote:
why on earth "sharp"?
Because a committee got involved: The A-Z of Programming Languages: C# - Computerworld[^] :sigh:
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
-
I am conducting a round of interviews this week, looking for a mid-level C# developer. I'm down-selecting some tech questions which are aimed at trying to filter out the "Yeah, I did a C# project a couple years ago" crowd from the "C# has been in my blood for at least a year or two" folks. But selecting appropriate questions is always a challenge. (Just because something is obvious to me, doesn't mean every developer has encountered it. Every project is different and people get exposed to different things. I definitely want to avoid "language trivia.") So here is my first cut of questions. For those of you who are .NET devs, would you agree that somebody with a couple years of solid experience should be able to talk intelligently about most of these topics? (Not all of these are C#-specific.) 1. How do you inherit a class, and why might you want to? 2. What is the purpose of interfaces, and how are they helpful? 3. Why would you ever want to make a method private or protected? 4. When might you use a static class or method? 5. Can you explain what a lambda is, and why you might use one. (Or, alternatively, LINQ?) 6. Why might you use a property instead of a regular variable? (How are they different?) 7. Are you familiar with any "Design Patterns"? Can you name one or two that you have used? 8. Have you heard of the concept of "tight" or "loose coupling", and how does it effect code design? 9. Have you used a Unit Testing framework? If so, how did it (or unit testing in general) benefit your code, if at all? [Note: we have decided not to make the candidates write or debug actual code in the interview, with the possible exception of FizzBuzz. But that is a topic for another thread.]
-
I am conducting a round of interviews this week, looking for a mid-level C# developer. I'm down-selecting some tech questions which are aimed at trying to filter out the "Yeah, I did a C# project a couple years ago" crowd from the "C# has been in my blood for at least a year or two" folks. But selecting appropriate questions is always a challenge. (Just because something is obvious to me, doesn't mean every developer has encountered it. Every project is different and people get exposed to different things. I definitely want to avoid "language trivia.") So here is my first cut of questions. For those of you who are .NET devs, would you agree that somebody with a couple years of solid experience should be able to talk intelligently about most of these topics? (Not all of these are C#-specific.) 1. How do you inherit a class, and why might you want to? 2. What is the purpose of interfaces, and how are they helpful? 3. Why would you ever want to make a method private or protected? 4. When might you use a static class or method? 5. Can you explain what a lambda is, and why you might use one. (Or, alternatively, LINQ?) 6. Why might you use a property instead of a regular variable? (How are they different?) 7. Are you familiar with any "Design Patterns"? Can you name one or two that you have used? 8. Have you heard of the concept of "tight" or "loose coupling", and how does it effect code design? 9. Have you used a Unit Testing framework? If so, how did it (or unit testing in general) benefit your code, if at all? [Note: we have decided not to make the candidates write or debug actual code in the interview, with the possible exception of FizzBuzz. But that is a topic for another thread.]
Since most of the questions are so vague that they need 1,000-word answers, they're probably hoping to publish a book with material stolen from interview answers.
I wanna be a eunuchs developer! Pass me a bread knife!
-
I am conducting a round of interviews this week, looking for a mid-level C# developer. I'm down-selecting some tech questions which are aimed at trying to filter out the "Yeah, I did a C# project a couple years ago" crowd from the "C# has been in my blood for at least a year or two" folks. But selecting appropriate questions is always a challenge. (Just because something is obvious to me, doesn't mean every developer has encountered it. Every project is different and people get exposed to different things. I definitely want to avoid "language trivia.") So here is my first cut of questions. For those of you who are .NET devs, would you agree that somebody with a couple years of solid experience should be able to talk intelligently about most of these topics? (Not all of these are C#-specific.) 1. How do you inherit a class, and why might you want to? 2. What is the purpose of interfaces, and how are they helpful? 3. Why would you ever want to make a method private or protected? 4. When might you use a static class or method? 5. Can you explain what a lambda is, and why you might use one. (Or, alternatively, LINQ?) 6. Why might you use a property instead of a regular variable? (How are they different?) 7. Are you familiar with any "Design Patterns"? Can you name one or two that you have used? 8. Have you heard of the concept of "tight" or "loose coupling", and how does it effect code design? 9. Have you used a Unit Testing framework? If so, how did it (or unit testing in general) benefit your code, if at all? [Note: we have decided not to make the candidates write or debug actual code in the interview, with the possible exception of FizzBuzz. But that is a topic for another thread.]
Whatever questions you decide on, encode them with ROT13. :cool:
-
I am conducting a round of interviews this week, looking for a mid-level C# developer. I'm down-selecting some tech questions which are aimed at trying to filter out the "Yeah, I did a C# project a couple years ago" crowd from the "C# has been in my blood for at least a year or two" folks. But selecting appropriate questions is always a challenge. (Just because something is obvious to me, doesn't mean every developer has encountered it. Every project is different and people get exposed to different things. I definitely want to avoid "language trivia.") So here is my first cut of questions. For those of you who are .NET devs, would you agree that somebody with a couple years of solid experience should be able to talk intelligently about most of these topics? (Not all of these are C#-specific.) 1. How do you inherit a class, and why might you want to? 2. What is the purpose of interfaces, and how are they helpful? 3. Why would you ever want to make a method private or protected? 4. When might you use a static class or method? 5. Can you explain what a lambda is, and why you might use one. (Or, alternatively, LINQ?) 6. Why might you use a property instead of a regular variable? (How are they different?) 7. Are you familiar with any "Design Patterns"? Can you name one or two that you have used? 8. Have you heard of the concept of "tight" or "loose coupling", and how does it effect code design? 9. Have you used a Unit Testing framework? If so, how did it (or unit testing in general) benefit your code, if at all? [Note: we have decided not to make the candidates write or debug actual code in the interview, with the possible exception of FizzBuzz. But that is a topic for another thread.]
Long while ago (7+ years ago ) I was at the receiving end of interview questions. All technical questions being fired at me by 4 people from the company and one of them completely threw me off when all of a sudden one of them asked me "design a zoo". Now I am in a zone to answer technical questions like language syntax and why one thing over other etc and bam..Till date I remember that interview because it was so odd. So you can add that to your list or not ! :)
Zen and the art of software maintenance : rm -rf * Maths is like love : a simple idea but it can get complicated.
-
kdmote wrote:
How do you inherit a class, and why might you want to?
I think a relative has to die, and that's not fun to think about.
kdmote wrote:
What is the purpose of interfaces, and how are they helpful?
It's all about the interaction, like we're interfacing right now.
kdmote wrote:
Why would you ever want to make a method private or protected?
There are just some things you don't want to have witnesses for
kdmote wrote:
Can you explain what a lambda is, and why you might use one
A lambda is a baby sheepda, and it's used to distract rednecks from noticing your own private methods.
kdmote wrote:
Why might you use a property instead of a regular variable?
You can't do anything without property.
kdmote wrote:
Are you familiar with any "Design Patterns"?
My wife is the seamstress in the house...
kdmote wrote:
Have you heard of the concept of "tight" or "loose coupling",
Yes, but now we're solidly back into that private methods/no witnesses thing.
kdmote wrote:
Have you used a Unit Testing framework?
Yeah, but I found out my unit was just fine.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
