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.

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

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.

I'm sitting in on an interview

It sounds more like you're conducting parts of the interview? Or is this just a regional terminology thing? Anyways, if you're flying solo then god help you. If you have co-interviewers you should be hashing this out with them. Presumably someone in the entourage has a standard playbook for your company/team.

tomorrow

Ouch.

This is dreadfully late. You need to have your organization prepare a scheme for interviewing candidates before you post the listing and get applicants. Frankly it's dangerous from a liability standpoint to pull in last-minute interviewers, unless they are already vetted by the organization for legal preparedness and readiness to give a fair and consistent interview in keeping with organizational practices.

with the intention of quickly assessing a candidates technical abilities / experience level

Assessing a programmer's technical capability is a very, very hard job at the best of times, when armed with prepared exercises/tests and interview topics. In my experience, you're painfully close to random chance at this point.


You have my genuine condolences with this situation. The best I can offer is to find some common ground with the candidate (game engines, C++ esoterica, big data algorithms, whatever) and talk shop in as much detail as you can muster.

I often use the "five question" rule - start with something like "what's your favorite bit of code you've written?" Iterate through why, then pick a detail and ask the candidate to justify it, etc. Pick on the subject for a good 5 questions before moving on. The more a candidate shows willingness and ability to dive deep on a subject, the more questions you can afford.

Frankly with minimal time to prepare I think you may be stuck going with your gut. For someone with a seasoned bullshit detector and plenty of first-hand experience, it should be straightforward to just chat for a while and see if any red flags pop up.


Let us know how it goes :-P

Ask them if C++ is a nice language to work with. That ought to tell you enough about the candidate.

Some good tips, thanks :D

@TheChubu got voted down for trolling I assume, but I actually like that. Anyone who's an expert in C++ could talk for days about all the things that are wrong with it.

It sounds more like you're conducting parts of the interview? Or is this just a regional terminology thing? Anyways, if you're flying solo then god help you. If you have co-interviewers you should be hashing this out with them. This is dreadfully late. You need to have your organization prepare a scheme for interviewing candidates before you post the listing and get applicants. Frankly it's dangerous from a liability standpoint to pull in last-minute interviewers, unless they are already vetted by the organization for legal preparedness and readiness to give a fair and consistent interview in keeping with organizational practices.

Yes, participating in the interview. Yeah, have talked with the other interviewer over the past weeks, and they're not keen on too much formal testing, but more interested in personalities and general ability to learn skills/procedures quickly.
The interview itself isn't last minute -- me deciding to ask GDN for any tips for my BS detector is last minute.
This is nothing so corporate btw. This is an indie game studio and we haven't hired many programmers before, so we don't have a good routine yet.
We fund our indie game by doing work-for-hire and outsourcing, so we have a very wide variety of tasks for any staff to work on, but we're not big enough to have full time employees. I'm a part owner and I'm not even an "employee" - everyone is a freelancer. Any programming freelancer that we hire will be working alongside me, with me as the quality checker between them and the outsourcing clients.

Remember that a false no-hire is less hurtful to your company than a false positive hire.

Workers actually have rights in Australia (sorry US :lol:) so normally a full-time hire would be a very big deal, but as above, this is just deciding whether to try out a freelancer or not, so we can easily change our minds later if it doesn't work out. I'd rather hire them for a week to test them out than spend an excessive amount of time deciding on the perfect test -- it's probably actually cheaper to do that. We're also largely an art-outsourcing firm, and unpaid "art tests" are a cancer in that field, which has probably influenced the way that we think about testing programmers now too...

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.

As above, we've got our own understaffed indie game, and a wide variety of outsourcing work, so I can find tasks for programmers of most skill levels. One of the key decisions will be deciding a suitable starting wage based on our impression of the kinds of tasks they'll be able to take on / how much supervision or rewrites their work will require.

They've only been screened via their CV and some email chats, this is the first face to face meeting.

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 :)