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.]
-
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:
I definitely want to avoid "language trivia."
Well ... 1, 2, 3, and 4 are pretty much "language trivia" :laugh: If I was you, I'd have a look for those "interview questions and answers" sheets some "developers" seem so fond of. Ask the questions on that and reject anyone who gives the answer on the sheet...
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.]
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 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.]
To weed out the truly weak, you could ask them how long they've been developing in "C hashtag"
MQ / Tor.NET / Angry Potato
-
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 stryngly tiped code myself.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
-
I prefer stryngly tiped code myself.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
I prefer smugly triped.
This space for rent
-
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.]
Not a bad set of questions at all - nothing too narrow in there. If not getting them to write code, it might be a good idea to ask how they would approach writing something for a stated problem. In our last round of interviews (admittedly for a junior), I set what I considered to be a super-easy coding task. I thought at the time that it would filter out a couple of idiots but hardly any candidates even got close to it. The task was simply to take an input of a sum of money and break it into the smallest number of notes and coins possible. The first attempt was hilarious (pretty much if (amount == 52.31) print "some answer that added up to about £48") and they didn't get much better from there. At one point I was so worried that I'd gone OTT that I asked my ageing mother. She worked out the algorithm in half a second. The thing was, some of these guys could talk the talk (or at least quote Wikipedia) but couldn't code their way out of a wet paper-bag so I really would go with a test of that sort.
Slogans aren't solutions.
-
I prefer stryngly tiped code myself.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
How about boldly striped?
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. -
Not a bad set of questions at all - nothing too narrow in there. If not getting them to write code, it might be a good idea to ask how they would approach writing something for a stated problem. In our last round of interviews (admittedly for a junior), I set what I considered to be a super-easy coding task. I thought at the time that it would filter out a couple of idiots but hardly any candidates even got close to it. The task was simply to take an input of a sum of money and break it into the smallest number of notes and coins possible. The first attempt was hilarious (pretty much if (amount == 52.31) print "some answer that added up to about £48") and they didn't get much better from there. At one point I was so worried that I'd gone OTT that I asked my ageing mother. She worked out the algorithm in half a second. The thing was, some of these guys could talk the talk (or at least quote Wikipedia) but couldn't code their way out of a wet paper-bag so I really would go with a test of that sort.
Slogans aren't solutions.
Is your mother available for an interview? Seriously, though. I think that's kind of the problem with interviews: bright people can get so nervous that they aren't able to think as quickly or clearly as they might under normal working conditions. Good/bad interview performances don't always correlate to actual skill or aptitude. That makes it tough for an interviewer. But I appreciate the suggestion.
-
How about boldly striped?
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.Afraid it's boldly gone where no code has gone before.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
-
kdmote wrote:
I definitely want to avoid "language trivia."
Well ... 1, 2, 3, and 4 are pretty much "language trivia" :laugh: If I was you, I'd have a look for those "interview questions and answers" sheets some "developers" seem so fond of. Ask the questions on that and reject anyone who gives the answer on the sheet...
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
OriginalGriff wrote:
1, 2, 3, and 4 are pretty much "language trivia"
Really? I particularly liked those questions. What I liked about them was that, for the most part, there isn't really any right or wrong answers, per se, but I would be surprised if somebody had been doing development work for a year or two and hadn't encountered them in some form. I don't care about the exact syntax; I'm just interested to hear if they can discuss the concepts thoughtfully.
-
Afraid it's boldly gone where no code has gone before.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
Since NextGen it's 'to baldly go where...' :-)
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. -
OriginalGriff wrote:
1, 2, 3, and 4 are pretty much "language trivia"
Really? I particularly liked those questions. What I liked about them was that, for the most part, there isn't really any right or wrong answers, per se, but I would be surprised if somebody had been doing development work for a year or two and hadn't encountered them in some form. I don't care about the exact syntax; I'm just interested to hear if they can discuss the concepts thoughtfully.
-
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.]
These are pretty good questions for a mid-level developer. What I have found to be the best way to gauge a developer's skills is to ask them to tell you about different projects they have worked on. If they don't give much detail ask if they worked on it alone, if they wrote all the code or just maintained it, if they designed the classes etc. You should be able to tell if they are qualified by allowing them to do most of the talking.
There are two kinds of people in the world: those who can extrapolate from incomplete data. There are only 10 types of people in the world, those who understand binary and those who don't.
-
These are pretty good questions for a mid-level developer. What I have found to be the best way to gauge a developer's skills is to ask them to tell you about different projects they have worked on. If they don't give much detail ask if they worked on it alone, if they wrote all the code or just maintained it, if they designed the classes etc. You should be able to tell if they are qualified by allowing them to do most of the talking.
There are two kinds of people in the world: those who can extrapolate from incomplete data. There are only 10 types of people in the world, those who understand binary and those who don't.
:thumbsup:
-
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 can completely answer 8 out of 9 having used C# poorly in a single project 5 years ago. An that's because I don't remember Design Patterns, not by name - I always used a bunch of them even before being introduced to the concept of design patterns... When I read that infamous book I mostly thought "well, duh!" every odd page.
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"
-
OriginalGriff wrote:
1, 2, 3, and 4 are pretty much "language trivia"
Really? I particularly liked those questions. What I liked about them was that, for the most part, there isn't really any right or wrong answers, per se, but I would be surprised if somebody had been doing development work for a year or two and hadn't encountered them in some form. I don't care about the exact syntax; I'm just interested to hear if they can discuss the concepts thoughtfully.
:thumbsup::thumbsup::thumbsup:
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.]
You'll get someone good at exams, doesn't necessarily translate to ability to create solutions from scratch. The Asian's education departments are fighting this very weakness in their current system right now, they got plenty of kids who ace exams but are useless in the field without constant mentoring. (Those 14 year old geniuses doing PhD's - touted to be the next Einstein and will solve world peace, hunger and global warming - never heard from again.) Ask them not "how do you ...," rather questions where they will need to suggest use of such items as you listed. If answers are vague ask for details. i.e. simple case: don't ask a builder "how to use a tape measure," ask them how they would determine the width of a doorway. Sure there are other ways to do things, if it sounds odd ask them why they chose that way, challenge them on the got-ya's, ask why they believe their solution is the best way and what's the alternatives. (Warning: Don't play teacher and correct them - that's just a recipe to become their mentor if hired - OK to throw in the odd clue but not too much. Act like a doctor, throw in a few hmmm's and take notes - that last one will get them sweating and acts as a good stress test.
Sin tack ear lol Pressing the any key may be continuate
-
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.]
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.
-
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
