Closed Wintermute21 closed 5 years ago
Hey @Wintermute21! Thanks for writing in, and sorry it’s taken me a bit to get back to you.
It’s great that you want to genuinely see where you are; I think this sort of continuous self-reflection is critical to improving as anyone in a technical role.
I was thinking about this a bit and I think I can sum it up in a patented*
AAAA ™️ approach:
In this step, you gather all of the content you think could be relevant to the skillset you’re examining. Look up popular books, videos, training courses, blogs, etc. that are relevant to the skills you’re wondering about. This may mean searching by keywords, following folks on twitter, etc. — or asking around. (Feel free to follow up with me if you want any recommendations in certain subjects, by the way). If you can approach this content and it feels relatively comfortable, you’re probably in a reasonably good place. And for the content you’re not familiar with, you can move on to the next step...
Scan through the contents, blog topics, etc. from above, and find something you aren’t familiar with. Dig in.
How was the experience? Do you feel you can grasp it, or did you go down a rabbit hole of concepts you’re unfamiliar with? Either is fine — and in fact that’s one of my favorite things to do sometimes. But, if you’re looking to gauge where you are and this is happening for things that seem to be more fundamental, it may help you understand your current level of understanding.
Once you’ve started to gauge where you are, you may want to take a more formal assessment. This could take the form of a certification (for example I recommend a CSD for fundamental OOP development concepts such as SOLID, TDD, etc.). It could also take the form of a subscription to Pluralsight, which I love and which has both overall assessments for certain groups of skills and assessments after many of its courses when using the appropriate subscription.
Assessments are a great way to see what you know and how you might stack up to others in the industry. I wouldn’t worry about them too much as an end goal, but preparing for them can give you great insight into where your journey might go.
This is my favorite way to attempt to understand a skillset — jump in and build something! Chances are, not only will you understand where you are but you won’t be able to help learning some good stuff along the way. If I want to understand build pipelines, I create one. If I want to check how a thing works, I build a thing that works (...eventually). If I want to test whether I can explain a concept, I write about it or present on it. If I want to see if I understand a library or tool well enough, I’ll see if I can contribute a pull request to it.
It’s important to not get discouraged if the thing you create is ugly or barely functional. It will help you understand where the hurdles are, which is a great way to start exercising to get over them.
You will be a senior at some things, and a junior at others — I sure am, at least. If you can continually level up your skills and you care about doing things well and about the people you work with, you’ll go far.
—-
I hope this has been useful! Feel free to follow up with any additional questions you have.
*
totally not patented
When I started my career, I hopped around mostly doing contract work, but never really got to stick around in one place long enough to really mature, so, how can I know if I'm truly a mid-level Full Stack dev for example, or if I'm still a junior despite my experience on paper? How should one begin to overcome this? Thanks in advance.