pouët.net

That said, personally I wouldn't mind doing that kind of thing, even with 'competitors'. For the expected salary, with additional compensation for "time wasted" if it didn't work out, of course.

Social abilities and a match with an organizations culture is far more important than any technical achievements. Technology can be learned. Ability to get along with your other employees usually can't.

I don't know. I had gone through various interviews and tests for a year and still nobody likes me. Maybe I am not good enough regardless that I code for a hobby. Maybe it needs more than that.

Plain interview can be subjective. So many candidates to chose from. I think I might not look confident enough, I am anxious, I am not an extroverted person, sometimes I stutter, maybe I am not convincing. And I had some interview from the phone, it's very hard from the phone, several times I had to ask them again to repeat. I don't know what message I conveyed.

So, I felt tests where a bit better because at least there is a chance to show them that I can program. Problem was, I get anxious with tests and I can't focus when there are so many things to do in a very limited time. There are things I could code and deliver not pressed by the time, and for example I manage to deliver say 6 from 8 of the questions, but much later I realize when I tried them in a compiler that I made horrible mistakes and only 2-3 of the 8 might be right. Yep, in some tests I didn't felt there was time to open a compiler (I will do so from now on though). I had one test recently that was better, I was given a laptop and left alone to code my solutions on the compiler (btw, don't stay above someone's head when he is writing code) and I was sure for the first time I did correct, though the other 50% of the test were SQL questions I wasn't experienced with at all, so fail I guess :P

Then there is the third solution of proposing a project that one has to deliver next day or next week, the good thing with this is I can have time to actually code my solution and deliver, though I know many people don't like this because they are not going to spent coding days for free. Though I had a test like this and failed, because I missed implementing everything in time and I know some things are horrible because of lack of time.

I am a bit sad because I see people around me that are not programming for hobby, getting jobs and living the country with much less tries than I had, and I wonder about myself because I want it too much and I am fed up with failing.

p.s. I do insist that I program as a hobby too, I give them some links, sometimes if given the opportunity I show them something, only thing I haven't done is a portfolio. It's like this doesn't matter much. I should do this too and point them there..

Try to make the potential hire implement a bunch of obviously broken designs. The one who decides to go after another job instead is who you want.

Turn your focus on other things than your code. In a team, you need to be able to work under preasure while others watch or even wait for you. You often need to be able to present your completed work to someone that doesn't understand code. If I were you, I'd try to improve confidence in that what you're doing is good if not the very best.

not necessarily, you dont want quitters to work on your project. if they manage to implement a broken design within reasonable results, that just means they're 1) dedicated and 2) good.

Oh! And if you were applying for a job with me, mentioning the demoscene wouldn't hurt at all ;-)

Yeah, being picky about the company you decide to work for is quitting.

How I interviewed people for 2 Java & web developers.
- Some basic questions about the Java programming language.
- Very basic Java program to be made on a computer. By basic, I mean very basic, something like 'Hello World', a 'for' loop, etc... Each program is an incremental addition to the previous one, to save time. The aim was to ensure that they actually know Java. No Eclipse, just notepad, a shell and the compiler.
- One task is to change some text in a website, it can be done by using the search function of the imposed text editor, an obscure one.
- Wifi connection is deactivated.
- One task is re-factoring of a little OOP exercise. Just to check there coding style and approach. Actually, no real good answer, it's just to test the reaction.
- I don't look what they are doing, I'm a few meters away. They take the time they want to take.

And... Half the people didn't really knew Java. Some asked to check stuffs on the net. Some did not ask, they set the Wifi on, then switched it off without telling me (it was of course logged), and forgot to delete the browser's history. Or some did, but also deleted my own browsing history. Some panicked because the text editor was *THE* one they are used too, not bothering looking around at least 2 mn. Some where honest about not knowing something (fine, you can learn), others tried bluff and techno-babble, some did "hey I'm a management guy anyway". Simple stupid test, but it was really revealing.

I like 216s idea.

yea, 216s idea was neat, indeed.

plus you want developers who have a certain intuition for what the customer wants, not what the specs/requirements say.
(and who play well with the team, of course, i.e. what Punqtured said)

Punqtured, your points are partly correct but then again consider something like this. Would you hire the juggler just because gets on well with the team, but still needs 5 years to actually learn how to juggle? People should know at least some of their shit, which this is all about.

216: there's picky and there's flighty. i don't want primadonnas who bail when things don't go the way they please, even if they have ridiculous skills to back it up. (also known as the cristiano ronaldo syndrome.)

i'd much rather have an amateur go teeth-and-nails at a problem and give it all they got than someone who could fix a complicated issue in half an hour but thinks it's beneath him.

also, fat good does it do you if he already left for another job thinking "man these interviewers are a bunch of idiots, trying to get me to do this obvious bullshit."

i like 216's idea too.

my general line of though is: if you think you need a practical examination of the people you want to hire - then you're hiring in the wrong segment. i'd say it's better to get references from earlier jobs or projects.

if i was presented with what marmakoide proposes - i'd walk away silently from the meeting knowing that the company isn't worth my time.

if an applicant states that he's a programmer, then please assume that this is true until otherwise proved. anything else will bring bad karma into the interview.

imposters are "easy" to recognize by having an informal chat about earlier jobs/projects/school projects/etc.

the only kind of "examination" i'd say is relevant is a personality test, which shouldn't be executed until you know that you really want to hire the applicant.

@rasmus It was not in Europe, but in a much less fancier place with way more sun. I was sad to do it like this, but I felt that in the context I was, I had to do this. To local standard, the positions were super attractive, not a out-sourcing sweat-shop. Sadly, this is where most developers are there, most of the good ones are gone to greener pastures. And the others got balls that I could hardly imagine at that time ^^ It might sound strange, but the reactions of the candidates were very revealing. In the end, if you go 'WTF those guys sucks', then it's win-win :D

Spot on.

Err. First of all -- read what punqtured wrote. Then read what you wrote yourself. And no - "coding as a hobby" most certainly isn't enough to get you hired at most decent companies.

I have done this a few times and it's worked out great. In essence, it's what internships is all about (except those are usually not paid very well).

Also, I forgot the most important part of the process: CV sorting and calling people before actual interviews. The sorting of CVs is what most hiring processes spend the most time on -- simply because it's important to reduce the number of applicants by removing simply unskilled people. And by that I don't mean just tossing out people without certain degrees or a gazillion years of work experience. A CV can usually tell a lot about a person, outside of pure skillsets.

Keep the ones you like based on their resumes, and then you call everyone that you keps. I can usually tell if I like someone enough to get them back for a face-to-face interview in the span of 5 minutes.

It's very basic, but if you go through this process properly, you can go from 59 applicants (resumes) to 12 (phonecall) to 3 (face-to-face).

Those numbers are from the last hiring process I was involved in.

gloom: you are obviously the recruiting expert

Everyone involved in hiring are experts. No one knows their organisation better than they do. Afterall - being in a position to hire others usually doesn't come from nothing. If you're the founder of the company, you have a completely clear idea of what you need and what type of people you want. Otherwise, you've proven your skills as head of a department, and is somewhat used to hiring and firing employees. That said, there's always some uncertainty, and every now and then, your gut-feeling fails, and you end up with someone that doesn't fit your department at all. That's when the not equally fun part comes into play, and you have to let people off due to incompetence. It's a LOT easier to let people off based on technical skills than personal skills. Therefore, your primary focus should always be on candidates' social skills.

And to those now thinking "But introverse and shy people can be really good emplyees too", you're right. But please trust your boss to know about team dynamics, personality types and human resource management in general. There's nothing wrong about being shy or introverse, as long as you know your role as part of a team.

♻: not an expert, but certainly experienced, yes.

(Oh, you were trying to pull a funny due to my comment in a different thread? I see -- how clever of you -- well, if you examine the two scenarios you'll probably see that they're in no way comparable, but I'm sure you already knew that when you decided to just flame a bit anyway. Good call!)

Which is exactly the point why you go through the process of eliminating technically unqualified people first, and then move quickly on to personality and communication skills.

I've hired shy and introverted people too, because they showed great skills and definite potential in the interviews and/or testing period.

In my experience, people who are shy and introverted and complain loudly about not getting any jobs because they are shy and introverted usually weren't bypassed because they were shy and introverted, but for being incompetent in some way or another.

"i really respect Flint's business acumen!"

Thanks!