> Why shall I still prove myself?

Because we see candidates claiming that level of experience that cannot construct a simple for loop.

Well claiming is a very far galaxy from "demonstrating". What about references? What about networking? What about published books and papers. This stuff is very hard to make up, especially references.

It can be a chicken and the egg problem. None of those matter if the person can code and solve problems, and is a good fit. We don't care if they are 15 or 60 years old.

I think you'd be surprised that it's actually a lot easier than one might think.

Unless they are references from people who those involved with hiring personally know.

This. We get candidates (HFT) with a CS degree from MIT or something, with 15+ years of industry C++ experience as a senior software engineer, who can't explain the difference between a list and a vector (or when to use each), or give even a ballpark estimate for search/insert/remove times for a basic BST. At the same time, there are candidates who are technically good at coding, but terrible problem solvers. We do use whiteboards for the interview, but more as a conversation starter for the algorithmic design, and don't expect compile-able code. In fact, when I interviewed here a year ago, I didn't touch the whiteboard, and we just talked about the design, tradeoffs, wrinkles/edge cases, etc.

It is usually a pretty organic process. If we get into it and question their coding ability, we might ask a few basic questions, like how do you declare an array or vector in C++. Do you use std::algorithm? Then possibly into C++14 territory. It depends on the position. On the other hand, if they breeze through some basic coding questions, it quickly turns into a discussion and feeling the candidate out in terms of fit. But if we get a senior SE come in, and we talk about previous projects and we get "I fixed bugs, reduced memory usage, and saved $X million dollars" that is a big red flag.

> We get candidates (HFT) with a CS degree from MIT or something, with 15+ years of industry C++ experience as a senior software engineer...

Sounds like your expectations are part of the problem.

Why do you expect someone 15 years out of university, working in the now enormously wide software space to have your pet questions memorized? C++ is well known for being too big and needing to be subset(-ed). And, why not realize that such a person could become an expert in those questions in less than an hour of googling and reading?

The bigger problem is that companies are not willing to invest even four hours of training into employees!

I assume you're exaggerating slightly and that you mean "couldn't code as well as the resume suggested". How certain are you that the pressure of the interview (which often means broken concentration, poor sleep the night before, etc) and the unfamiliarity of the setting (even typing in a Google doc without proper spacing, syntax highlighting and auto completion can be incredibly disorienting) aren't a major factor? Isn't it conceivable that some worse coders are better under such circumstances than a great coder who suffers mightily under them?

I don't think he's exaggerating; for the past 4 positions I've had to fill (at six figure comps) 80%+ of candidates with extensive resumes couldn't solve a simple recursion problem. We give the a notebook with an IDE and access to the language docs.

These folks with many "senior" level positions on their resume can't manage a task our last hire did in about 6 minutes.

because swift remove the ++ operator?

Your approach seems sensible as a freelancer. Hope it works out for you! But I don't think it would work for someone who's full-time employed looking for another full-time employer:

1. People can't just take two weeks off to go code for another company.

2. With so many other candidates out there, a company is typically not going to bother with an "eccentric" who refuses to interview. (not saying you are eccentric, just that's how you'll appear next to the other 100 traditional "interview me I need a job!" applicants)

I've seen #2 play out in real life. Company interviewed a guy who refused to do any code on a whiteboard, even simple fizzbuzzy stuff, pointing to his multi-decade resume full of big name companies and high-profile projects as proof that he's good. The company's response was basically "OK, there's the door".

Two way street... assuming the guy was legit and confident, he'd have other offers lined up, and your company may have been the loser.

I for one commend "whiteboard refusers."

Maybe so. We use whiteboarding as a jumping off point for discussion, not to implement trees or graph traversals. It is usually apparent within a few minutes if the candidate knows their stuff, and we move deeper. Additionally, there is always going to be an onboarding period, where the new hire is learning how our team does things. We spend a lot of time communicating and drawing out ideas on whiteboards. We need to see if you can communicate clearly. Saying "naa, I don't whiteboard" is NOT a good start. In all likelihood this person would be a bad fit.

Yes, the key is whiteboards are for diagrams, not coding.

I'm not sure I'd go for that TBH. I've seen candidates who are good on paper (one former university lecturer springs to mind) who was incredibly difficult to understand and his experience was irrelevant.

We typically need to hire quickly, and having to wait 2 weeks - and coach someone on all the different components, create accounts for them, etc. - is not "free" for us.

If you're that good you should blaze through the technical questions in half an hour, and give us all confidence we're not wasting each others' time.

Then again you're a freelancer to so it's a bit different to being hired as a contractor/permie. But either way, we want the hiring gap filled, not as something we have to revisit after 2 weeks before we decide whether we have to go back out to market.

Put it this way. You come in for an interview, refuse the tech questions and we're left thinking "this guy looks good on paper, so why doesn't he want to explain what a design pattern is?". Straight after you a guy comes in who answers the technical questions OK. Who do you think we'd hire?

Talking about patterns, technologies, how I would architect/design a specific solution or how I would approach a technical problem is not a technical interview, IMO. And I would be glad to answer these questions, which are fair and interesting. What I'm talking about are the quizzes and the puzzles, the invert-a-binary-tree riddles or, as it happened to a friend recently, to write a full blown application with tests and stuff and don't even bother explaining why the application was rejected.

It doesn't make sense anyway. In 25 years, the sheer amount of cowboys I have seen literally bringing down projects out of incompetence and lack of humility is staggering. And these guys were hired out of technical riddles.

Oh right. In that case fair enough. I'd far rather have a walkthrough of some of your github code to see your style and reasoning.

As a Good Person, you should get taken on by clients who don't have this requirement while others who do lose you.

I've only done one of those tests in the last couple of years because I wanted the (not insignificant) pay rise and it gave me an opportunity to learn something. It's all about negotiating power (they had more).

But yeah, in general I don't have to bother with them. OTOH I don't see them as entirely negative because hopefully it should mean you'll be working with competent people (provided the tasks are small demonstrations and not full applications which smacks of incompetence).

Also, don't you think that the technical competence of a candidate is just a fraction of the elements required to work in a company? What if the guy is a complete toxic worker or dishonest etc. etc. It is not that difficult to pass a technical interview, after all.

I think that two weeks are a good time-frame to evaluate a mutual "love" and would also help better understand the soft-skill and how well the candidate fits in the company.

Yeah there'll still be a probationary period in case someone's toxic. But being inadequately skilled is a deal-breaker and something you can go some way to filtering for before you offer someone a job.

Shouldn't that be the other way around? If it doesn't work out, charge the 2 weeks, if it does, you get a job?

If you go with the notion of "I don't need to prove myself, I'm good enough - look at what I've made", then this is exactly how it should be. Otherwise you're still proving yourself and providing 2 weeks of your highly valuable time for free.

Those 2 weeks should determine whether it works out on other levels (e.g. are both parties comfortable with working each other) and if you do work in that time, you better charge for it.

You grossly underestimate how conservative and risk averse most clients are.

As a consultant I have tried a variation on your approach. I've offered to work for a client for 2-3 weeks. At the end of which THEY get to decide how much I'm worth. I reserve the right not to carry on working for them but for those 2-3 weeks I will accept whatever they pay including nothing.

In over a decade not one client has accepted this deal.

Dunno, not sure this applies. My reaction would be that it is too much to think about. I'd just want to pay a certain rate and be done with it, not load up on ambiguous ill-will.

Now, the GP says he will work first two weeks without pay? Simple to understand and accept.

I'm sorry, but I'm not sure I understand. Why do "they" decide how much you are worth? Don't you have a daily/hourly rate that you communicate up-front?

The whole purpose of the offer is to let the client decide how much you're worth to them. I provide no up-front rate or fee.

It's always the clients who claim to be 'innovative', 'game changing', 'disruptive' etc. that are the most risk averse. They seem completely blind to the cognitive dissonance.

Maybe it'd require a trip to their (no doubt expensive) lawyers to make sure the arrangement doesn't sound too good to be true and open them up to legal action if you're not happy. Perhaps it's not worth the time/effort/cost for them?

This is why I prefer dating contracts to deep technical interviews. If someone shows enough promise in their CV and portfolio, and they're personable enough to sell themselves reasonably, then a 1-2 week contract to cover some real work is low risk and a better measure than trivial whiteboard problems.

... and you are guaranteed to only get people with nothing else going on in their lives, such as their current job or degree program.

I can't upvote this enough. In the age of Github, if a candidate has an impressive body of work and can "talk the talk", a coding interview is wasteful, potentially misleading and insulting. As soon as enough candidates balk at them, companies will stop doing them.

I don't have a github account. All of my work previously was academic research, in which I have 10+ years of writing software, and currently it is all industry/proprietary. I thought the process I went through at my current company was great. A short phone screen, a coding test (~1 hour, with a week to complete), then an on-site, which took 1 day. The first two hours was a coding test, then I met with several teams, which were mostly high-level discussions and a few problem solving questions.

We're not architects, and nor do we have a certification system. There needs to be SOME way to probe a candidate's abilities, and it's not easy.

That sounds like a sensible way to work as a freelancer. Have you already had success with it or is it just a plan for the future for now? I'd be interested in hearing how it pans/panned out.

Well, yes and no. For around 3 years, I have been running my own consulting company with a friend. We were doing pretty much what I do as a 'solo' consultant, except that we were fronted by a company. This automatically removed the need for interviews. As soon as I sold my company and got back to solo consulting, I had to re-enter into this ridiculous circus which are technical interviews.

So, to answer your question, I will apply this approach from 2016.