The myth of the developer that can't code

That is true, though I must also add that some of the ones in question came from prestigious and world renowned universities. Once you'd struggle to get in(in theory apparently, because otherwise I have no idea how that works). They all had the "senior developer" in their titles with near or double digit years of experience.

general developer: I don't know why people want to find out if a person can code? ... I assume that a person can code ...(if not you will see very soon)

I mean it's not about writing "hello world". If the person is not dumb, you won't find out in an interview if someone can really code. (repos are much better for that, but can be deceiving)

"We have a 3 month probation period and if something is really not true it will have consequences. I'm crystal clear about that."

I mean we are all humans, but there is also a contract with money involved. I have to look out for the company and it has to be fair for all the other team mates/colleagues too. If you hire some "faker", without consequences it will destroy the whole team balance. (Additionally there is a "meet the team" to address the consent process). From my experience, technical people have a low tolerance for people which can only talk...(in a technical team).

So it does not mean you are safe if you can make it through the inverviews with tricks. (it may seem a bit hard, but I don't like the general acceptance of "lying" or superbeautify ^^ in the application process)

And then I talk about what we are working on and how we are structured. So the interviewee also gets an impression what the day to day work will look like.

What I really want to see, is the ability to solve problems. Because this is our real job. We are solving problems(with code). So I ask questions you can not solve in 5 minutes, but you see how someone approaches a problem. Is the person collecting intel about conditions and constraints or is he/she immediatly starting to code etc. ... For that I generally take real problems we had and we already found a solution. And sure I tell them, that it is not possible to find a solution now, because many interviewees are "conditioned" (or used to) to give you immediate solutions. Else they would panic or getting frustrated.

In general ask a question: Why should I want to barbecue(or embarass) a possible colleague?

You also have to take into account, that there are people which don't know everything yet from the specifics you need. But in the right environment with support of colleagues, they become really great. It's more about the mindset & willingness to learn and also the support of the team members.

The above is more for a general developer.

For an expert with 7y+ (whatever..) experience in a specific topic. I would really ask very specific questions and maybe a "homework". Because I hire an expert for specific experience in a topic. Also the risk of losing money & time is much higher. Because it's experts work...it's hard to judge if the person is not capable or if it really just needs some extra time.. ;-) You won't believe how many people have a lot of years of experience and made only basic stuff during that time. So on paper they should be an expert, but in reality they are not.

Yes, but that's not your "professional" work (which is copyright your employer), it's your "amateur" work done in spare time. Which is a pretty exclusionary approach to hiring.

It would be very different if more employers paid more than lip service to professional development and encouraged the publication of personal githubs on "work time" as part of that. It sounds like (some of?) the big Bay Area companies do, but those are the ones after the big hiring barrier.

The actuaries I know spent a lot of time on exams, but also in their early years got some time set aside by their employers for that.

>They are asked to submit a portfolio of their own original work.

How do you assess that it's their own work?

> Incompetent programmers don't have anything to show, and our industry makes it easy to come up with excuses about why, excuses that wouldn't play for a digital artist.

Such as?

One thing to bear in mind is that ultimately there is no perfect way to hire, whether programmers, artists etc ..

I've worked with "developers that can't code".

One example was an external contractor who, according to their CV, had multiple years experience with programming in C.

The person was tasked to fix some errors in our code base that the static code analysis tool found, e.g. remove implicit type conversion, etc. They submitted their changes for review, claiming the analysis tool reports 0 issues now. Their code simply did not compile (and the analysis tool only works with a successful compilation)!

Even after explaining the issue, the developer asked if the task is completed now and if they could move on to the next one.

This wasn't the only time this developer proved that they "can't code".

The issue is that it is very easy to claim to have experience. There are a lot of self-taught programmers out there who learned coding at home by themselves. How do you differentiate those from people who "can't code", but claim to do?

I like the approach to let them implement a small(!) piece of code ahead of time and in the actual interview let them explain their code, their decisions and ask questions.