How to assess the seniority of an Engineer This question is crucial, it’s how you ensure you hire the right profile for your team. While many skills matter, one of the most revealing is how an engineer approaches problem-solving. 👨💻 Juniors often dive straight into the code. 🧠 Seniors, on the other hand, take a step back to understand the problem as a whole : the context, constraints, and the best methodology to solve it. Here’s an example of methodology: I've seen engineers working in environments where every small change required minutes of compilation just to test. A senior engineer thinks differently: "How can I isolate the specific part of the code I'm working on so I can iterate and test faster?" Fast iteration when testing is key. It’s not just about writing code, it’s about designing an efficient process for solving problems. 💡 What about you? How do you assess the seniority of an engineer?
Wow powerful message. I agree, I do not consider just jumping to the code as the right approach. It is definitely important to at least think first about the plan for what one wants to achieve. Before every problem I face, I go through manuals to try and find a specific already made framework and then follow it.
Juniors think how to solve the current problem they have, Seniors think how not to have it in the first place xD
The best code is the one you can avoid to write.
I think researching and exploring how other engineers have solved problems similar to the one you’re tackling now is not just a sign of seniority, but of wisdom.
Very true. I had an I/O path issue to debug and produce a hotfix for. As you might guess, testing a fix in the I/O path of a storage array is not trivial. Thanks to some help from teammates that provided a really cool way to iterate testing, I was able to gather more debugging info and come up with and release a hotfix for the issue. The customer was happy and I learned a lot about that part of our huge system. I honestly never would have solved it without iterating over debug scenarios in my mind and later verifying some of those with pinpointed tests that were enabled by that simulation code my teammates shared. This was great because my small fix enabled the customer to pick up a hotfix quickly while the next available release was still months away. All that code had been refactored already in the new release so I had to study the code, run debugging tests, learn from those results and devise new tests and possible solutions that didn’t break the entire I/O path. It was an awesome experience and every senior engineer has those kinds of stories.
You won't be a senior dev until you don't get a few white hair.
A senior will also take into account: can my team build this? Can I split the design so that multiple people can work on it, with different skill sets. Can it be tested. Can I do this with minimal impact on existing clients. And they should not forget the human aspect either can they keep the team motivated, allow juniors to make mistakes they can learn from... Be a mentor not a dictator
I hate jumping into the code because it’s least efficient way to learn the actual requirements before making a decision. Imagine you need to update how magic sign in link works but the code is spread across 3 different services, 6 classes, 20 methods, and 300 lines of code. How can we learn exactly how thing is working before looking into the code? Think about it for a minute, then open my second comment.
Senior don’t use ROS 😂
Robotics Engineer and consultant
2wIt's hard to asses, but for me seniority is 90% about ownership