Sijin Joseph

I can tell you something that has worked very well for me:

1. Grab a sub-set of the competencies that you NEED to have https://sijinjoseph.com/programmer-competency-matrix/

2. From that subset, setup questions for the different levels
For example, for the VCS competency we have:

source code version control
Lvl 1 questions:
"- What is the difference between Git and Github?
- What is a branch?
- What is a pull or merge-request?
- What is a commit?

Lvl 2 questions:
- Mention other VCS besides Git
- Mention good practices of a Commit (short title, description content, etc)
- Describe one branching model (aka gitflow or other)
- What is a cherry-pick?
- Describe good practices of a Pull/Merge request

Lvl 3 questions
- What is the difference between a Merge and a Rebase? When to use them?
- What is Git Bisect? how to use it?
- Git vs Mercural or other DVCS.
- What is partial clone?
- What is a Git Submodule?
- What are Git Hooks

3. Split your 1 hour interview into 2 parts: Coding and Q&A. For the coding part, ask them to build something, in their machine, with the language of their choice, sharing screen. The problem should be something for 1 hour, and split in steps (I usually do 6). With this problem you will score coding ability, cleanliness, defensive coding and similar stuff. I usually score between 1 and 3 (1 - Below Average I have seen, 2 - Above Average I have seen, 3 - Amazing/Impressive)

The second 30min part is Q&A, use the questions to check whether…

This is spot on. Obviously there is a lot to dislike about performance reviews, but big companies need some process to determine who gets a raise, who gets promoted, etc. Although flawed, performance reviews are the best process for that.

I think the things that companies can do to make them better are:

1. Have well established career frameworks (aka career ladders) ahead of time. These should be as detailed as possible. https://sijinjoseph.com/programmer-competency-matrix/

2. Have transparency about the ranking system and distribution to all current employees and future employees.

3. Ensure that some amount of accountability is shared at the department level and also at the team level, so you can have somewhat objective conversations about trade-offs between departments and teams.

Things seem aimed a bit more at designers than developers. If it was to be more developer-centric it would definitely need some references to things like GoF patterns, dependency injection, code reuse, testing/testability, loose coupling, etc. Someone could have a perfect score on this and potentially be terrible, even at web development specifically. If someone had a perfect score on the programmers competency matrix, however, they would be a sure thing.

http://sijinjoseph.com/programmer-competency-matrix/

The best sort of skill tree is one where it is hard enough that you cannot make it down every path in the time that it takes to play the game (in this case a career). Someone needs to create a new competency matrix with a broader scope.

Can't say I learned much useful from getting (most of) a CS degree. I dropped out to get a programming job, which was much more useful :)

So good news: you didn't necessarily miss very much. Get a basic algorithms/data structures book and skim it, and you're good to go.

But like all programmers there's lots more to learn, and mostly you will learn it on the job from coworkers. Things like testing and API design and performance analysis.

http://sijinjoseph.com/programmer-competency-matrix/ is useful (you don't need to be top at all of it, though!) but leaves out a lot of important skills.

I'm not sure what "fit to be a developer" means. People (with very few exceptions) are not born with labels that say "able to write software professionally" or "not able to write software professionally". Try to understand what has prevented you from landing jobs so far. Go through http://sijinjoseph.com/programmer-competency-matrix/ to determine what you lack, and then work on improving those. (Not saying that that link is the ultimate criteria for determining one's suitability as a programmer, just that if you really don't know what you're missing, it will give you some ideas)

There are many ways to quantify how good of a programmer you are.

- You can compare yourself to other developers (there are plenty of qualities to compare)

- You can review your statistics (commit frequency, average file size, accuracy of time estimates)

- You can compete in programming competitions

- You can evaluate yourself using the Programmer Competency Matrix: https://sijinjoseph.com/programmer-competency-matrix/

Also, "Good" is subjective. Some programmers are "good" in certain contexts, but "not good" in others.