# I've got problems with interviews

## Recommended Posts

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

##### Share on other sites
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 ;)

##### Share on other sites

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

##### Share on other sites
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.

##### Share on other sites

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.

##### Share on other sites
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.

##### Share on other sites
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.

##### Share on other sites

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.

##### Share on other sites

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

##### Share on other sites
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. 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.

##### Share on other sites

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.

##### Share on other sites

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.

##### Share on other sites

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

##### Share on other sites

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.

##### Share on other sites

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)

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.

##### Share on other sites

Reminds me of myself.

When someone told me what a singleton was, it reminded me of some 'ugly hack' I had done to make something work. Then I realized that it was exactly what a singleton was.

That's also why I always refer to myself as being able to write code, but never as a programmer.

I would be worthless in a large team because, as soon as someone says something and everybody goes back to work, I'd be the one asking 'what did that mean exactly?' and once I would get the proper explanation I'd feel like I've wasted both our time for something simple.

Truth is, someone like you (or me) end up costing a lot. It is possible to have a lot of practice but too little theory, and this hinders proper communication.

##### Share on other sites

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

I have to be brutally honest here: I know a few people who think they are great programmers and scoff at basic interview-style questions and knowing the definitions of things, and who cannot code on paper. The code they produce at their computers is all average or worse. I can understand there might be exceptions, but I haven't met any yet. I can also understand how an interviewer would be skeptical about whether you're an exception.

This doesn't just sound like you don't know specific things like the linked list loop problem. It sounds like you don't place much value in understanding more than whatever it takes to get your code to run. That doesn't make you a person who I would want to work with. Edited by Pink Horror

##### Share on other sites

This doesn't just sound like you don't know specific things like the linked list loop problem. It sounds like you don't place much value in understanding more than whatever it takes to get your code to run. That doesn't make you a person who I would want to work with.

Its the bad interviewing methods of the industry that is killing my skills,

Originally I was top a class programmer. Then I had a break lasting several months (supposed yo be a temporal quit - due to family issues). Then I couldn't get in any more.

But I still kept up by developing great personal projects (a RT 3D photographic scanner- for example), Except that through the years, as I concentrated more on development, My theoretical rehearsing stop, that affected interviews.  My coding skills remained top class at first until i'm forced to work outside the industry 9 hours a day, 5/6 days a week (in a retail, restaurant - find it boring, not my calling), and now, after some few years of that , even my programming skills (and analysis skills) is now starting to get extremely rusty.

Its a chain effect that I wouldn't wish on my enemy

Yes, now i realise the solution was extremely simple, but i was attending to the forum during breaks in my long shift, was tired, lacked patience...  if I'd known my judgement would be affected that much i would have waited for my day-off

Edited by run_g

##### Share on other sites

Learn the answer to every question you are asked in all interviews.

It doesn't matter if the interviewers are "the problem" they are the 'gate keepers' - defeat them (with charm).

If you can't write down the basic algorithm to find a loop in a linked list then I know you haven't studied data-structures or haven't studied them in years.

I expect you to know how more advanced data structures work, like priority heaps, red-black trees, AVL trees, b-trees, etc... but I don't expect you to know all of them so it's hard to ask questions about those.

#old #hires

Edited by Shannon Barber

##### Share on other sites

I cannot imagine ever hiring for a programmer position without having the candidate white board one or more programming problems.

I say this, because I've been the "technical interview" for people being hired in as programmers who really were not at all qualified. The resume looked great, they absolutely nailed the "let's talk about process, and how we work together" process interviews, as well as the "let's talk about programming without actually doing any" interviews. And then I asked them to whiteboard, and they absolutely cratered.

One of the questions I used to use when looking at candidates who listed on their resume a proficiency with C/C++ was a simple opener.

/* Implement a simplified version of integer to ascii, supporting only base 10, and assuming a 32 bit value on a 2s-Complement architecture */
char * itoa(Int32 value)
{
}



This is not a hard question per se (as with most of my interview questions, I stole it from questions I was asked in an interview). There are a couple of ways to approach it, and while there is a corner case, I don't hold missing it against the candidate. Getting it on the other hand is a bonus. Mostly, I want to see you approach the problem.

And yet, one candidate confidently wrote this:

char *itoa(Int32 value)
{
return (char *) value;
}


Not only did he confidently write it, it took a fair bit to convince him he was wrong. Even with a lot of prompting, what was supposed to be the first 15 minutes of the interview took the whole hour, and he never did get the problem solved.

And that is why I'll always want anyone being hired for a development role to actually write code as part of the interview. Because I've *seen* people with the right resume say all the right things, and flunk the ability to actually write anything. I no longer assume "basic coding competence".

[As a side note, having been on both sides of whiteboarding questions, it is *always* easier to spot the bug while you are sitting there watching them write. That's why the interviewer always seems to have a laser focus on the bug when you haven't seen it. As a candidate, as soon as you finish writing it down (and you should talk about what you are doing and why as you go), say something to the effect of "Now to step through this and look for bugs", and out loud start debugging what you wrote with example cases.]

## Create an account

Register a new account

• ## Partner Spotlight

• ### Forum Statistics

• Total Topics
627661
• Total Posts
2978490

• 10
• 12
• 22
• 13
• 33