Jump to content
  • Advertisement
Sign in to follow this  
ChaosEngine

C# Basic C# quiz

Recommended Posts

I've been interviewing a few job candidates recently. I wrote a short list of what I could consider pretty basic C# questions for them. My intention with these questions was to use them as a jumping off point for more interesting discussions, but so far, people have struggled to answer them. So I thought I'd post them here to get some feedback from people.

Basically, am I expecting too much? These are pitched at mid-senior developer level.

 

All feedback much appreciated.

Technical Interview questions.pdf

Share this post


Link to post
Share on other sites
Advertisement

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.

Share this post


Link to post
Share on other sites

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.

Edited by TheChubu

Share this post


Link to post
Share on other sites
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). 

Edited by ChaosEngine

Share this post


Link to post
Share on other sites
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.

 

Share this post


Link to post
Share on other sites
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.

Edited by ChaosEngine

Share this post


Link to post
Share on other sites

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.

Edited by Nypyren

Share this post


Link to post
Share on other sites

 

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.

 

Share this post


Link to post
Share on other sites
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.  

Share this post


Link to post
Share on other sites
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.

Edited by Nypyren

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!