Criteria when hiring salesforce devs
Posted by glitchrrr@reddit | ExperiencedDevs | View on Reddit | 7 comments
I am noticing more and more of a friction point at the startup I work at in getting in competent salesforce devs in, working cross functionally we are starting to see blockers emerge because SF build takes much longer than rest of the build on backend/front teams. There are several other factors for this, but one is definitely the calibre of person we are able to hire for this role.
Whilst I don’t control the hiring decision for these devs, I am keen to understand any key pointers you guys look for when hiring for this role, I have seen people come and go on the team who have it on paper but then lack basic data modelling skills and ability to build on SF outside of just simple flows/basic apex. It does feel like senior sf dev is an inflated title, possibly from years of title inflation shenanigans from consulting and things of the sort.
Context: Moving away from SF now is not possible and it is a critical system for the business. Our SF setup is huge and complex , writing custom apex etc etc. Deep integrations between sf and backend systems (think external services for example)
Any key pointers you guys have that you look for and that have worked out on the other end when interviewing and finding someone would be key!
Thanks!
Zestyclose_Humor3362@reddit
This hits so close to home. We see this exact pattern at HireAligned when companies hire for platform-specific roles vs fundamental problem solving ability. The Salesforce ecosystem creates these weird incentives where people can get decent paying jobs without really understanding software development principles, and then they get stuck in that bubble.
Your approach of hiring generalists makes total sense, especially since you're planning to migrate away from Salesforce anyway. The real issue is that many "Salesforce developers" never learned to think like engineers - they learned to click through setup menus and copy/paste apex code. A solid full stack dev will not only pick up Salesforce faster than you'd expect, but they'll also build more maintainable solutions because they actually understand concepts like separation of concerns, testing, and proper architecture.
somedonkus69@reddit
I'll give you my 2 cents. For context, I'd say I'm a generalist full stack developer, but I got pulled into Salesforce development several years ago since I work in consulting and we have a huge client who needed Salesforce help. Since then I became a tech lead and later solution architect for our Salesforce projects, and as the team grew, we've gone through several devs. I have no involvement in the hiring process at all, but here's what I've personally seen - Salesforce devs just don't cut the mustard. They don't know the software development fundamentals and they don't care to learn either, they just want to do basic Salesforce things. It feels like a lost cause sometimes and we had to fire people because they just weren't good. The best Salesforce devs we've had have been other full stack devs who learned Salesforce on the fly. Maybe I'm too picky, but that's my experience.
So my recommendation is to hire a generalist, (senior) full stack developer and give them some time to learn Salesforce. Salesforce really isn't that complicated and a true senior dev, who has experience with many tech stacks, should be able to figure things out. Since you're moving away from Salesforce eventually, then you won't have to fire this person since they'll be able to pivot to the new system too.
Alternatively, you might consider getting a consultant from a reputable place since you will be moving off Salesforce eventually. Might be cheaper in the end. I didn't mean to make this comment a sales thing when I started it, but I feel like I should just say, feel free to DM me if you are interested in this, and I can reach out to someone at my company to talk about helping with your project.
wacoder@reddit
Good SF decs understand that SF’s most powerful feature is also its most dangerous weapon: customizing the data model. Good ones understand the depth, complexity, and interoperability of off the shelf SF and are thoughtful and cautious about updating the shipped model. Bad ones slap custom fields anywhere and abuse models by overloading and cross-linking them to solve whatever problem is in front of them without consideration for the spaghetti that will strangle your business in a few years. Goes quadruply for HealthCloud data model. They better understand how FHIR maps to the SF model and work with product to align business processes to follow the core HC/FHIR processes and customize thoughtfully.
YerManOnTheMac@reddit
Generally, I place less value on time in consultancies. Many 'senior' SF devs have spent 3 -6 months on multiple projects. They tend to have a very limited knowledge. They can do one thing well, say integrations, and have done that repeatedly for multiple short projects.
A great deal of SF devs have little or no experience with git, mocking and stubbing, and many skills that are considered foundational in other stacks.
I look for experience in a non consultancy role, ideally in an ISV. I always include questions about version control, testing strategies, deployment strategies in interviews.
I have to sift through a lot in order to unearth actual engineers, but they do exist. It is just difficult to find them in an industry overpopulated with accidental devs who are often glorified admins.
db_peligro@reddit
I know the SAP world, not SF but I imagine its the same. People specialize in SAP ABAP because they want steady unchallenging work. Its not software development, its configuration management and scripting.
The fact that you are trying to build things on top of SF that these SF developers can't grok tells me you are asking for trouble.
glitchrrr@reddit (OP)
Thanks, I think the business is slowly coming to terms with this, the problem is entire critical path business processes run on SF and the scale we are hitting and piling on more , think a move away is on a 3-5 year horizon so we need something for this period.
MoveInteresting4334@reddit
Even if you find a temporary solution, best to start heading for that 3-5 year horizon now or it’ll always be 3-5 years away.