Jump to content

  • Log In with Google      Sign In   
  • Create Account

We need your feedback on a survey! Each completed response supports our community and gives you a chance to win a $25 Amazon gift card!


I've got problems with interviews


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
26 replies to this topic

#1 run_g   Members   -  Reputation: 212

Like
1Likes
Like

Posted 28 June 2014 - 12:25 PM

I've got serious problems with interviews ( I live in the UK ...  not sure if my experience is the same for those in the US or else where)

 

When i was in university over 13 years ago i practice code and definitions on paper - mainly to pass exams

 

But since leaving uni i coded straight to my computer....  because i code to develop projects (not to pass exams), and with advanced IDEs such as eclipse i can concentrate on developing algorithm. Of course i do analysis on paper - vector maths, algorithms, data-user interactions, image processing, rough pseudo-code  analysis... on paper. But never proper coding and never definitions because its never been necessary for my code to work. I get the full picture writing the code direct to my computer.

 

And i don't need to rehearse concepts in English because i know it. My focus can momentarily shift from a concept (depending on what i'm currently working on) and there are so many... but i can easily reference anything when i need it.

 

I don't even have to memorise definitions to get complicated code to work.

 

simple example: don't know the definition of anonymous inner class but i have used it b4 because once i see an example of how its used, i have always used it. My description of how i use didn't cut it with them, I have to define it using some key words. 

Ok now with hindsight i can describe it better.  But my using it wouldn't necessarily improve and next time it would be something else

 

In my opinion core algorithm development on computer (not on paper) should be the best way to test the competence and intelligence of a developer 

 

Yet whenever i go for an interview every time again and again and again (despite pre-asking to be tested by writing code to computer) i kept being tested by definitions and crossword-puzzle kind of coding questions on paper (where i can't get- in non-trivial situations- a full picture of the problem)

 

Then someone calls me dumb... because i scored 6/50

They don't even consider my portfolio-projects - taking the so-called test to over-rule my portfolio 

 

Now i'm forced to work in KFC to pay my bills

 

Why do employers insist on this way of assessing programmers?

Why are they so naive?

What's the experience of others (not if you a boss your-self) on this forum?  


Edited by run_g, 04 July 2014 - 08:18 PM.


Sponsor:

#2 swiftcoder   Senior Moderators   -  Reputation: 10450

Like
5Likes
Like

Posted 28 June 2014 - 03:40 PM

Why do employers insist on this way of assessing programmers?

It differentiates engineers from people who only learned to program.

Don't get me wrong, programming is a fine skill, and you can accomplish great things with nothing more. But the majority of employers are looking for software engineers. They need someone who can function on a team, and much of that is having shared vocabulary, design patterns and concepts.

Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#3 Paradigm Shifter   Crossbones+   -  Reputation: 5443

Like
2Likes
Like

Posted 28 June 2014 - 04:13 PM

None of which are addressed by a paper test, especially if it is a multiple choice test. If I get crossword style questions I just say I think it is a bad question (after answering it, or saying I don't know the answer and explain how I would find out the answer).

Being asked how you would detect a loop in a linked list I have been asked twice in interviews. Using a debugger wasn't the right answer ;)
"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley

#4 ApochPiQ   Moderators   -  Reputation: 16423

Like
5Likes
Like

Posted 28 June 2014 - 04:31 PM

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

Interviewing is a tricky art, and has little correlation to job performance; but if you want a software job, it's worth learning to interview well.

#5 ferrous   Members   -  Reputation: 2147

Like
1Likes
Like

Posted 28 June 2014 - 04:32 PM

None of which are addressed by a paper test, especially if it is a multiple choice test. If I get crossword style questions I just say I think it is a bad question (after answering it, or saying I don't know the answer and explain how I would find out the answer).

Being asked how you would detect a loop in a linked list I have been asked twice in interviews. Using a debugger wasn't the right answer ;)

 

It's not the right answer =)  It's actually valuable to know, I had a similar problem I had to solve for work, I needed to actually detect if a graph was recursive, as the graph was getting passed in by a user, so could potentially be poorly set up.  One needs to be able to detect it at runtime in those cases.


Edited by ferrous, 28 June 2014 - 04:32 PM.


#6 Paradigm Shifter   Crossbones+   -  Reputation: 5443

Like
1Likes
Like

Posted 28 June 2014 - 04:43 PM

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.
"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley

#7 swiftcoder   Senior Moderators   -  Reputation: 10450

Like
1Likes
Like

Posted 28 June 2014 - 04:59 PM

Being asked how you would detect a loop in a linked list I have been asked twice in interviews. Using a debugger wasn't the right answer ;)

Those questions filter for a basic background in algorithms. If you took a data structures course in university, you probably know the answer to that right off the bat.

Keep in mind that the entire interview process is calibrated around that fact that you can't get to know a person in one hour. Assuming that, then you are left with having to filter for the things you can test for in an hour: the kind of basic CS skills taught at university, the ability to think on your feet when faced with an unfamiliar problem, and the ability to function under pressure.


Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#8 Paradigm Shifter   Crossbones+   -  Reputation: 5443

Like
1Likes
Like

Posted 28 June 2014 - 05:10 PM

I did maths at uni so I didn't do that. But ferrous is the first person I have heard of that used the algorithm in production. I know the algorithm I just think it is a poor question because it tests academic knowledge rather than practical problem solving. If I had a linked list with a loop my program would hang and I would use a debugger before writing code to validate a list.
"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley

#9 Paradigm Shifter   Crossbones+   -  Reputation: 5443

Like
2Likes
Like

Posted 28 June 2014 - 05:22 PM

Anyway, I agree with the Apochster, interviewers can be bad at identifying good candidates. If you need to do a written test, you should be asking things like "what is this code doing?" rather than what does this syntax mean. Written tests with no feedback are not good interview technique. Communication is the most important skill for a programmer on a team to have if they are competent in coding areas.
"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley

#10 Álvaro   Crossbones+   -  Reputation: 13937

Like
9Likes
Like

Posted 28 June 2014 - 05:45 PM

The way interviews work at my company, you get interviewed by 8 or 9 people and each one of them will ask you to solve some programming problem. I have interviewed maybe 30 people over the last few years. I do ask people to solve stupid toy problems that might not be very closely related to programming on the job, but I don't judge people on whether they solve the problem or they don't: 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. So far I have enjoyed working with everyone that communicated well in my interview. There was only one candidate that I recommended against and ended up working in my group, and I have to admit he is very competent. But I think I would rather work with one of the other people.

After about 15 years of professional experience, I am convinced that the main difficulty in software development is human interaction, not any technical skills. And that's what I am looking for in an interview.

Edited by Álvaro, 28 June 2014 - 05:48 PM.


#11 kunos   Crossbones+   -  Reputation: 2207

Like
6Likes
Like

Posted 28 June 2014 - 06:41 PM

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
Lead Programmer
TWITTER: @KunosStefano
AssettoCorsa - netKar PRO - Kunos Simulazioni

#12 run_g   Members   -  Reputation: 212

Like
0Likes
Like

Posted 28 June 2014 - 06:44 PM


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.



#13 Tom Sloper   Moderators   -  Reputation: 10179

Like
2Likes
Like

Posted 28 June 2014 - 06:45 PM

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.

Edited by Tom Sloper, 28 June 2014 - 06:50 PM.

-- Tom Sloper
Sloperama Productions
Making games fun and getting them done.
www.sloperama.com

Please do not PM me. My email address is easy to find, but note that I do not give private advice.

#14 ApochPiQ   Moderators   -  Reputation: 16423

Like
5Likes
Like

Posted 28 June 2014 - 06:59 PM

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.

#15 SeanMiddleditch   Members   -  Reputation: 7269

Like
4Likes
Like

Posted 28 June 2014 - 07:03 PM

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.

#16 swiftcoder   Senior Moderators   -  Reputation: 10450

Like
1Likes
Like

Posted 29 June 2014 - 07:33 AM

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 - Software Engineer @Amazon - [swiftcoding]


#17 ChaosEngine   Crossbones+   -  Reputation: 2509

Like
0Likes
Like

Posted 29 June 2014 - 05:42 PM


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

#18 run_g   Members   -  Reputation: 212

Like
1Likes
Like

Posted 29 June 2014 - 11:26 PM

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



#19 Buster2000   Members   -  Reputation: 1783

Like
2Likes
Like

Posted 30 June 2014 - 01:41 AM

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.



#20 ferrous   Members   -  Reputation: 2147

Like
0Likes
Like

Posted 30 June 2014 - 08:43 AM

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.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS