In general, we find it much easier to spot strengths and weaknesses in others than we do in ourselves. We might have developed some poor habits over many years, and if so, they may have become so ingrained that we cannot notice them as weaknesses.
Everyone is inclined to interpret situations in biased ways, often based on their cultural norms and beliefs. But there is another kind of bias, called cognitive bias, that all humans share.
A study by David Dunning and Justin Kruger of Cornell University uncovered two natural biases in human behavior: first, that people with below average skill levels tend to overestimate these skills; and second, that people with above average skill levels tend to underestimate them. We often make the mistake of thinking that other people act like us and think like us. We tend to think what is easy for us must be easy for others, and what is difficult for us must also be difficult for others.
Today, the “Dunning-Kruger Effect” is commonly used to mean “overestimating knowledge and skills.” Further information on the Dunning-Kruger Effect is available on RationalWiki.
The tendency to underestimate knowledge and skills is more commonly called “impostor syndrome”. It is actually more serious rather just an underestimation. People who suffer from it are convinced that they are frauds and do not deserve the success they have achieved.
To learn more, I recommend David Walsh’s I'm an impostor.
This question is sometimes asked at interviews, but different candidates will interpret the question differently. For example, a rating of 10 might mean “very good” to some candidates but “absolute perfection” to others. If an interviewer asks you for this, it may be helpful to clarify the numbers by agreeing words to represent 1, 5, and 10.
Another problem is some candidates will be naturally more modest than others, but impostor syndrome will reduce the best developers’ ratings (while the Dunning-Kruger Effect will boost the worst candidates’ scores). If you state a number, back it up with information about some of the best work you have done and have learned about.
Experience doesn't guarantee anything. Recently I learned of a developer with eight years’ experience in C# who had no idea what an interface was. This is not all that uncommon.
It's also entirely possible to gain significant expertise in a language in under a year. I recently worked with someone who was able to go from zero experience in C# to being good enough to pass code reviews in one day.
It's not the duration of the experience but the quality of the experience that matters.
Never allow yourself to think of years of experience as a limiting factor, either for you or your colleagues.
For your next job application, don’t sell yourself short just because you don’t have a certain amount of experience; your interest and willingness to learn can more than make up for it.
For example, even if a job specification says three years’ experience in a programming language is required, this is just a shorthand to deter the weaker programmers from applying. If you are able to demonstrate a detailed understanding of the language at the interview, that will be valued more highly than your years of experience.
Because of the many biases that we have, it is difficult to accurately assess our skills because we tend to do so in a subjective rather than objective manner.
Subjective: characteristic of or belonging to reality as perceived rather than as independent of mind; phenomenal; arising out of or identified by means of one’s awareness.
Objective: existing independent of mind; belonging to the sensible world and being observable or verifiable especially by scientific methods; expressing or involving the use of facts.
Objective viewpoints are based on facts. The more facts we can gather, the more we can be satisfied that we are measuring ourselves objectively.
Test scores are a good way to achieve this. I do a lot of assessments on Pluralsight. Most other online training companies also offer assessments to gauge your progress.
Even after doing assessments for almost three years, I am often still surprised by the scores I end up with. Sometimes I find a course easy but struggle on the assessment, and sometimes I find a course very hard and then score 100%. The test results bring my subjective opinions back into alignment with the facts.
Finding something hard might be an indication that you are learning a lot, and finding something too easy might mean that you're not paying enough attention.
Coding competitions are a great way to objectively measure your technical skills against other programmers.
HackerRank allows you to see how your solutions measure up against others. The scoring system is very explicit and performed by a computer algorithm, which means you have a much clearer idea of what the trade-offs are than you would in a real software project.
In a real software project, you typically make judgement calls, such as on whether the application performance is important enough to sacrifice some readability, or whether the schedule is so important that it justifies any technical debt. Real world judgement calls are an important part of the profession, however these challenges let you focus entirely on improving your computer science skills.
Feedback from others will be subjective, but it tends to be less so than your own opinions.
Honest feedback from others can boost your confidence by finding strengths, and also help find your weaknesses. Seeking feedback from someone who you consider to be better than you will produce better results, because they have likely already been in your shoes. They’ve undergone the process of improving themselves and understand where you need to go next.
It is important not to get defensive when on the receiving end of critical feedback. The other person is generally in a better position to evaluate yourself than you are.
That is not to say they will always be entirely correct; to some extent the feedback you receive will be biased, but there is at least as much chance it is positively biased rather than negatively biased. Generally, people who are giving feedback are careful not to cause offense.
At the very least, give any feedback you receive due consideration and thank the other person even if you disagree.
How you go about evaluating your skills will depend on whether you are looking to quickly plug some gaps in your skillset (for example, if you are about to start looking for a new job) or you are interested in improving your skills over the longer term.
If you are interested in making quick progress over the short term, then you probably already have a basic idea of one or two areas you would like to improve. You should only evaluate yourself in a few selected areas that you believe may be holding you back.
If the results of your evaluation lead you to conclude that you need to make rapid short-term progress, you will typically see this most from practicing something you have little or no previous experience in. You need to be disciplined and focus on only one skill at a time.
Sometimes just a few hours of study and practice can make all the difference. Last year in a job interview with Quartix, I learned they used Entity Framework, which I had no experience of. Quartix then asked me to do an assignment that included Entity Framework, and discuss the outcome at a second interview. Less than 24 hours before the interview, I still hadn’t used it, but watching a Getting Started with Entity Framework course and promising to keep studying and learning was enough to get the job.
If you are looking at the medium to long term, then you will want to evaluate a wider skillset so you gain a more complete understanding of your strengths and weaknesses.
Boosting weak areas might be less important for you than boosting areas where you are already strong. After you have completed your evaluation, you might decide that you want to specialize in your stronger skills.
There are hundreds of skills associated with programmers. You don’t need to assess yourself against all of them, or even many of them.
Sijin Joseph has created a popular matrix for programmer competency available here.
Joseph’s matrix is quite a comprehensive list of skills and contains clear definitions of each level. It is language agnostic, so you can complete it regardless of which languages you know.
However, job specifications tend to list specific languages and frameworks. If you want to evaluate yourself at this more specific level, then Joseph’s approach is probably not for you.
There is no one right way to select the list of skills you should evaluate yourself with. However, you can always add more skills to the list at a later date, so I recommend initially choosing only a few areas to evaluate.
In determining your strengths and weaknesses, consider not just your knowledge about them, but your ability to use them.
Accuracy and precision are often used interchangeably. Although they are related concepts, they are not the same, and the difference is important when estimating.
Accuracy is how close to the mark a measurement is. It is strongly associated with correctness.
Precision is how many significant digits a measurement has.
When we give an estimate, they actually work against each other: a measurement can be precise without being accurate, and it can be accurate without being precise.
The more precise a figure we give, the less likely it is to be accurate.
As such, it is usually more important to be accurate than precise.
For example, if you were to estimate your IQ and you give a precise estimate of 110, you'd be much less likely to be accurate than if you said 100-120. Either estimate means a bit better than average intelligence, but the less precise estimate is much more likely to match your score if you were to take an IQ test.
I have found that giving yourself a crude estimation ranging from Basic, Competent, Strong, and Expert for each skill area is enough to understand where you feel your strengths and weaknesses are.
However, it's not necessarily the weak areas that you should focus on. For instance, I am weak at many languages and have no knowledge at all about most of them. Nevertheless, I have no need for them in my current job, so I am happy for that to remain the case while I focus on improving existing strengths.
I recently interviewed several successful developers, and this taught me that there is no magic recipe for success as a developer. Having weaknesses in some areas is a desirable outcome if that means we have more time to focus on the areas that are of most benefit to our careers.
As an example, the majority of developers would consider the difference between a class and an interface as basic knowledge, while a good understanding In Memory Online Transaction Processing (OLTP) architecture is a lot more advanced.
However, if you are an SQL Server consultant, then whether or not you know the former likely won’t matter (SQL Server doesn’t use classes or interfaces), but significant knowledge of In Memory OLTP might give you a significant competitive advantage over other consultants in your area.
I hope I have encouraged you to do your own skillset evaluation. Regardless of your experience, it is normal for the evaluation to find many things left for you to learn and practice.
It does not matter whether you have been programming for 50 minutes or 50 years—we all have our strengths and weaknesses, and understanding them well helps us better understand ourselves and how we can work more effectively with others.
It may just be because you have more experience in those areas, or it could be that those are the areas that interest you the most. If you find that you enjoy what you're best at, then as long as there are jobs available for those skills, that is great news for you!
Above all, it is important not to be disheartened by the discovery that there is much more to learn. Understanding what you don’t yet know puts you ahead of many others who suffer from the Dunning-Kruger Effect. You are now in a position to define your goals and proceed toward achieving them.
If you have any good techniques for evaluating your skills, please share them by leaving a comment below.