Concrete skills are something I feel as though I have an abundance, and simultaneously, a lack of. I guess this depends on what kind of skills are being referenced. If data structures, algorithms, or Leetcode is in question, I have confidence. I enjoy these topics and have solid knowledge in these areas. When it comes to automating tasks, or something more applicable to my current capstone situation, such as getting a strong grip on Docker, I feel… less qualified.
The learning pattern on concrete skills puts on some much-needed pressure. I can have all the knowledge of theory and ability to learn quickly in the world, but if I can’t put real technical skills on a resume, I’ll never make it past any hiring interviews. I should highlight my weaknesses and mark them down as learning opportunities instead of finding ways around them.
There has been a plethora of times at which I confront a problem I have been avoiding and the knowledge I gain seems to apply everywhere. Last semester I learned the state design pattern, and because it came with some confusion, I dropped it quickly enough. Now, as I tried to make a Markov chain simulation for my Math Modeling independent study, I realized a state pattern was perfect. It took some time, but I got it down and it feels great not only to have learned and used something new, but to know I have the knowledge to use whenever I need it going forward.
I think my first focus should be some more surface level skills. As the chapter points out, the question, “If we hire you today, what can you do on Monday morning that will benefit us?” is one of the most important questions of the interview. If my best answer is, “Try really hard to get up to speed,” I’ll be job hunting for a long, long time. My new goal is to collect the skills I don’t know or feel uncomfortable with that are more common and focus my spare time on them. It will make daily life as a developer easier and take me further in my career faster.