I work for a company where we do coding tests as part of the interview process. We don't ask them to do a trivial thing that they can just Google, like FizzBuzz. We ask them to do it at home in their own time, and the task is something that anyone who is qualified for the job should be able to complete with a few hours of work. The test is conceptually related to the actual product that we make. We also enter a dialogue with people about their solution, allowing them to submit improvements as many times as necessary.

I don't think you realize how terrible most people are at coding. We specifically ask for a solution that has tests and benchmarks against a reference implementation (because the work we do is performance-sensitive, so applicants should have a fair grasp on benchmarking techniques). Most don't even get the basics right.

Even then, if they show potential in other areas, we sometimes still call people in and have a conversation about the problems in their code — which is often very interesting and can certainly prove a candidate's worth, even if their implementation had many faults.

1. I know how to code, and can show it. They can check my blog, my numerous repositories on GitHub, my public sample projects, my freelancing portfolio, and even my fully-working apps and sites out there.

We do check those things as well. A lot of times public projects aren't too interesting, though, because they're either small incomplete hobby projects, or collaborations with groups of people, making it hard to find out what your exact contribution was.

2. I've already expressed interest in their position. I have a day job, and several side projects: I won't spend a sizable chunk of my free time so they can tick some boxes about my coding skills.

We're an attractive place to work, many people are interested in it, but we have to weed through many, many applications every week to find the very few that will even be asked to do a code test. The problem we ask you to solve is actually quite interesting, and related to the problem the company solves, so if you're not having fun solving it as a puzzle, you probably wouldn't enjoy working here anyway.

3. No matter how general or specific their tests is, it will never replace the proper way to see if someone fits your position: work with them on the real job, and see how it feels.

That's why a code test never stands alone. There are many other skills that a great software engineer must have, but our experience just is that the code is where many people fall short.

Now for your suggested alternatives:

• Bring me to the office for a day or two, and let's work together. I'd get to know the company and its environment, and they can see how I fit within their team and culture.

We often do that, but it's extremely costly. Not only would we usually pay your way, it's also a massive resource drain on the team to expose them to "outsiders" all the time if you aren't already feeling really good about their abilities.

• Let's pair program with people from your team or an hour or two (Screenhero works great), so I can learn from them as they learn from me.

Absolutely not. I don't have to tell you why pair programming with someone who isn't familiar with the product or code base isn't going to be a productive use of anybody's time.

• Assign me a real feature to implement from home, and remunerate me accordingly. I can sign an NDA, and both parties will have come out benefitted from the exchange.

For some products that makes sense, but most real-world projects have a startup time of several months before any developer on the team is productive. If there was any real feature that we wanted implemented, that an applicant could realistically do in their free time, it would be easy enough that we would have already done it ourselves — especially considering that we would have already had to do the work of identifying that feature, which isn't necessarily trivial.