--- An essay on seniority and tech recruitment --- As I am now starting to get into the corporate life, I've been more keen to observe how developing relationships with people, specially those who have more company time, can help someone grow professionally. An example of such shows itself when you're maintaining huge systems developed internally, which, for me in particular, is what I spend most of my working hours on. To have someone you can rely on when the internet/documentation aren't quite enough is very reassuring, and it seems that, no matter how much I learn while in an industry context or by looking with an outsider's perspective, that knowledge seems negligible (when solving my problems) when compared to what I learn from my more experienced peers and when while I accumulate experience while solving internal issues. What I mean by that is, in my head, is easy to split the technical knowledge (and I'm only talking about actual hard skills here) into two very different categories. The first being things that can be learned from the outside: programming languages, libraries/frameworks, design patterns, system/software architecture and the like. These are very valuable skills to have in your tool belt and IMHO they make you a very valuable asset to any corporation. The second, in contrast, is knowing how the business and its cogs operate. Moreover, my goal today is to explore how my mentality shifted regarding the importance of the latter and how it can be explored to improve the tech market. <Intermission> Before getting into that. I would like to rant about LinkedIn/Instagram for a brief moment. That was my motivation for writing this post BTW. If that's not relevant to you, just `ctrl + f + </` out of the intermission tag, or something. Social media memes about work: 90% are just garbage. Bump that up like +5% when adding AI slop to the mix. They are not funny, people who find them funny should probably broaden their entertainment routine to doom scrolling, brain rot or something. I'm sure the dopamine you get from those will be more enjoyable than spending more than an hour scrolling through your LinkedIn feed nowadays. But, somehow, the Brazilian developer meme community can be even duller. Senior v.s Junior dev, complaining about PMs POs Jira, front-end not being programming and hating on Java/php. These same jokes, just like a broken record... That's all they talk about. When relevant things actually do happen, like the recent Firefox AI browser thing (https://infosec.press/brunomiguel/is-mozilla-trying-hard-to-kill-itself), that part of the internet just doesn't seem to care... At all. I truly believe in this community's potential, but people just limit themselves to what's required from them by the corporations they work at, the famous "fazedor de CRUD" is all they strive for. And a symptom of that is not being able to poke fun at any of the recent mishaps, because those actually require minimal technical knowledge on the matter. Comedy is a weapon for critique, after all... I'm not saying that good developers are lacking in my home country, I'm trying to convey that with the increasing interest shown by the locals, people should be more aware of the tech world that surrounds them. Building a community that gets past superficial knowledge (i.e A Brazilian version of https://news.ycombinator.com) would be way more delightful to engage in, wouldn't it? But I digress. </Intermission> Getting back on topic. I'd like to unpack the concept of seniority and as to why I don't fully agree with what people usually esteem from the term. Recall the two categories we discussed earlier, let's give them names to make them easier to reference: I'll call them _external_ and _internal_ knowledge from now on. Usually, when people think of senior programmers, they are thinking about external knowledge, with it's meaning's depth varying across different contexts. The title of "Senior Software Engineer", for instance, does not take into account what the individual is actually proficient in, and what people do to fix that is putting a language/field as a prefix: "Senior Java Developer", "Sr. SRE". Again, I'm not disregarding the effort people put into learning about the topic that interests them, 10h C++ crash courses on free code academy, 100h+ on LeetCode exercises... I'm not saying those hold no value. However, I think these pale in comparison, in an employee's value to the company standpoint, to the internal knowledge mentioned. Imagine you just got into a new company as a Sr. dev, completely different from the line of work from your previous job, but the tech stack is the same, at least. I assure you that the cognitive effort of actually understanding this different line of business will be much expressive then thinking about the nooks and crannies of this new software you are creating. You will come up with a bunch of sophisticated ideas on how you can implement an event oriented microsservice, blazzing fast Rust application, but 90% your time will be spent talking to people on the business logic that should be implemented. Over engineering can be the cause for loss in efficiency, time, cash and your career at the company. "Oh, so it's impossible to be a senior in a company without spending 10+ years in it then? Are you saying knowledge is not transferable between jobs?". Yes and No, hear me out. I've said it before and I'll say it again: Learning is always good, there is not downside to it. But unfortunately, the economy today does not require specialists, what makes money flow is getting work done. Saying this does frustrate me - Thinking about the solution is way more fun than actually solving the problem - but, according to my short but valuable experience up until now, that is how I interpret the current scenario. Companies don't care about how many programming languages you know, they don't care about how deeply you know about Haskell and their monads, they just want you to do this 100 line python script that processes data in a specific way and sends it to another service, this is what makes the cogs their system turn and what pays your hardly earned salary at the end of the day. So you **should** learn your tools, but invest more time into learning about their processes and how make them more efficient, specially in an automation standpoint. And now, we dive head first onto the second topic at hand. Tech recruitment nowadays has a lot to improve. Big companies are delegating talent scouting to HR, and that's making the workforce quality decrease exponentially. Team leaders/people in the actual projects should be the ones prospecting new talent; HR's daily work is typically disconnected to ongoing projects affairs, they lack awareness on the internal knowledge discussed, so it's very unlikely that they can make good decisions on that front. The project's leadership and those who get their hands dirty, on the other hand, know their system, they know which puzzle pieces are missing, so they should be ones making these kinds of decisions. I do not agree that personality tests, gamified hiring processes or horoscope matching will do any good to weed out the bad apples, nor do I endorse focusing the entirety of the process into knowing if the candidate can implement tree inversion blindfolded, or if they know the difference between FIFO and a multilevel feedback queue, that's not what makes a senior in my sense of the word. What should be prioritized is knowing whether the candidate is apt to perform their upcoming tasks, that being, if they have what it takes to handle what's to come. And their ability and interest to learn what makes the clock tick inside the office's doors is a pretty good indicator for that, IMO. For small companies, adding one more duty to the technical lead seems doable. For big ones, though, things get a bit more challenging due to the sheer volume of people trying to get in. Knowing that and dedicating the scarce workforce into looking at hundreds of thousands of applications would be counterproductive and a bad decision altogether. So how should they hire? My answer to that is a kind of a hot take, but I think people who are looking to work at a company are the ones who should sell themselves better. Technical people can sniff out bullshit and they know who's the real deal. So making yourself be heard by showing off cools personal projects, that actually prove your ability and dedication to make things happen, writing interesting blogs posts, studying about their prospected companies tech stacks, participating on tech events and career fairs, etc. should be what these people should start investing their time in. Naturally and eventually, interested people in the field are bound to notice and reach out. That way, I think team building will be easier and the quality of work will have a much larger chance to improve. I look forward to see what the future of the tech market holds. So I shall conclude this post, and this year, in a more light hearted manner: here some of my predictions as to what's to come. Don't hold me accountable to any consequences if you take my words to heart (you probably shouldn't) and let me hear what you think if you are interested in reaching out... = Vibecoding will dominate for a while. Companies, in search of efficiency, will keep investing in AI, making their software quality worsen. (Really?...) = Software security will eventually boom into one of the most highly paid jobs in the industry. = Rust will become more popular, due to it's more sophisticated guardrails. = The year of Linux be upon us in the next 2-3 years. Happy holidays and I hope to see you in the next one.