pouët.net

i think all of the above speculation is a bunch of bullcrap and it all depends on the EXACT function of the guy (if he needs to hack obscure chinese linux kernels for DERP-chips all day, communication skills isnt really that relevant), general style inside the company (many variables there too) and probably more things that i cannot be assed to sum up.

if you wanna find out if someone is technically good at something. ask him to do smth technically good with that something. if you cannot come up with a way to test/paraphrase that into an assignment or whatever, you're obviously not meant to be a recruiter anyway. talk about being 'good at something', eh?!

@Gloom: Yes I have read punqtured's comment.
I think I wrote this thing so that maybe I get some advise exactly.
Fortunately, in late interviews I become more confident in my saying. It will improve.
I shouldn't whine about it much, everyone gets a job at the end. It's just painful that it takes so long.
Friends see what I do and tell me "This is impressive! If you apply for a programming job, they will hire you asap". So, it's ironic for me. But they don't see how many more skilled and experienced programmers are there and of course all the other factors that play a role.
Then again what I don't know is what each interviewer excepts to find and some don't even bother to tell you why you were not hired.

Then again, there were few jobs I thought I failed and it was my fault, but I learned from other sources that that company didn't hired anyone from the 20 and instead hired another person who some employee knew personally and proposed. It happens. I don't blame them, there is insecurity, so many candinates, not sure who is the most suitable, fear to hire the wrong guy.

So, sometimes what a company wants is quite subjective as subjective it is whether tests or plain interview or anything else works best.

Maali: I respectfully disagree. While the exact function the person has to fill is indeed relevant, I believe that finding someone to hack obscure chinese linux kernels for DERP-chips is an edgecase you usually don't encounter. :) More often than not, hiring is a bit more generic than that (and indeed, in this thread we're talking about hiring programmers in general). Programmers need to function with other programmers, and while there are examples of brilliant but entirely disconnected people working at larger companies, their expertise needs to be beyond exceptional to allow for the added cost of having what basically amounts to a support staff around this single individual.. and that is rare.

That is very true.


..and what you should take from that is that your friends and family will lie to you. :) They do because they like you and want to "protect you" in some way, but in fact you the opposite is true. While you shouldn't take a generic "sorry, we went with someone else" as direct criticism of your skill or talent, it's important to weigh the evaluation from someone who don't know you differently from that of your best friend.

Optimus: i think you have 2 points that make you dodgy as a hired programmer.

1) you dont seem to be able to do things under pressure, (you get nervous doing exams, you cant think properly when people are looking over your shoulder or putting you on the spot) for many companies this is no good couz the real world demands this of projects every day, so if they would hire you you would just end up curled in a corner of the office stressing out and wondering when can you leave, this is not productive for anyone. the only way you can fix this issue of yours is by being more experienced and self-confident in the things you are supposed to work on. so if i was you i wouldnt bother applying to job interviews where you know they'll ask you to code things you're not familiar with, be honest with your cv and when they ask you if you can do this and that say "i could try but its not my area of expertise". which leads us to the question: what is your area of expertise? if you cant find jobs in a category that fits your profile then you need to either widen your network to figure out where they are or get some new skills in other fields that interest you (where more jobs are at) if you dont know what you want to do thats fine too, make a shortlist of possibilities and give them a shot each with short projects for a few months. then you'll know if you want to go deeper or go back to other things.

2) you seem to lose motivation rather quickly. might be my perception that is wrong though. but if you transpire that in an interview they wont hire you unless they know they have a good way to motivate you, and lets face it most project managers / team leaders / human resources suck at handling that, they play the psychologist for a couple of weeks if you're lucky and then tell the boss to give you the axe if you dont shape up. even worse then not getting hired for losing motivation quickly is to let it happen while working on an important project, you will already be feeling like shit, your boss will chew on you for sure and you will feel even less motivated for the next project. they expect you to deal with your shit at home and come to work motivated to get things done for the moniez. i think the only advice i can give you on this front is to push on. making sure you're joining a company where the projects will interest you is also quite useful. but you wont like all projects you will have to do, and there is always a lot of compromising. push on through the ones you dislike knowing that they will be done with once they're done with and that you will then be able to focus on something more interesting. if the ratio of uninteresting/interesting project is too low after a few months/years, then you're working at the wrong job.

i just respectfully disagree with the fact you bring 'being able to work in a team' analoguous with 'having social skills'.

I've done a lot of testing of IT engineers. From experience, the best route is to put them in front of a computer with the IDE you use, and give them a few basic tasks related to the kind of work you do. Keep it fairly open of course (i.e. don't expect them to have knowledge of all your APIs etc.) Tell them at the start that if they're unfamiliar with something, get stuck, have questions etc. then to just ask. Then watch them do it.

You learn more in the first 5 minutes of this than you'll ever learn from interviews and written tests. I've seen guys breeze through the interview and get high marks on the written tests, then when I'm asked if he was just as good in the practical part the answer has been "no, he was completely useless"!

Also, you can see what kind of person they'll be when you're working with them. Some don't deal with pressure well at all (some break into a sweat, get the shakes, and just lock up - always entertaining to watch :D). Some breeze through it in 1/2 the allowed time, then spend the other 1/2 criticising the test and telling you how they would do it - brilliant, but you don't want this type in a team ;) Then there are the ones that get stuck on something basic and have to ask, then face palm when you tell them and get on with it - they're usually the best, you know they'll ask for help when they need it :)

so i dunno what kind of subspecies of humans show up at your job offers if their social skills are THAT awful :D

not sure i agree there. it greatly depends on their attitude of the criticising ofcourse. i always found it beneficial to have people with a little (a lot) of critical thinking, as long as they are just as open to compromise when proven wrong or told there is no time for that level of refactoring.

but yeah, i guess the ratio of critics vs lambs should be alot lower in a team. unless you're looking for lead engineers or strict team managers :p

ps: while i agree with you in principal, in practice the people that do this in an interview are pretty much all arrogant cunts you wouldn't want to work with :D

people without communication skills should be shot.

As promised here is an update:

I collected some of the ideas from this thread and put together this test.

First, I gave it to two guys already working with me (just for reference):
- the first is a very smart guy with a very steep learning curve, but without too much experience.
- the second is guy with many years of experience, but is a little careless.

After that I had 3 candidates tested:
the first went pretty quickly. But after the the second candidate I decided to change the test to make sure guys actually manage to understand the code in question 4.

So I changed test to this version, and gave it to the last candidate of the day.

btw, It's really amazng how people fail the FizzBuzz test!

Your test is pretty easy. Do you think it will really suffice to select able candidates?

Adok: have you seen the results?! Mind that no IDE is involve, just notepad.

Christ it's scary to see the real-world answers from the applicants.

Question 7: Social skills
a) Give a concise summary of what you did last friday night
________________________________________
________________________________________
b) What was the last pickup line you used?
________________________________________
c) My mum (tick where applicable): []does my laundry []cooks for me []MOMMY!!!!! []phones me twice a week []my dad
c) If a random Mensa member (not Adok) claim you're not able enough, which five swearwords will you throw at him. [Please order them alphabetically, just to verify your IQ is above 70!]
__________
__________
__________
__________
[yes. trick question!]

my english is as awful as in the original test by TLM, damn :DDD

:D

I wonder if they also test farming applicants that thoroughly (DRIVE THE TRACTOR AROUND THE HOUSE! SHOVEL ALL THE PIG SHIT! SLAUGHTER THE BUNNY! BEG FOR SUBSIDIES FROM THE GOVERNMENT! ALL IN 5 MINUTES, WE HAVE TENS OF PEOPLE WAITING FOR THIS OPPORTUNITY!!!11).

I would not give that piece 100% - consider negative values!
Also piping into the wrong direction on cout streams - should not happen.


Shouldn't this be something like?

Considering "string" is std::string in your test.


Okay he's of by one - but he's way better than the guy with the wrong piping direction and takes the readable and easy solution - also consider that a proper compiler can and will optimize on common [sub]expressions . Thus computing that thing twice should not matter at all with a proper compiler.

Maybe you should talk to them after the test - and say something like - "you are computing this shit twice - is that a problem? And if not - why and under which conditions."

you drove the tractor in the 3rd gear most of the time while you should have been driving on the 2nd gear on the uphill sections! clearly a no go.

i was thinking for a while on why so many applicants would fail the fizzbuzz test. there is no need to be familiar with mod while learning programming language. us, sceners who enjoy byte wanking and graphics programming by nature are used to it. folks who got into programming by learning java, delphi and c# wouldnt give a rats ass about it :p and not having it in your daily vocabulary makes it hard to come up with under pressure :)

i think i would only have had trouble with the regex of that test :S never been much into regex stuff, only used it a dozen times with very bipolar rate of success. but guess i could have pulled a semi-decent answer out of my ass from consulting the wikipedia page about it.

"this is a regex defined to validate and specified input String that really matches this regex."

it's captain obvious! hire immediately!

btw,

my regex is a bit rusty but shouldnt the dash be escaped here?

las: remembering correct piping direction is a deal breaker for a good coder? :p anyone coding c/c++ stuff has examples around that use it properly, its not really something you need to remember. if all you do is c/c++ then it makes sense you remember those details, but if you change context alot i doubt that many coders would keep those semantic details in their head for eternity.

Gargaj gets the job! :)