Jump to content
  • Advertisement
Sign in to follow this  
Hodgman

Conducting a programming interview (C++, C#...)

This topic is 617 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm sitting in on an interview tomorrow with the intention of quickly assessing a candidates technical abilities / experience level, including:

* High level C++ -- lambdas, std library, polymorphism

* Low level C++ -- manual memory management, etc

* C# for general applications / GUI 

* General software engineering / computer science knowledge

 

I don't really want to go down the route of giving a big written test, or doing too many on the spot exercises (maybe I could tolerate one or two "write this on a whiteboard" exercises)... So what would you ask to find out whether someone is experienced in these topics? Maybe just ask them to talk about the projects that they've used these languages on, and then ask them to explain some random details? Throw in a big-o or a data structure question to see if they remember their CS training?

 

Maybe some kind of a linked-list vs vector (trick) question where your theoretical CS training would support one answer, but your practical knowledge of CPU cache behaviors will support a different answer. A veteran might give you both answers?

 

It's also not just a yes/no they can/can't do the job kind of decision... but a decision on a starting wage based on a guess at what kind of tasks they'll be able to be given solo.

Edited by Hodgman

Share this post


Link to post
Share on other sites
Advertisement

Since it is tomorrow that you are interviewing and more so that you're looking for experienced programmers  (i will assume you are hiring senior level programmers), IS it not too late to be asking for that kind of strategy now? You probably should have asked like a week or 2 ago, - that would give the chance for more people to provide inputs and ideas-  and you probably should be putting finishing touches to your interviewing strategy about now. 

 

Just my honest thoughts 

 

EDIT:   As for the main question, i've never sat on your side of the table before, so all I can say as a person representing the interviewed (rather than interviewee) is that programming test is a good and effective way of getting the right candidate if it is NOT done on paper but direct on a computer so you can get an IDE help, which highlights APIs, allows line insertions, highlights syntax error etc.

 

EDIT2: Shit!!!  :( a stupid typo changed the meaning of the bracketed second line. Just corrected 

Share this post


Link to post
Share on other sites

Rather than vector vs linked-list maybe "How would you approach scenario X" where a container of some kind is required. Mmmm... Maybe something like audio streaming (where you'd expect something like a circular buffer) and you can explore the candidate's general approach and reasoning in order to lead in to the vector vs linked-list sort of thing?

 

Another exercise could be to describe a mildly complex system that's producing an incorrect behavior and ask the candidate how they would approach the problem (can they use a debugger, do they know how and where to catch an issue). Thinking about things you've had to seek out before (that went slightly beyond simply stepping from a breakpoint) may help coming up with a scenario.

 

As a possible alternative/addition to whiteboarding, maybe have a simple (1k loc?) program that's missing a component and ask the candidate to write the component (100 loc?) in an IDE. See if they write reasonably clean code, comments, don't go crazy with optimism or pessimism, etc. Especially make sure they can explain and discuss what they wrote afterward. Bonus points if it's C++ and C# and they need to write a little of both.

Share this post


Link to post
Share on other sites

The questions you suggest are more for a phone screen than for an on-site interview in my opinion. In an on-site interview you want to let people solve actual problems. E.g. classical questions are revert a string, implement atoi, or itoa. When you ask these questions you give as few information as possible and then let the interviewer scope the problem themselves. If they cannot do this, this is a red flag. If they scoped the problem successfully you let them implement the problem. In the end there should be a working solution. If it is not, they should find the problem through testing when you discuss the solution. If not, this is a red flag. Finally let people discuss and most importantly test their solution. E.g. good people will identify the corner cases and walk you through them (even without a debugger!).

 

The bad people will fall through this very quickly. You need to be aware of the 'talkers' who kind of have reasonable to good resumes and try to handwavingly talk themselves through the questions. That is why it is important that you let them actually code the problem. If someone avoids implementing even the easiest loops this is a red flag. On the other hand there are also the great engineers which have a bad day. You want those people get into the interview process and help where it makes sense. It is a narrow bridge and requires some experience I guess.

 

Finally you should always check for the personality of a person as well. Usually this is done in the first ten minutes of the interview. I like to ask people about points in their resume or some problem they recently solved they find interesting enough to discuss. This is more of a friendly talk and you don't need to go too deep. 

 

I personally like whiteboard testing. It is true that a lot of people fail on this, but there are people who succeed these tests easily and those are the ones want to consider for hiring. Remember that a false no-hire is less hurtful to your company than a false positive hire.

 

HTH,

-Dirk

Edited by Dirk Gregorius

Share this post


Link to post
Share on other sites

It's difficult to give much targeted feedback, because we don't know the experience level you're hiring for, or much of what you expect from the candidate other than proficiency in C++ and C#. We're also not familiar with your company's interview process, so we don't know if this is a candidate who has already passed a phone interview, perhaps a programming test before that, etc.

 

That being said, if you expect them to know multiple languages, perhaps have a few questions where they compare and contrast features in both languages, maybe explain why they would choose one over the other for a particular problem, etc. You get some insight into their problem solving skills, as well as if they know the languages enough to be able to make higher-level architectural decisions.

Share this post


Link to post
Share on other sites
In the past I've prepared snippets of code, no more than ten lines each and presented each to the candidate.

I then ask "where might I see this code", "what advantages does it have, and what disadvantages"
"why might this code not be optimal and in a few words how can I improve its performance"

Some of my questions touched on security too as the programs I am involved in are Internet facing and this is important.

Hope this gives some ideas :)

Share this post


Link to post
Share on other sites

Edit / wrote a whole lot, realised I wasn't answering the question doh! lol.

 

I would think the CV / demos would guide you mostly as to what they would be capable of working on / how much they should be paid. The interview is usually for things like attitude test and checking the CV is realistic, and modifying the assessment from the CV.

 

You could also ask them to bring some source code (might be late now) and / or get them to write some as the others say. Maybe ask them some of their favourite elegant algorithms. Then ask about their actual knowledge of different areas, and see if they seem to know what they are talking about.

Edited by lawnjelly

Share this post


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