bigpeet

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.

There should be naming guidelines just like how a team should have style guidelines. The discussions should happen when creating (or updating) these guidelines.

Then these guidelines should be followed, no need for long discussions during code reviews.

Variable name does not follow guidelines => Mark it as an issue, defer to the guidelines move on.

Pretty much spot-on.

My current company seems to apply the following variation of the motto:

Move slow, break things anyway, disable tests to hide it.

Yeah, I've quit.

I've recently got a Xiaomi one myself. Will look into these ressources, thanks.

Depending on what version of C you are using, there are no "boolean" values.

X != Y returns an integer value, no "implicit cast" required for &.