pouët.net

TLM: just be careful so you don't fall for the age-old "trying to be to clever for your own good"-hazard. There is little point in making tests that only tests how good your test-subjects are at trick questions.

having screened a lot of people those past few months, there's absolutely no point in whipping out fancy questions. it is utterly depressing just how high the percentage of people is that you end up rejecting because they fail on basic stuff.

gloom: I know what you mean. There is no doubt that a incompetent smart-asses might do well in the test. I think the test should just use as an initial filter.

For example, assuming that we have 3 types for developers (and their percentage in developers population):
- incompetent (85%)
- incompetent smart-asses (5%)
- competent developers (10%)

I wish to filter away:
100% of incompetent
50% of incompetent smart-asses
0% of competent developers

That's why the test is relatively easy, I think we all agree that any developer, with/without background should be able to answer the test. In reality so far not many did good.

Yat-another-point about the demoscene and programming skills: we (if I may include myself) the demoscene developers are usually guys that enjoy coding, we do it as a hobby for many years. We are always interested in creative programming, smart solutions and technology - We simply enjoy it.
The problem is that most out-of-the-scene developers aren't like that, many times we keep on forgetting this, but the average programmer doesn't see the beauty in coding. Some of you will disagree, but I believe that doing something you love for many years immediately makes you good at it.
Point is this: while the test look to you all very simple, it's only because it's indeed simple for YOU, but in reality, for the average developer - it's not, hence the results :)

*Yet-another-point :)

TLM: in terms of hiring, it's no secret that if the person conducting the screening/hiring process is familiar with the scene, and you whip a little scene-knowledge out in the interview, you stand a higher chance of being accepted.

I'd never ask a technical question in a interview, especially a "I am autistic and I like to masturbate with C pointers" one. I find them completely pointless and annoying.

Rather, I'd ask the candidate how they'd approach a given problem, something like "how would you do this effect":

http://jonathanpuckey.com/projects/delaunay-raster/resources/delauney-moss2.jpg?thumb=ec19eb8d9248b716e50d204f436990e9

i really really hate coding tests.

it's been a while, but if someone did whip one out on me now i'd probably find it insulting and tell em to shove it :) . but aside from that, they irritate me because they're so often irrelevant to actual skills needed for the job. like personally i dont often write code without a compiler to check the syntax for me, and i rarely have to deal with spaghetti coding horrors because i dont write them myself - and if someone i'm working with wrote it i'd make them change it themselves.

case in point - i still look up the odd bit of basic maths or even some esoteric coding syntax now and again even if i once knew it just cos i dont use it often enough to remember, and google is always nearby.. that doesnt make me a bad coder or bad at maths, though (even if i actually am).

in general i think hiring coders (especially in games/graphics) is like hiring an artist - you want to see their portfolio, know what they actually did on each thing, and you value stuff they did on their own. then you want to discuss things in depth, understand their approach, knowledge of the hardware, how much they innovated.

i agree with something someone said tho - debugging is a skill that really separates coders imo. its really interesting seeing people's approach to finding problems when they occur. not just using the actual debugger (altho its shocking how many cant) but the whole problem solving approach. particularly in graphics.

syntax can be learnt and screwed up easily - but coding is mindset.

navis: yea, "how do you do this effect" or "how would you achieve this", exactly..

Navis: Is it a delaunay triangulation out of random points took from where the image exhibits significant gradient on the luminosity?

smash: I find that you can usually separate the weak from the strong by looking at their past projects-list and ask specifically what they did on that project. There is a lot of resumé-padding out there.

gloom: exactly.
coding tests are good for graduates, although id still expect a graduate who wanted a decent job to have done something on their own to show off. if they came to an interview with nothing to show except a degree certificate i wouldnt be interested.

nystep: yes, the random points are not random but follow a heuristic (corners or local fuzziness or something - there isn't a right answer, whatever works best for the visuals).

You may not know Delaunay (and that is fairly reasonable) but you should know about the concept of triangulation and topology if you're applying for a graphics position. Similarly, you may not know about what causes the random points to appear where they do, but you can guess the answer. What matters (to me, in an interview) is the train of thought, not knowledge.

At our last company we had that one test for prospective game programmers where we put the applicant in front of a computer and said "Here's an empty C++ class skeleton with one method that gets called once per frame. This function draws rectangles on screen, this other function gives you the joypad stick position. Now write $VERY_SIMPLE_GAME_FROM_THE_70S - you've got two hours, and don't worry about finishing". Even though most applicants didn't finish in time it gave lots of insight into their way of tackling problems.

smash: i totally agree with you - actually i wrote something similar in my opst.

post

@TLM +2^2^2^2^2
I of course don't blame them, but most people doing coding job don't do it for the love of coding. They happened to pick a bachelor or master in IT and happened to get a job in IT. They would love to be, I don't know, firemen, stuntmen, helicopter pilot whatever they did not dare to or could not do. And they have to fill the fridge, conditions are ain't that bad, but coding or making tires, same same. A ill-effect of this is, such people might not be the sharpest knifes. In some countries (1st hand experience in Asia, for me), people pick jobs just for the income, the aspect "job motivation" and "emulation" are non-existent, because in those countries, life is just way harder than say, West Europe.

And as others underlined it, it's just one dimension of the problem, being able to listen and talk with customers without enraging them is good for the business. For that later aspect, how would you appreciate that from someone ? (true question, not rhetorical)

Haha! :) That rings a bell. But indeed, you MIGHT if you're applying for a job, because you'll have to deal with the code and design errors that people have done before you even stepped or knew of the company. What a nightmare..

In the past i had to deal with a significant spaghetti/meatball coding horror, in which meatballs where modules and spaghetti was the messages between them. I've learnt at least something. If there is any coupling between 2 modules, then don't separate them, you usually want to keep variable synchronisation to the strict minimum as it is something that is prone to errors/interblockings/mystical crashes.

Another thing is to avoid that type of programmer who are proud of how much code they write, regardless of what it is actually doing. They usually try to make problems look bigger to get other people to bow in front of them, and they end up wasting quite a lot of project time. It means that since they write more code it is more prone to errors (the less code the less trouble), and it is also harder for others to understand/debug/maintain it.

Some people get proud of a particular compiler or low level trick/hackery but i don't see the point to write code that others might not understand easilly. It's not a good idea to test on these in my humble opinion.

I've read in this thread one utterelly idiotic statement that social skills can't be learned. Well, it's just plain wrong. Social skills are learnt by everyone, but their rate of learning depends on the number of social interaction the person gets, so it develops just more slowly for "autist" people. When the early interactions in one's life are painful, he will try to avoid them to protect himself from negative/painful situations. It's natural.

But indeed social skills are *very* important in a programmer team (or any other team of creative people who have to come up with solutions for problems). The "problem" is that the ideas of the most socially skilled person in a team of "equal" programmers always wins. Regardless if a less socialy capable person comes up with a better idea, it will be immediatelly wiped of by a person who has more self-confidence. That's why a team of people may not always come up with the best idea to solve problems.

nystep: which is why you have a project manager -- someone who is not a die-hard coder, who can play devil's advocate.

Actually, it could be solved pretty easilly if all ideas where submitted anonymously to some kind of intraweb by the team and then everyone brainstorms and talks about them together. (we can imagine a vote system and so on).

That doesn't really change the fact that the socially skilled person has the best skills to persuade others and that a more introverted person is not all that likely to defend their ideas (that could be a lot better) in such as situation.

Also, design by a committee is something that is not at all always preferable. Even if a particular solution is not objectively (measured in whatever way applicable) the best one, it might still be Good Enough(tm) and produce less friction and issues overall than a long discussion process culminating in votes and so on. This is even more important in an environment with corporate politics or other bullshit since a strong spokesperson will bring attention, resources and focus.

preacher/nystep: the trick is to know WHICH decisions require/are best suited to be solved by a committee, and which are best left up to the individual. Again: this is why you have a project manager -- perferably one with some experience :)

marmakoide: I believe that everyone has a different set of skills that usually balance one another. An Mr. amazing coders might have lower socially skills, Mr. Steep-learning-carve might not handle well long system maintenance and Mr. Clean-code wouldn't handle spaghetti as it will drive him nuts.

Point is that nobody is perfect, and I don't see the lack of socially skill (or any other quality) as a problem. As a team leader, my job is to make sure the correct person gets the correct job the matches his strength and ability.

Have two or three subjects one might not know, ask them with which are more familiar and which less and then test them with the less familiar and explain them you want to see if they learn fast. Nasty too, I know :)