Apex Code Development You need to sign in to do that
Don't have an account?
Determine knowledge level of salesforce specialist
Hello,
As a rule software developers have three levels of knowledge: Junior, Middle, Senior
Is there any official methodology (provided by salesforce) to determine knowledge level of salesforce developer?
Guys, can you share some documents, best practices, methodologies that are used in your companies to determine knowledge level of salesforce specialist (admin or developer)
Thanks you!!
As a rule software developers have three levels of knowledge: Junior, Middle, Senior
Is there any official methodology (provided by salesforce) to determine knowledge level of salesforce developer?
Guys, can you share some documents, best practices, methodologies that are used in your companies to determine knowledge level of salesforce specialist (admin or developer)
Thanks you!!
I'm going to take the fundamental stance that classifying people --Regardless of what your classifying them as-- is fundamentally a dangerous proposal.
Things like Jr. Dev, Dev, and Sr. Dev are arbitrary classifications. The fundamental problem with arbitrary classifications is that You, Appirio and Accenture are certian to have different boundaries for each. Thus, it's probably that a Sr. Dev at, say Appirio may only classify as a Dev, or even Jr. Dev at Ye Olde Salesforce Shop.
Regardless of the Technology (Salesforce / Ruby & Rails / Node etc.) I find that people generally self-categorize themselves into one of three categories:
1. Auto-didacts: These people may not know shit about shit, but they're hungry to learn, take feedback (when given well) and internalize it, and seek to write code that is elegant and beautiful.
2. Old-timers: These people aren't necessarially older, or wiser but they are *stuck in their ways*. A problem has *their* solution, and their solution is battle tested and it's the only one they *see*.
3. Googler's: These aren't google employees, but rather the people who turn to google not for technical documentation, but for solutions part and parcel. They believe that Google has all the ansers, and they need not *think* through the problem domain, so long as they can find a solution that mostly fits then hack away at it till it works.
I'm of the firm opinion, that it takes all 3 to have a healthy development ecosystem. That said, I'd prefer to hire #1's.
Each of these three types has three stages:
Novice: Just learning the technology, not enough experience to be an old-timer, likely still consuming massive bandwidth from *.stackexchange.com, but learning, even if only because their forced too.
JourneyPerson: They believe that they've a firm grasp of the technology and are likely the first to suggest solutions. These solutions may very well work, and be wonderful, but they may not be the best thought-out, scallable or "idiomatic" for the platform. Regardless, they're throwing out ideas, rather than googling first.
Master: These people are almost always auto-diadacts, who have *taken it upon themselves to mentor novices and journeypersons* They are characterized by listening first, and suggesting only coherent, well thought out solutions. They're likely not the first to throw out a solution, but when they do speak up with a suggestion, it's likely a more fully developed plan than others on the table. They have learned the secret that part of crafting beautiful code, is shaping fellow coders.
All Answers
I cannot speak to any official documentation but I can tell you what we look for at my company to determine our levels, and I'll associate them with the terminology you used:
-
Junior: Just starting out on the platform and has very little knowledge. Day to day requires some help of more senior developers to complete tasks. Typically needs help or guidance in tasking assignments that are given to them.
-
Middle: Knows the platform well and has medium to high knowledge. Day to day requires almost no help from senior developers and is very comfortable in tasking out assignments and working them with little to know intervention.
-
Senior: Knows the platform well and has high knowledge (this could be a broad knowlege of the entire platform or a deep knowledge of parts of the platform). Day to day requires no help from others and is assisting junior developers with the job. Senior developers are expected to help drive the product forward both by helping management make decisions about the goals of the team and by laying out the general assignments for the team.
I would say that this type of structure is handled similarly regardless of the platform that is being worked on. The only difference being what the knowledge is on.How many years are required to become a middle? Senior?
Again, we do not have any year requirement because it is not a hard and fast "you must be a junior dev for 3yrs to become middle" but it is more based on goals set forth by the manager and the individuals ability to work without supervision / oversite from the other team members.
But, we, in our company are going to establish a process that will allow to determine developer level using some questionnaire or checklist. The main point is that process should not depend on person, who will examine candidate.
We want to prevent impact of human factor and somehow standartize and streamline assessment of employees
Is it a big secret what? Guys come on... :)
It's hard to quantify a distinction between Junior, Middle, Senior devs because it's very subjective and opinion based. You're right, the big consulting forms likely have their own criteria for determining the difference between each, but they're not going to be the same, nor are they going to share them on a public forum.
That being said, here's my opinion on the matter:
Junior: Has a computer science or engineering related background. The junior developer can answer simple questions around inheritance, polymorphism, loops, databases, unit tests, has a fundamental knowledge around design patterns and MVC. They likely have zero to little experience with Salesforce, however, they are good problem solvers and can research answers to any questions or problems that come up. Junior developers will likely need some guidance, but can take a set of instructions or documentation and run with it, without slowing down the rest of the team.
Middle: In addition to the skills above, has a fundamental knowledge of Salesforce. They know when to use declaritive functionality and when to use Apex or Visualforce. They know how to write thorough unit tests and best practices around bulkifying triggers. A good test for a "middle" developer is whether or not they can pass both the Developer and Administrator exams.
Senior: Comprehensively knows software, object oriented principles, frameworks, and how they can all be applied to Salesforce. Has an indepth knowledge around Salesforce, Apex, Visualforce, and one or more of Sales Cloud, Service Cloud, Heroku, Communities, Sites, etc. If they don't know something around a facet of Salesforce, they can figure it out quickly. The senior developer has an intricate knowledge of Salesforce and Apex such as the order of execution across validation rules, workflow rules, trigger execution. They know when Ids are available in triggers, etc. They could easily pass the Advanced developer ceritification. A senior developer can take a project and design it themselves and run with it, or if they are in a more supportive role, they are not afraid to provide feedback on improving projects. A senior level developer is close in skillsets to a Technical Architect.
In conclusion, the above points are my opinion, and are likely to differ with others' here on the forum. However, you need to sit down in your own organization and formulate your own criteria, perhaps using the above as a baseline.
I'm going to take the fundamental stance that classifying people --Regardless of what your classifying them as-- is fundamentally a dangerous proposal.
Things like Jr. Dev, Dev, and Sr. Dev are arbitrary classifications. The fundamental problem with arbitrary classifications is that You, Appirio and Accenture are certian to have different boundaries for each. Thus, it's probably that a Sr. Dev at, say Appirio may only classify as a Dev, or even Jr. Dev at Ye Olde Salesforce Shop.
Regardless of the Technology (Salesforce / Ruby & Rails / Node etc.) I find that people generally self-categorize themselves into one of three categories:
1. Auto-didacts: These people may not know shit about shit, but they're hungry to learn, take feedback (when given well) and internalize it, and seek to write code that is elegant and beautiful.
2. Old-timers: These people aren't necessarially older, or wiser but they are *stuck in their ways*. A problem has *their* solution, and their solution is battle tested and it's the only one they *see*.
3. Googler's: These aren't google employees, but rather the people who turn to google not for technical documentation, but for solutions part and parcel. They believe that Google has all the ansers, and they need not *think* through the problem domain, so long as they can find a solution that mostly fits then hack away at it till it works.
I'm of the firm opinion, that it takes all 3 to have a healthy development ecosystem. That said, I'd prefer to hire #1's.
Each of these three types has three stages:
Novice: Just learning the technology, not enough experience to be an old-timer, likely still consuming massive bandwidth from *.stackexchange.com, but learning, even if only because their forced too.
JourneyPerson: They believe that they've a firm grasp of the technology and are likely the first to suggest solutions. These solutions may very well work, and be wonderful, but they may not be the best thought-out, scallable or "idiomatic" for the platform. Regardless, they're throwing out ideas, rather than googling first.
Master: These people are almost always auto-diadacts, who have *taken it upon themselves to mentor novices and journeypersons* They are characterized by listening first, and suggesting only coherent, well thought out solutions. They're likely not the first to throw out a solution, but when they do speak up with a suggestion, it's likely a more fully developed plan than others on the table. They have learned the secret that part of crafting beautiful code, is shaping fellow coders.
Probably I will share what we will create.
Somebody who wants to learn the final description of the process - please comment or like.