If the companies core competency is not technology, I don't see this as a big deal.

Possible duplicate of What are specific ways to learn meaningful information about company culture in interviews?

Did you move to Germany recently or are you already familiar with the German vocational education system?

I've been in Germany for the past 6 years as full time dev. I've got only high school diploma, nothing more

I never ask for coding tasks when I interview candidates. I ask questions to see how deep their knowledge of relevant languages goes, and to get a general feel for their work process. I also try and find out how enthusiastic they are about programming in general. But I personally suck at on the spot programming tasks, so I don't subject others to them.

Why ask for a coding task? There are greater and greater voices against those tests because they don't test for what they're hired. Passing a test is usually "do you know this algorithm" or "how can you go towards this algorithm", both of which can be done in a reasonable amount of time with reflection and an Internet connection. This is my answer to such tests. I'd be more encline to show I know good practices (like SQL join) and good API design as this is where to company will most likely not lose time/money on the long run.

Good questions can give quite a good idea of the depth and breadth of your knowledge without actually coding.

Where I work we don't ask applicants to do a coding task because A) you can tell just through a conversation whether someone is completely lying about their experience B) we recognise that in real life, when no one is looking over a developer's shoulder, developers Google stuff they don't know (which is fine) and C) there's a probationary period during which the completely inept can be fired anyway.

Depends who and for what position interviews you. BTW are you serious? Only high school diploma, 7 years of experience, and you got an interview for a sr. engineer/leading position?

If, for a senior position, an organization asked me to take a coding test or task, I would consider them unqualified to screen applicants for a technical position. My current position is the first time I have ever taken one, and that was because they made it clear that it was a uniform requirement and I needed to do it only to complete my file paperwork. They could not skip for a sr. position while requiring it for jr. slots.

A big chunk of being a developer is actually programming and writing code. I really don't understand why some people here say that it is inappropriate to ask to do a coding test for a senior position? Coding is part of your job, you can't be afraid of that! Also coding test is not only about knowing the most optimal algorithm for a given problem but it's about seeing a candidate's thought process. I agree with dyesdyes here I would prefer to work for a company where everyone was exercised and proved they're not uncomfortable with writing code. It's especially important in pairing environments.

@MarekR: Because 1) Any non-trivial coding task will take days at the very least; 2) If I'm going to do some coding, I need my own tools; 3) I can't do coding (or anything else, FTM) well with people looking over my shoulder.

I heartily disagree with the opinion here and agree with Marek. We had a disaster here of someone claiming years of experience and acing the interview. His performance was so terrible that even a small coding task would have exposed him, so no, you cannot talk to judge his coding experience. Small coding tasks do not give you an insight of how good someone is and are not intended as such, they are fail-fast tests. If you cannot uppercase a String by hand, you cannot code. If you cannot do FizzBuzz, you cannot code. What you also can see is how the applicant approaches a solution.

@Thorsten S But if he was that bad, then some reasonable interview questions should have revealed this anyway. How to uppercase a string etc are not IMHO coding tests as meant here - (in high-level langs at least) they are simple verbal questions with simple answers which can be pursued to discover how they think eg Can you think of another way (eg OR-ing the ASCII code?)

I agree with @ThorstenS. due to having had the same surreal experience. We hired a guy who was in no sense a programmer. I got stuck trying to turn him into one. He ended up in desktop support and was successful in that role. The purpose of FizzBuzz is to identify the candidates who are simply kidding you (and themselves, usually). Anybody who's going to write code or manage coders directly needs to do a fizzbuzz. If they take offense, that's a red flag. We've all known idiots who failed upward into senior positions and had glowing references. You must weed them out.

@peterG You are searching for a good driver in a racing team. One applicant is really excellent in the theoretical test, but clumsy and sluggish in action, a real horrible driver. How do you find that out by asking verbal questions?. You can't. You must see that those duds have detailed knowledge of the standard interview questions and how to confidently answer them. If you let code them, you see at once patterns. C++ programmers claming Java knowledge (if aString == bString), bad habits (int i,j,k,l,m; i = k = l = m = -1), how he formats and how she thinks. I will add an answer below.

@thorsten s I don't think that's an accurate analogy. IMO being able to drive vs theoretical driving knowledge are two very separate things; different layers of cognition. Akin to knowledge of music theory vs being able to improvise a blistering guitar solo. Whereas, being able to answer coding questions of the form 'How would you approach X' is, IMO again, a lot closer to actually being able to code X. But that said, my point really was that if the guy was as bad as you said, he should not have passed competently probing interview questions.

. . . .cont'd But honestly compels me to admit I have, in a previous life, attended interviews which went approximately like this - Them: "Do you know X" Me: "Yep!" Them: "OK - Start on Monday"

@Thorsten S.: Your race driver is a good analogy to coding tests. Instead of examining the candidate's performance in real races, you put him/her at the wheel of a Chevy Mastodon - automatic transmission, power steering, handles like a waterbed - in rush hour traffic, with a three or four back-seat drivers going "why'd you do that?", "why not go there?", "turn right at the next corner", "no, I meant left at the next corner!"... (And I'm curious as to why you think declaring & initializing a bunch of integers is a bad habit?)

@ThorstenS. Get Real. In this case the legal ramifications for this guy go up close to jail time for fraud. The proper way to handle criminal cases like this is exactly by this: handing it over to a lawyer and have him pay for all the cost associated, including hiring a freelancer at the time he is not able to do his work due to misrepresented credentials. This is a case for fraud, if someone claims significant experience he does not have.

In other news, seven years experience is now considered to be "senior" :-)

@jamesqf And as I said below, while a driver will drive erratically and makes errors in such circumstances, he still drives. An incompetent impostor will simply stall the engine. Declaring a bunch of datatypes is error-prone: You can do long a,b;c; on a C compiler (people switch warnings off/ignore them), resulting that c is an int and the program still very likely works. Also for char * c,d; d is not a char pointer. Also from experience short varnames like i,j,k are most likely loop/tmp vars indicating other bad styles (function/global scope, reusing & forgetting vars).

@TomTom Sure. It never, ever happens (especially if you are a freelancer) that an employer/client pretends that your work is worthless, claiming you are a cheat/impostor and refuses to pay (fully). Until someone has very hard evidence that someone is guilty, incarceration is not remotely possible. And after you poured time, costs and energy into the case, you will inevitably come to the conclusion that the end result wasn't worth it at all. Don't think you can blame someone entirely and that the law shares your viewpoint, it is a better strategy to cut your losses.

Potentially relevant link: github.com/poteto/hiring-without-whiteboards

It's usually a waste of interviewer/interviewee time. Coding is trivially easy for most projects. Getting the data organized well, testing and debugging is really, really difficult, and a fizzbuzz-test gives next-to-no clue to how good the prospective employee is at digging out bugs in complex systems. SO shows this - so many questions with reasonable-looking code, all from next-to-useless software developers, (cannot debug).

@MartinJames I am repeating myself. Fizzbuzz tests do not say anything how good someone exactly is with organizing data, testing and debugging, but if you fail fizzbuzz, you cannot do debugging (organizing data and testing are different tasks which may not need developer experience).