Intern interviews

[RussSchultz]

We're currently interviewing interns, and I'm concerned that I'm not asking the right level of questions.

Our general guidelines are:
- 3 years of university completed
- aiming for software engineers w/embedded focus

What would you expect these people to be able to do/answer in an interview?

Here's my general 'test':
1) Give me the structure for a linked list w/a payload of an integer
2) Iterate the linked list and give me the max value of the integer payload
3) Allocate an array of 10 integers, followed by some pointer math questions
4) A trick question about swap(int a, int b)
5) Give a structure with 2 data members. Iterate through an array of 50 of these to give me the max value of one of the data members

Is this aiming the bar too high?

 

[Tim Murray]

Don't think so. 1 is trivial, you should be able to do that after an intro programming course. If you can do 1, you should be able to do 2 (although you might screw up on checking for the end and what not). 3 is the only questionable one--pointer math is a bitch to remember and it's really easy to screw up. 4 is the generic xor question everybody's already prepared for, and 5 is straightforward.

Unless, of course, these are all magically different on embedded systems, which I know absolutely nothing about

So yeah, the test looks fine. I'd probably do something to make sure that they can write reasonable English, though. Might not be too important for an intern gig, but way too many CS students can't communicate ideas at all.

 

[Crusher]

It doesn't sound unreasonable in terms of knowledge for a job, but I dislike the idea of testing for this kind of knowledge in the interview process. If they've completed 3 years of college, it's probably been close to two years since their data structures class. Depending on who often they've had to use it since then, and how good their memory is, they may or may not do well on tests like this. I guess my theory is the test won't show whether or not they could perform the job well, just whether or not they would need to use a quick reference now and then to refresh their memories.

Clearly if someone has no clue what a linked list is and you use them frequently, they would be a poor candidate. But I would limit the test analysis to whether they know of these things, not how well they implement them in the time period you give them.

 

[RussSchultz]

If you're hiring somebody to be a programmer, how would you ensure that have basic skills? Or, better yet, how would go about rating their capabilities as a programmer?

 

[RussSchultz]

3 is the only questionable one--pointer math is a bitch to remember and it's really easy to screw up.

These candidates are coming from an embedded engineering course, knowledge about memory layout and pointer math is pretty essential to conversing with hardware registers.

4 is the generic xor question everybody's already prepared for

HA! Its actually a check to see if people realise that passing by value doesn't do diddly.

 

[Npl]

if you want to be evil, change 2) to report back the 2nd highest integer
First you see if the guy actually realises that there could be multiple interpretations of the task and asks back before he does something that might not be required. And the algorithm itself also aint as trivial as it looks.

But personally I think you can only filter out the worst people in an interview. After a few days of work you have a quite good picture, so I would rather have 2 weeks of trial before employment.

 

[Simon F]

.......
Is this aiming the bar too high?

Russ,
Those are about the level of question I ask in interviews but I also like to see if they can do some problem solving (but then I'm in the research group).

Simon

 

[Humus]

I think the best approach is to mix a bunch of low level and high level questions, and perhaps also some general less technical engineering questions. I'd throw in a bunch of quick specific questions about C/C++ (if that's relevant for the position), some problem solving questions, high level description of common high level data structures and so on. I prefer to have many short questions rather than a few big ones to get a good overview. I interviewed a lot of people for a position at ATI, and I used the above approach. We ended up hiring a really good guy, but one thing to keep in mind is that even very skilled programmers will miss out on some of the relatively basic questions. So if you have a list of just a few questions that might give you a false negative on a good guy.

 

[_xxx_]

I think you should also make sure the candidate has some social competence and is a nice team player, also capable of managing stuff on his/her own. So I'd check that out prior to diving into technical stuff. Tech can be taught, the personality can't.

 

[Frank]

Depending on what you want out of them, I would try to find out if they do the things as they learned them, or if they make up their own mind. I would probably want them to be able to work unsupervised as much as possible, and so would value problem solving over knowledge. So, general "how would you..." questions.

 

[digitalwanderer]

Just remember to get real serious at one point in the interview and look at them with a totally deadpan face and say, "Do things taste salty to you?".

 

[Simon F]

I used to ask "Can you juggle?"

 

[RussSchultz]

Heh.

I ask this because yesterday I had two university students, both in their 4th year with very high marks come in and not be able to answer any of those questions without gobs of prompting. Both their resumes said "proficient with C/C++". I had to send both of them home with a bit of a lecture/advice to not put anything on their resume they couldn't back. Both of them had excuses like "I haven't done this for over a year" "I didn't have time to prepare". Maybe I'm a hardass, but in my opinion, when you're talking about job skills, you need to KNOW the material.

I'll try the juggle thing, though.

 

[Frank]

Heh.

I ask this because yesterday I had two university students, both in their 4th year with very high marks come in and not be able to answer any of those questions without gobs of prompting. Both their resumes said "proficient with C/C++". I had to send both of them home with a bit of a lecture/advice to not put anything on their resume they couldn't back. Both of them had excuses like "I haven't done this for over a year" "I didn't have time to prepare". Maybe I'm a hardass, but in my opinion, when you're talking about job skills, you need to KNOW the material.

Agreed. Or at least give it a good try, to show they do know what you're talking about.

 

[Simon F]

I had to send both of them home with a bit of a lecture/advice to not put anything on their resume they couldn't back.

I've interviewed some whose CV/Resume said "3D Graphics" and they couldn't tell me what a Z-buffer was. Now, is that unreasonable?

I'll try the juggle thing, though.

:smile:

 

[KimB]

I ask this because yesterday I had two university students, both in their 4th year with very high marks come in and not be able to answer any of those questions without gobs of prompting. Both their resumes said "proficient with C/C++". I had to send both of them home with a bit of a lecture/advice to not put anything on their resume they couldn't back. Both of them had excuses like "I haven't done this for over a year" "I didn't have time to prepare". Maybe I'm a hardass, but in my opinion, when you're talking about job skills, you need to KNOW the material.

Well, I think it's rather sad that they couldn't answer those questions, and definitely shouldn't get the job. I know that I could have answered every single one of those, though I may have needed some prompting on 4, by the time I started my third year of undergraduate study (just bear in mind that I'm currently working on a Ph.D. in physics, so my bar may be set a little high too ).

However, there is one thing to bear in mind when giving an interview: nervousness. I have met people who just can't handle nervous pressure. That might lead to a false negative, because once they're on the job and comfortable, they may be able to perform admirably. One thing you can do to combat this is to try to act like you're their friend, like you want them to do as well as they can. It might also be good to try to break up the interview with a bit of humor, especially in the middle of the interview if they're doing badly. I'd say assume first that they're nervous, but if you can't get them past that, to answer even the above simple questions, there's no way you can tell whether it's nervousness or just lack of knowledge or logical reasoning.