C# devs: how about these interview questions?
-
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.]
They're ok but those questions are asked at almost every interview so you risk employing people who are simply good at taking interviews. I prefer real-world questions like; You inherited a legacy system that uses a fairly complex Stored Procedure and for no valid reason whatsoever you want to convert this procedure to LINQ. What do you use as keywords in your Code Project thread where you effectively ask someone to do the task for you? a) SQL b) Stored Procedure c) LINQ d) c# e) c#5, c#4, c#3, c#2 f) MVC g) jQuery h) All of the above
-
Your questions are OK, but Software Development is about problem solving. Anyone can memorize the textbook answers to those questions, and even speak intelligently about them, but if they can't take a common business requirement and break it down into a development plan are they really someone you would want to hire? Consider coming up with a generic business problem/requirement and ask them to describe (possibly on a whiteboard) how they would approach the problem. There are a lot of approaches to any given requirement, some better than other, but you'll learn a lot about them during this process.
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
Kevin Marois wrote:
Consider coming up with a generic business problem/requirement and ask them to describe (possibly on a whiteboard) how they would approach the problem.
Yep, that's how I'd do it. The language and/or framework isn't important, you can always learn it when you need to. It's more the "this is what we want to do, how would you go about making that?" kind of question that gives a real insight into how the person thinks and often opens up some good discussion points.
Ah, I see you have the machine that goes ping. This is my favorite. You see we lease it back from the company we sold it to and that way it comes under the monthly current budget and not the capital account.
-
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 usually chuck in a question about what books they had read that influenced the way they developed - then if the books are the same sort of thing that has affected you, and the people they will be working with were of a similar persuasion, then I'd take it as a good indication that they may well fit in.
-
They're ok but those questions are asked at almost every interview so you risk employing people who are simply good at taking interviews. I prefer real-world questions like; You inherited a legacy system that uses a fairly complex Stored Procedure and for no valid reason whatsoever you want to convert this procedure to LINQ. What do you use as keywords in your Code Project thread where you effectively ask someone to do the task for you? a) SQL b) Stored Procedure c) LINQ d) c# e) c#5, c#4, c#3, c#2 f) MVC g) jQuery h) All of the above
i) urgntz pleeeeese
CALL APOGEE, SAY AARDWOLF GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver "Go ahead, make my day"
-
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.]
Q 1 to 4 are a waiste of time for a mid-level. The later questions are showing if the dev is understanding the language. It is better to invest in some words about the goals and some "lessons learned". A good filter is always the salary. :~
Press F1 for help or google it. Greetings from Germany
-
To weed out the truly weak, you could ask them how long they've been developing in "C hashtag"
MQ / Tor.NET / Angry Potato
In about the year 2000, after coding C++ for a few years, I saw C#. I pronounced it "see pound". I still don't know why it is "see sharp". Alternatively, I think "see plus plus plus plus" makes more sense - it's almost a pound symbol. ++ ++
-
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.]
Just a thought - not a criticism: My particular strength is problem-solving (and rather quickly, at that). Knowing the answers to all of the above tells you nothing about how successfully they might use that knowledge. I, for one, learn what I need to know for a solution and/or what seems like just plain fun to know. Like that TV show, Jeopardy - those people know an awful lot of stuff - just don't ask them to actually do anything. You need to know stuff just to know the stuff you need to know.
Aut inveniam viam aut faciam
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
-
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.]
You could ask them questions they are unlikely to find in most books: * When does a class static constructor get run? * What does the Conditional attribute do? Or, if you're feeling more friendly to the candidate: When you call a Debug.Assert(), do the arguments get evaluated in release builds? * What's a debugger display attribute and why would you use it? * In a lambda function, is it possible to use a function that returns void? For example, can something like Console.WriteLine() be used in a lambda function? * What don't you like about C#? Or: In your opinion, what did Microsoft get wrong in the C# language? I particularly like this question, and I don't care about what their answer is, but merely that they have and answer and can defend their position. Only caveat, if you don't use these things in your codebase, and don't want to start, I wouldn't use them as interview questions. Otherwise, you might be filtering out candidates that could be good additions to your team.
kdmote wrote:
not to make the candidates write or debug actual code in the interview, with the possible exception of FizzBuzz.
Bonus points if you have them write it as a LINQ statement :)
We can program with only 1's, but if all you've got are zeros, you've got nothing.
-
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 don't consider myself a super strong C# and even I could answer those questions. I'd think if they couldn't answer those then they aren't mid-level devs. In fact, I might use that list myself for interviews.
Jeremy Falcon
-
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:
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 -
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 think a good mid-level C# developer would have a solid command of most of the canned classes and collections. I personally would ask them to hand write code or psuedo-code for loading a CSV file and run some basic analysis on it such as summing and averaging values from two or three of the columns. If they properly use the System.IO, System.Collections, and possibly System.Data classes and proper flow control, they are ready for a more technical interview. I would follow up with questions on when to use interfaces, what the null coalescing and null conditional operators are used for, and explain lambda expressions just to gauge if they have been keeping up with how the language has evolved.
if (Object.DividedByZero == true) { Universe.Implode(); } Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
-
In about the year 2000, after coding C++ for a few years, I saw C#. I pronounced it "see pound". I still don't know why it is "see sharp". Alternatively, I think "see plus plus plus plus" makes more sense - it's almost a pound symbol. ++ ++
-
In about the year 2000, after coding C++ for a few years, I saw C#. I pronounced it "see pound". I still don't know why it is "see sharp". Alternatively, I think "see plus plus plus plus" makes more sense - it's almost a pound symbol. ++ ++
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...
-
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.]
