I've got problems with interviews

Started by
25 comments, last by Thinias 9 years, 9 months ago

if you really detect a pattern in your interviews you should treat it just as you treat any other programming problem you have solved: work on it.

Sadly you cannot make the rules, even if you think the rules are stupid, you either play by the rules or stay in KFC.

I can assure you that once you get hired the first time everything becomes easier.

It should be quite easy to find these kind of interview-like tests on the internet.. force yourself to work on these 1 hour a day and eventually you will get better and land your software dev job... I am sure it'll also widen your horizons and give you different perspectives on things in the process.

Stefano Casillo
TWITTER: [twitter]KunosStefano[/twitter]
AssettoCorsa - netKar PRO - Kunos Simulazioni

Advertisement


I want to see how they think and -more importantly- how they communicate. If I we are going to hire this person, he'd better understand me and I'd better understand him, because otherwise we won't be able to work together.

If a candidate gets stuck at some point, I will offer hints, as a way to keep the conversation going.

fair enough for a multi-stage interview. communication, aptitude, personalty ... coding . How do you assess the coding stage? Testing real algorithm development on computer would be closer to what the candidate would be doing if they join your company, so why not test them that way in addition.

most interviewers are really horrible at interviewing. Even the best have trouble reliably recognizing good candidates.


Perhaps so. But most people who interview programming candidates are programmers themselves, and know what good programming practices are.

And i don't need to rehearse concepts in English because i know it...
I don't even have to memorise definitions to get complicated code to work.


It's important to remember that in the game industry, each person is a member of a team, and communication with the rest of the team is crucially important. To work in a game team, you need to be able to explain ways of doing things. If you can't explain what you're doing (or planning to do, or how another person might want to tackle a problem), then you're missing an important ability needed for working in a team.

-- Tom Sloper -- sloperama.com

Perhaps so. But most people who interview programming candidates are programmers themselves, and know what good programming practices are.


Being a programmer and understanding good practices does not correlate in any meaningful way with being able to spot someone who shares that knowledge in a single hour of conversation. I know plenty of brilliant programmers who are terrible at giving interviews. I trust them with a lot of difficult code every day; I virtually never have them sit in when talking to a candidate.

Sure, given a few weeks, any decent programmer can give you a reasonable rating for how good someone else is. Landing on that score with a minimum of information and no observation of the candidate under realistic work conditions is another thing entirely.


From my own experience with giving interviews, the main difficulty has little to do with assessing base programming skill. It's almost entirely a communications problem. I can tell if someone understands the basics of C++ in a five minute phone screen; but it takes at least an hour of very specifically honed questions to ferret out whether or not they can work in a large code base with a large team and get things done. Even then individuals often miss things, which is why our interview loop consists of several rounds with different interviewers.


As a baseline hint: if your interview questions consist of things like "find a loop in a linked list", the answer damn well better be "look up the algorithm on the internet" or you are a failure of an interviewer, period. Testing ridiculously specific knowledge does nothing but tell you how good a candidate is at regurgitating stuff. What you need to know is can they find the relevant things to look up, can they think, and can they know when to do one versus the other.

Wielder of the Sacred Wands
[Work - ArenaNet] [Epoch Language] [Scribblings]

We actually don't ask a whole lot of technical questions in our interviews. I used to have a problem with this, and would try to inject technical minutiae into my portions of the interview, but I've since come to see the value in the way our more experienced interviewers ran things.

You can't get to know a person in an hour, but you can get to know a good portion of their skill range, enthusiasm, and personality in an hour by asking the right kinds of questions. For instance, asking if someone can solve some linked-list problem will tell you exactly whether they can solve that linked-list problem or not. They could be an idiot who managed to memorize a few bits of CS100 or they could be a 20-year veteran who just hasn't dealt much with linked lists in a long time.

On the other hand, if you ask a person what in game technology excites them, you can learn all kinds of things. If they give a vague or empty answer, they're either nervous (and need a bit more gentle prodding to open up) or just mediocre. If they go on about <insert cool tech here>, you know that they're passionate about games tech, study things beyond the immediate bug/feature they've worked on, and have a good understanding of all the related fields to the topic they're talking about. If someone can tell you details about how real-time soft-body deformation works, you can safely skip asking the basic linear algebra questions at the very least. smile.png If they pick a topic you're familiar with, you can quiz on details. If they pick a topic you aren't familiar with, see if they understand it well enough to teach you about the topic.

Ask for their stories and experiences and interests. You learn a lot about what they know, how they learned it, why they learned it, what motivates them, what they're passionate about, how they solve hard problems, what kind of team dynamic they're comfortable in, and their surface personality.

Asking how to find a linked-list loop or whatnot doesn't tell you any of that even in the best of cases. It just tells you if they can solve the linked-list loop problem. That's a giant waste of everyone's time, especially if you only have an hour.

Every candidate I've interviewed who didn't thrive when lightly prodded to tell stories like the above also failed pretty miserably when I gave up and fell back on technical questions or vernacular quizzing. The intersection of competent engineers with engineers who have nothing interesting to talk about turns out to be really small, especially in an industry like games which is fueled by enthusiasm and passion for the product.

Sean Middleditch – Game Systems Engineer – Join my team!

Communication is the most important skill for a programmer on a team to have if they are competent in coding areas.

That's a *big* assumption. A lot of the interview process (particularly phone screens) is to weed out applicants whose technical skills do not match up to their resume.

Testing real algorithm development on computer would be closer to what the candidate would be doing if they join your company, so why not test them that way in addition.

I would assume that any engineer worth their salt can code up a basic algorithm given a suitable IDE. The question in my mind is whether they can whiteboard up an algorithm alongside a team of other engineers.

Any junior engineer should be able to code up a storm, whereas a core function of a senior engineer is to be someone you go to when you need help, and they can grab a whiteboard and walk you through to an optimal solution.

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]


As a baseline hint: if your interview questions consist of things like "find a loop in a linked list", the answer damn well better be "look up the algorithm on the internet" or you are a failure of an interviewer, period. Testing ridiculously specific knowledge does nothing but tell you how good a candidate is at regurgitating stuff. What you need to know is can they find the relevant things to look up, can they think, and can they know when to do one versus the other.

This. Good lord, THIS.

Even worse when it's API specific. Years ago I was asked in an interview which win32 api function I would use to do something (don't remember the specifics). When my answer of "whatever msdn told me" wasn't accepted, I politely let them know I wouldn't be wasting any more of my time in that interview.

My last job application consisted of an hour of informal chat/mild technical questions and then a day at the office working on a problem. I thought that was a really good way to judge someone, but my only issue was that I was left alone to solve the problem. The problem itself was trivial to solve, but if I was running that interview, I would have had the candidate work with someone to judge how they worked with a team.

if you think programming is like sex, you probably haven't done much of either.-------------- - capn_midnight

if you really detect a pattern in your interviews you should treat it just as you treat any other programming problem you have solved: work on it.

Sadly you cannot make the rules, even if you think the rules are stupid, you either play by the rules or stay in KFC.

I can assure you that once you get hired the first time everything becomes easier.

It should be quite easy to find these kind of interview-like tests on the internet.. force yourself to work on these 1 hour a day and eventually you will get better and land your software dev job... I am sure it'll also widen your horizons and give you different perspectives on things in the process.

You are perfectly right! as tough as that sounds you are damn right!!!

Probably 4 hours a day instead bcus i need to fast-track myself away from the fried chicken job

When you have an interview the programming test is only a small part of the interview. You could get 0 / 50 and stii get the job. The trick is to be able to hold a conversation and talk about something interesting. If an interviewer asks you a question don't respond with one word yes or no answers. The chances are if you sound boring you will not get the job even if you got 50 / 50.
When interviewers interview candidates they are rarely looking to just fill a pair of shoes.

Then you are the first person I know who has found a use for it ;) in 99% of the cases you use a debugger and correct the code. Knowing about graph theory is a good skill to have though, I'm not arguing against that.

Anyplace where you are being handed data from a user or runtime generated source should be validated, especially anything that can be made into an infinite loop. Though most games are not going to have something like that, most tool chains on the other hand? Probably.

That said, as interview questions go, it's not that great of a question, as someone who has done the problem once, will know how to solve it forever, and it ends up being not that interesting. (it's actually kind of a fun whiteboard problem to solve, other than that issue -- along with yes, it's a googleable answer)

And most of the word problems have thankfully died off, I hated those, I can't believe how many times I was asked that stupid marble question (X marbles, one is heavier than the others, how do you find it when all you have is a comparative scale)

There was an interesting article from google about interviews, and they ended up admitting that it's a very tough problem space: http://www.deathandtaxesmag.com/200732/google-admits-its-famous-job-interview-questions-were-a-complete-waste-of-time/

The money quote:

Years ago, we did a study to determine whether anyone at Google is particularly good at hiring. We looked at tens of thousands of interviews, and everyone who had done the interviews and what they scored the candidate, and how that person ultimately performed in their job. We found zero relationship. It’s a complete random mess, except for one guy who was highly predictive because he only interviewed people for a very specialized area, where he happened to be the world’s leading expert.

This topic is closed to new replies.

Advertisement