Basic C# quiz

Looks okay to me, if I was really familiar with C# and its syntax. The higher level question you should me asking is, "Am I looking for a programmer or am I looking for someone who knows C#?"

Your questions focus a bit on both programming and understanding C# syntax, but not knowing C# while knowing programming would make some otherwise good programmers struggle a bit. Generally, my rule of thumb is to avoid asking programming questions where the answer is a quick google search away.

Are these candidates expected to know C#? Is this a position that requires some experience in C#?

Otherwise some of the questions simply cant be answered by someone who knows other languages but not C#, like the IEnumerable's Count one, or the one with a generic and abstract class.

1 hour ago, slayemin said:

The higher level question you should me asking is, "Am I looking for a programmer or am I looking for someone who knows C#?"

1

I would be willing to accept someone who had good programming skills in another language, but the job itself will be mostly in C# (working with an existing code base).

50 minutes ago, TheChubu said:

Are these candidates expected to know C#? Is this a position that requires some experience in C#?

Yes, to all of the above. It's clearly stated in the job listing. The thing is, all of the candidates I've interviewed so far, actually have C# experience, but still struggle.

1 hour ago, slayemin said:

Generally, my rule of thumb is to avoid asking programming questions where the answer is a quick google search away.

As I said, these are expected to be jumping off points. This is definitely not the whole interview, just the C# portion.

There are a bunch of other questions around general OO concepts (SOLID, LSP, inheritance v composition, etc).

2 hours ago, ChaosEngine said:

but so far, people have struggled to answer them

My thought is that you are asking the wrong questions.

Going through them...

You have three "how could this be improved", or "what is potentially bad with this algorithm" questions, all are "aha" or "gotcha" questions. Either they recognize the thing you are looking for, or not. Most of these are inconsequential to the real world. Why are you asking? Are the improvements relevant to the job? Is this the kind of thing your programmer will be spending their day doing? They may be nice questions to ask if you are looking for something specific, but overall they don't tell if the person has the mindset of a good developer. Would you fire an existing developer if they got the question wrong?

"Will it compile" is another "gotcha" question. Plug the thing into a compiler and look, don't waste my time trying to see if I spot the missing punctuation or typos. This has nothing to do with the logical process of writing code. If you're looking for someone to do proofreading or copydesk editing then keep the question. Would you fire a programmer for not noticing the issue?

You've got two "what is the difference" questions. They're fine if you critically require someone who understands what the language is doing under the hood. But again, why does this matter to the job they're doing? Would you fire one of your other C# programmers if they don't properly explain the difference between abstract classes with C#'s single inheritance rules versus interfaces? Would you like to be fired if you didn't properly state the differences between generic methods and generic classes?

I strongly dislike that type of programming quiz in general. The best places I've worked have not used them, and the worst places I've worked relied on tests and quizzes extensively. Except for cases where the pre-interview quizzes go too long (I tell them I will only grant them an hour max, I'm busy trying to get a job) I generally pass the quizzes, but so did a lot of other people who didn't get much stuff done or who liked to argue about unimportant minutia. I've also moved on to interviews after declining to answer quizzes after the hour is up, and I've had people agree that their company's standard written tests are a waste of time and my rules were a point in my favor.

A simple "briefly explain question" is good, but deeper quizzing is bad. If it isn't must-have knowledge and if you wouldn't reprimand one of your own programmers for the answer, you probably shouldn't bother with it in that type of quiz.

2 hours ago, ChaosEngine said:

There are a bunch of other questions around general OO concepts (SOLID, LSP, inheritance v composition, etc).

Good. An interview is a discussion, not a pop quiz. If they are discussions be careful that it isn't you talking and them agreeing, and be careful that it doesn't become a quiz show of "do you know this answer". Lines that start with "tell me what you know about..." or "what do you think about..." can lead to some interesting interview-appropriate discussion.

Even better in my view are the questions "tell me about a time you used..." or "Tell me about any experiences you've had, good or bad, about ..." Some of my favorites are "tell me about some times you've made trade-offs in your code to accomplish a goal." If they look confused, ask about exchanging time versus space (such as a lookup table of pre-computed values) or swapped to a faster but less accurate algorithm, or switched to statistical methods, or tried a different language or tool, or otherwise showed they knew what kind of options are available to programmers.

The amazing old Guerrilla Guide to Interviewing is always a good thing to re-read before an interview. You're looking for smart and useful. If they don't know a specific question but they're smart and useful they can find the answer online in an instant. None of those questions really seem to address those concerns.

When I interview, my first thing is to look for interests and passions related to software, and ask about them if I don't see them immediately. Many programmers, being introverts, are highly passionate about what they do but some don't talk about it very well. I ask questions about what they've done, but I don't care as much about the specific details than I do about the words they use. Are they using the right vocabulary, are they describing solutions in ways that show they think like a programmer? I ask for them to write some simple code, but mostly as a simple sanity check.

For more senior positions as you describe I look for big holes in their knowledge and experience. Have they worked on tools, on networking, on graphics, on gameplay, on engines? What have they NOT worked on? Holes aren't necessarily a problem, but are important to know and too many holes in critical areas to the work are a problem. We talk about what languages they know and how they have used them professionally and in a hobby. I recently (painfully) made a case against a senior programmer applicant. He had done some good things a decade ago, but nothing recently, he had big holes in his knowledge about too many things and he only knew a single programming language despite working in games for twenty years. Yes he was smart and everybody picked up on that, but he had pigeonholed himself into a role that was bad for a senior developer. He may have been an okay mid-level developer and may have been able to learn other languages and fill the holes, but for the role we needed at the time they were too big of an issue.

On 1/22/2018 at 6:51 PM, frob said:

You have three "how could this be improved", or "what is potentially bad with this algorithm" questions, all are "aha" or "gotcha" questions. Either they recognize the thing you are looking for, or not.

To be fair, the first is around the concept of resource management and the use of the using statement. That's a pretty important idiom in C#, akin to asking a C++ programmer if they understand RAII.

On 1/22/2018 at 6:51 PM, frob said:

"Will it compile" is another "gotcha" question. Plug the thing into a compiler and look, don't waste my time trying to see if I spot the missing punctuation or typos.

I'm not really worried about missing punctuation or typos, I'm looking to see if they understand the difference between reference and value types.

On 1/22/2018 at 6:51 PM, frob said:

Good. An interview is a discussion, not a pop quiz. If they are discussions be careful that it isn't you talking and them agreeing, and be careful that it doesn't become a quiz show of "do you know this answer". Lines that start with "tell me what you know about..." or "what do you think about..." can lead to some interesting interview-appropriate discussion.

As I said, the point of these questions was as a jumping off point to spark discussion.

But thank you for your feedback, I'll take it on board. I'm not really super attached to this quiz myself, it was a request from above to use something like it. Might be time to push back against it.

Yeah, anyone you're hiring specifically for thorough C# knowledge should know all of those. However...

1. You want them to suggest changing it to IDisposable+using, right? It's not a very straightforward question but anyone with good C# experience should notice that.

2. Someone who knows to use generics at all probably will immediately understand the difference. And if they don't, the compiler will yell at them until they do.

3. You should remove the missing semicolon part of the question and focus on the return-struct-from-property nuance instead since that's far more important to understand. It WILL compile if you fix that semicolon, but it will silently discard the change they're trying to make. Asking "will it compile?" distracts from the real problem.

4. Avoiding (or intentionally using) lazy re-evaluation is important to understand. Keep it as-is.

5. The compiler will simply tell someone exactly what's wrong if they try that. When I worry about a programmer on my team making mistakes, I don't care about ones the compiler simply won't allow.

Also, I've worked with a lot of very experienced developers who have just recently switched to C# who probably wouldn't understand ANY of those, but could be taught them in less than an hour. What you're testing for here is C# language knowledge only, not really general purpose programming skill. HOWEVER, it is likely that anyone who understands all of the nuances also has good general purpose skill.

If someone passes this test with flying colors, they probably also have great general purpose knowledge. But if someone fails it, they might have tons of skill, but just switched from C++ recently or something.

Suggestions for additional questions if you want an even more thorough C# skill check:

operator+(string, string) vs. StringBuilder. It sounds trivial but make absolutely sure they know the difference.

Functional programming (passing and returning first class functions).

async/await.

13 hours ago, Nypyren said:

You should remove the missing semicolon part of the question and focus on the return-struct-from-property nuance instead since that's far more important to understand.

Oops, that was actually a typo when I copied the question to that doc. Doh!

Yes, the intention was the return-struct-from-property nuance.

13 hours ago, Nypyren said:

It WILL compile if you fix that semicolon

Actually, it won't. The compiler will catch that problem with a

Cannot modify the return value of 'Person.Address' because it is not a variable

error, but I wanted to see if people understood the differences between reference and value types.

2 hours ago, ChaosEngine said:

I wanted to see if people understood the differences between reference and value types.

Then why not ask them directly?

Most of those questions seem to ask if the person taking the quiz can divine the answers you are searching for. Based on what you've said, neither your interview candidates nor the people on here fully picked up the nuances you were trying communicate.

Even with those extra notes about why you asked the questions, I still don't think any of the questions solve the core questions about if they can do the job, or if they are smart about how they code, or if they can play nicely with others.

4 hours ago, ChaosEngine said:

Actually, it won't. The compiler will catch that problem with a

Cannot modify the return value of 'Person.Address' because it is not a variable

error, but I wanted to see if people understood the differences between reference and value types.

Ah, so it does. I'm thinking of a different case, I guess. There is at least one situation which looks similar to your example which compiles but discards the modification instead of producing a compile error. Can't remember exactly what it is now, though.

2 hours ago, frob said:

Even with those extra notes about why you asked the questions, I still don't think any of the questions solve the core questions about if they can do the job, or if they are smart about how they code, or if they can play nicely with others.

Of course, they don't. That's not what this portion of the interview is about.

Our interviews typically extend over a few sessions. The first session covers the candidates' background, experience (in a business sense), strengths, weaknesses, etc. They get the opportunity to tell us about themselves and more importantly, ask us questions (what we do, how we work, etc). If we feel that they can potentially do the job, they go onto a technical interview (which includes this) and we go more in depth about what they've worked on (from a technical perspective). The last usually involves actually working through a problem in our development environment.

I should mention that this is not game dev. Also it's a very small team, so getting the right person is crucial.

On 1/23/2018 at 3:27 AM, Nypyren said:

Ah, so it does. I'm thinking of a different case, I guess. There is at least one situation which looks similar to your example which compiles but discards the modification instead of producing a compile error. Can't remember exactly what it is now, though.

Little off-topic, but it throws it away in case Address would be a function rather than a property. I.e. Person.GetAddress().City will compile, but throw away the result.

On 1/23/2018 at 1:23 AM, frob said:

Then why not ask them directly?

This precisely. This can make you start a discussion much more easily and can get you to learn a lot more about the programmer. As has been said before, these are all 'spot-the-bug'-kind of questions where you either catch it or are like 'aaah' (which doesn't tell you much; he either didn't know or he knows what's going on, but just happened to oversee it). Interviews can be stressful so it becomes easier to overlook such things. Starting an actual conversation rather than turning it into an exam will make candidates feel more at ease and get the interview to line up more with their normal workflow.

I get how you're interested in the interviewee's knowledge of C#, but I suggest you leave out exam questions to exams as much as possible and start conversations instead, such as by asking 'what is the difference between a reference and a value type in C#?'. For this particular example, you could, if you're really keen on it, ask the code-example question while or after discussing the topic. I know that in normal cases of problem solving you get no such hint of topic, but in this case it shows the candidate at least requires some additional knowledge to answer the question.

10 hours ago, AthosVG said:

This precisely. This can make you start a discussion much more easily and can get you to learn a lot more about the programmer. As has been said before, these are all 'spot-the-bug'-kind of questions where you either catch it or are like 'aaah' (which doesn't tell you much; he either didn't know or he knows what's going on, but just happened to oversee it).

How often are you presented with a bug in real code where the problem is clearly documented? I want them to look at the code and figure it out.