This may sound like an obvious question, but is it really that simple?
I've heard some developers in the company discuss this issue. A senior engineer of mine was discussing something else with two junior engineers. When the matter was discussed, one of the junior engineers raised the issue, and the junior engineer was still a senior engineer.
That senior engineer happened to be one of the best and smartest engineers I had the pleasure of working together. From his perspective, he spent 30 minutes trying to explain the difference.
The conversation was mixed with the usual answers. The junior engineer who asked the question (a little smart guy in the company) tried to split the question into two sub-questions. It seemed to me more interesting, exploratory and useful Sub-question:
1. Objectively speaking, how can I as a junior engineer determine when I become a "senior engineer"?
2. As a senior engineer, how do you measure the progress of a junior engineer, and how do you know when a junior engineer has crossed the threshold of becoming a senior engineer?
I think the first question is particularly interesting. As the office discussions continued, I tried my best to think about what problems I have been thinking over the years from the beginning of software development to growing up as a developer.
There is no doubt that for each developer, time is an important factor in growing to a higher rank. Looking at the various recruitment information over the years (some people think "advanced" means at least 5-7 years of experience, while others think it means at least 10-15 years), it is clear how long it takes for professional time True "standard".
After only a few years, some developers consider themselves to be senior engineers, while others have considered themselves to be just "intermediate" after 7-10 years. As a recruiter, I know the above facts are true. These are undoubtedly clear common sense. Conceit is also an interesting thing. There will be different opinions on "how long", and this "impedance mismatch" will cause disputes.
Does it have anything to do with the technology or language type learned? There is an academic view that mastering one or two languages can also become a senior engineer, as long as he has the experience of how to deal with problems encountered in the use of programming languages Just fine. However, another profession is more focused on the ability to work with different similar technologies and to solve more common problems with different technologies.
This is obvious, it depends on what you want to do. From that perspective, it is useless to discuss internally whether you have entered the "senior engineer" field.
After much deliberation and a long discussion, I concluded that the internal judgments on the first question are quite diverse. If you let me come up with a standard—whether informal or not—that would be: As a junior engineer, when a company or team of senior technicians asks you to do something, the comfort you have and Self-confidence level.
There is no doubt that there is an infinite number of answers to this question. Frankly speaking, I have not seen any solution that can be used as a silver bullet or gold ruler to measure all senior engineers.
Yes, there are many quizzes and exams to evaluate a developer's ability level. No doubt these tests cannot be ignored.
To make things even more interesting, sometimes those who judge what a "senior engineer" is are not familiar with those technologies or languages. For example, in a small company, the expert in the technical department may be a Java developer with considerable experience in deploying Java-based business programs. However, the same experts may be responsible for hiring senior iOS developers. In the absence of a senior iOS development engineer, some people have to step up and become experts.
Stop, I'm off topic. The real issue here is evaluating the progress of the junior engineer.
There are some possible standards, and most of them seem not easy (but not impossible) to properly communicate to the junior engineer himself. Once again, if asked to provide a possible standard, I think it is such a standard that developers can give an estimated workload for a task or a series of tasks (no matter how huge), and can be confident in a reasonable time frame (Don't let me give a task estimate) to complete it with minimal assistance.
In other words, if you have been making the same mistake, which is a mistake you encountered when you first started developing, then it is certain that you have not entered the field of senior engineers.
This article is not intended to answer the question of my savvy junior engineer. Instead, it leads to a discussion about what standards can be reasonably applied to each issue, and it is a starting point if you feel good.
What do you think? What standards are applicable on both sides? We don't have a mature human resources department, but there may be something we can learn to know.