4 ms·

I would be strongly in favor of some kind of professional license, where every X years you must retake some exam, similar to the P.E. license in other engineeri

I would be strongly in favor of some kind of professional license, where every X years you must retake some exam, similar to the P.E. license in other engineering disciplines. Benefits: - Employer: by scanning for resumes with this license, the employer saves time and money that would instead be spent on technical LeetCode-esque interviews. - Employee: a singular license would make you more attractive and compel a higher salary. You wouldn't have to grind LeetCode for 3 months before a job hunt. In my "utopia", FAANG/S&P 500 companies + universities (MIT/Harvard/Stanford/etc.) would band together to form a third-party committee and standards board that would design and proffer this exam. Having those big names in charge would give it instant credibility and make it the de facto S.W.E. P.E.

ChrisMarshallNY 5y ago
Yes and no. I think it's important, for certain types of coding; maybe not so much, for other types. FAANG companies are willing to put their money where their mouths are. They pay quite well. I think it would be quite reasonable for them to require a standardized certification, and people would bust their butts to pass the cert., for a chance at the money to be made. A lot of startups, on the other hand, have much "earthier" needs. They may want people that are more "generalist," for a lot of their roles, and might be able to use support for eventual training to the tests as a carrot. If they treat their employees well, they could get some certified engineers for a bargain price, out of the deal. Also, there is such a huge variety of coding specialties. Algorithm coders work with data processing, but you also have people that may specialize in ML, and that could require entirely different skillsets (I am not an ML person, so I don't know whether or not standard DP algorithms are ideal for AI work). I have done a lot of communication and device control stuff, and that has some facets that few of your "standard" developers see. Then, you have toolsets and frameworks. These are really what makes a developer rock. Someone who really knows their way around specific toolsets, or deep language knowledge, may be what you need. I can learn a new language, in a couple of weeks, but knowing it well can take years. And there's a better than even chance that knowing it well won't be particularly valuable to a company. Lot of variables. Software is a very, very dynamic place, and it's really difficult to distill meaningful standards from it, that aren't rendered obsolete, almost as soon as the ink dries on the documents.
jlangemeier 5y ago
I'm being a bit 'tongue in cheek' with this... you mean like... ABET or NCEES, which handles the FE, EIT, and PE 'tests'? Also, ABET already accredits Software Engineering and IT programs; and NCEES has had a Software Engineering PE in the works for the last couple years (I haven't checked recently, but iirc it was slated for release in 2022(?)). Toy problems seem to exist in pretty much any technical discipline, but it seems most acute in the software world; and I've come to suspect that it's accessibility to making those. Code is quick and human-centric technical item, where as something like a bridge rectifier, amps, fets, and PID controllers aren't necessarily items you can just 'pull out' in an interview; you can see if someone's comfortable with CAD programs, you can see if someone has the chops to understand when a BJT is more appropriate than a MOSFET; but you can't really do that quickly as a 'whiteboarding session' so other technical fields are required to be more selective since you can't just slap out a FET configuration for a D Class amp without spec sheets, requirement gathering, probably CAD design, and other design steps; but you can sure-as-shit slap out a MVP of a SPA customer portal without any of that. Divorcing "coding" as the act of writing code, and "coding" as the mental process of building a well designed app/system would bring the software world into better alignment with a lot of the rest of the engineering world; and would make something like a SWE PE more viable in the first place. I also don't know if you've ever sat a PE, but they're also __OPEN_BOOK__, since we know that it's a lot of knowledge to have in your head, and it's a better test if you know where to look something up and how to use the right tools (kinda like a 'take-home' exam in software interviews, but not nearly as exploitable and scummy); bring your reference material, but so much ground is covered that if you don't know your stuff, you're failing the PE no matter how many reference books you bring along.

ChrisMarshallNY 5y ago

Yes and no. I think it's important, for certain types of coding; maybe not so much, for other types. FAANG companies are willing to put their money where their mouths are. They pay quite well. I think it would be quite reasonable for them to require a standardized certification, and people would bust their butts to pass the cert., for a chance at the money to be made. A lot of startups, on the other hand, have much "earthier" needs. They may want people that are more "generalist," for a lot of their roles, and might be able to use support for eventual training to the tests as a carrot. If they treat their employees well, they could get some certified engineers for a bargain price, out of the deal. Also, there is such a huge variety of coding specialties. Algorithm coders work with data processing, but you also have people that may specialize in ML, and that could require entirely different skillsets (I am not an ML person, so I don't know whether or not standard DP algorithms are ideal for AI work). I have done a lot of communication and device control stuff, and that has some facets that few of your "standard" developers see. Then, you have toolsets and frameworks. These are really what makes a developer rock. Someone who really knows their way around specific toolsets, or deep language knowledge, may be what you need. I can learn a new language, in a couple of weeks, but knowing it well can take years. And there's a better than even chance that knowing it well won't be particularly valuable to a company. Lot of variables. Software is a very, very dynamic place, and it's really difficult to distill meaningful standards from it, that aren't rendered obsolete, almost as soon as the ink dries on the documents.

jlangemeier 5y ago

I'm being a bit 'tongue in cheek' with this... you mean like... ABET or NCEES, which handles the FE, EIT, and PE 'tests'? Also, ABET already accredits Software Engineering and IT programs; and NCEES has had a Software Engineering PE in the works for the last couple years (I haven't checked recently, but iirc it was slated for release in 2022(?)). Toy problems seem to exist in pretty much any technical discipline, but it seems most acute in the software world; and I've come to suspect that it's accessibility to making those. Code is quick and human-centric technical item, where as something like a bridge rectifier, amps, fets, and PID controllers aren't necessarily items you can just 'pull out' in an interview; you can see if someone's comfortable with CAD programs, you can see if someone has the chops to understand when a BJT is more appropriate than a MOSFET; but you can't really do that quickly as a 'whiteboarding session' so other technical fields are required to be more selective since you can't just slap out a FET configuration for a D Class amp without spec sheets, requirement gathering, probably CAD design, and other design steps; but you can sure-as-shit slap out a MVP of a SPA customer portal without any of that. Divorcing "coding" as the act of writing code, and "coding" as the mental process of building a well designed app/system would bring the software world into better alignment with a lot of the rest of the engineering world; and would make something like a SWE PE more viable in the first place. I also don't know if you've ever sat a PE, but they're also __OPEN_BOOK__, since we know that it's a lot of knowledge to have in your head, and it's a better test if you know where to look something up and how to use the right tools (kinda like a 'take-home' exam in software interviews, but not nearly as exploitable and scummy); bring your reference material, but so much ground is covered that if you don't know your stuff, you're failing the PE no matter how many reference books you bring along.