As to "you don't have to do it again every time you switch jobs", nurses are often required to go through continuing education just to keep their licenses current. But making the jump from one type of nursing specialization to another, or even upgrading from an RN to a BSN (often required today if you want to keep your job - probably the exact same job that you've already been doing for ages) can be quite grueling - almost like starting over. In one recent case, a well-respected fellow nurse upgraded her education only to be to told that even that was no longer considered sufficient. She was already doing management-level work but didn't yet have the official title or the pay, and was told that she needed to go up an additional level in education in order to get that, so she just bailed - decades of experience walked out the door for no good reason.
I continue to be shocked that software developers aren't licensed at least like RNs or CPAs are.
I think it is generally accepted that licenses don't signify "quality".
What are you hoping to gain with a license? Some badge that somebody can show to a prospective employer, so that they don't quiz you on capabilities?
I think we can agree that the field and knowledge required to perform as an RN doesn't change that often and the same goes for CPAs. However, the world of software is changing constantly. How could a licensing process ever stay up to date? Sure we could just test CS fundamentals and give people a stamp -- essentially what a degree is supposed to do. But if you're a software developer, like myself, that has interviewed many people and been subjected to many interviews, I know it's not a perfect process, but I've come across people that have exaggerated their abilities on resumés. One of the great things about software is GitHub, Bitbucket, etc. Why? Because it sometimes provides a window into the work of a developer before they make it on-site. I'd be happy if the industry as a whole just accepted this as the resumé and leaving the in-person interview as one that's non-technical, save for maybe something like FizzBuzz.
From my perspective, I think the idea of licensing is just an okay process for other fields. Without an interval of re-testing, how can we ensure that service providers can still deliver? I have friends that work at medical centers with doctors that have been there for decades that seem to have forgotten a thing or two, but refuse to accept the answer to a symptom or problem that is fresh in a new or recent grad's mind that's had fatal consequences. It's sad.
What a great idea! Let's call it a degree
Admittedly, the data is a few years old (and I didn't want to pull the same data from the 2018 survey), but such a requirement would put many people out of a job. I also haven't seen any concrete data that would support any correlation between the efficacy of a software engineer and whether they had obtained a college degree, so this seems like a poor metric.
I share your incredulity regarding the lack of any sort of "occupational license" for the industry, though I remain unconvinced that instituting one would have a positive effect.
[1] : https://stackoverflow.blog/2016/10/07/do-developers-need-col...
As more recent examples, a few years back I took all three of the original free MOOCs from Stanford. In the ML class, Andrew Ng at one point said something like "If you've ever taken calculus then you will recognize this particular equation as being a derivative; otherwise don't worry about it because that's not really important." Later he said something similar about linear algebra and matrix multiplication. And indeed I had taken both calculus and linear algebra back in the day so I recognized what I was looking at, but it just wasn't important within the context of that advanced class.
I also took the Database MOOC, and during that the instructor taught quite a bit of formal database theory. (I forget the proper name for it.) But despite having worked with databases for decades now I've only seen such theory referenced maybe twice, and that just in passing, so it's hardly the "critical, need-to-know" stuff that the instructor insisted that it was.
Meanwhile, in the AI MOOC almost everything taught there was new to me, despite my having taken several AI classes back in the day; so basically zero overlap between then and now. (I did recognize some of the statistical stuff, though, from my statistics class way back when.) But will any of the new stuff ever be of any practical use to me? Probably not. Interesting certainly, but probably not at all practical.
So perhaps, California would have the highest standards with Google/Facebook employees pushing them to do so to create barriers to entry, but Mississippi would end up with the bare minimum.
I wouldn't find it terrible if Software Engineering were licensed, in the same way that law is---with the board consisting of prominent practicing members of the existing population, and all current members grandfathered in so it only affects upcoming generations.
But this is idle wishing: the current system likely has to much inertia for real change at this point.
Just pretend you went to law school and have to make monthly loan repayments each month. Put that money in bank account and you will have more than enough savings to take off work for a month every few years.
Median wage for programmers is nearly double the US median household income and has few barriers to entry. If the only downside is having to take a month off work every few years, I’m not complaining.
Edit to add: In general, I don't think our system has to be worse than all others for it to be worthwhile to consider what might be better.
It's a rigorous exam, but to me, this is so preferable to a 5 hour interview on differential equations, stats, and linear algebra every time you interview. And that's pretty much what we do in software, it's the equivalent of asking a senior actuary to do an integration by parts or a complex derivative at the whiteboard during an interview.
What I also like about this approach is that we'd avoid that situation where a cartel like the law schools can put a 150k, 3 year degree in between talented people and the profession they'd like to enter.
Another thing is that tech exams are very capricious - you can end up with a totally unqualified interviewer, there's really no quality control on the questions or how the exams are administered. A more formal exam could have a lot of benefits, though I do agree that a required long degree program that is $$ would do more harm than good.
EDIT: There's is something that causes me to question some of what I wrote above - I have grown wary of many of the people who want to regulate software as a profession. I'm still stinging a from my collisions with the test-driven development crowd dating back over the last decade. They really were saying that to merely question the value of the methodology should render you un-hireable. Imagine if they got control over formal licensing. I do shudder at the thought. When I think of that possibility, the Wild West approach, unsavory as it may be, seems more appealing.
It is a very different set of trade offs than what we have in CS, where companies are more than willing to take a chance on bright people with non traditional backgrounds, including people that never went to college or dropped out. As a lifelong self-learner, I’ve certainly appreciated the lack of “credentialism” at tech companies.
The one part of the PE thing that I would like to see borrowed is the exams. If all companies are just running everyone through the same kinds of general CS problems anyway, might as well save everyone time and improve consistency by making a standardized test.
A month off? I completed an MSCS (including a thesis) while working full time with two young children at home (my daughter was born in between my first and second year). I can't imagine educational/licensing requirements that would be more difficult than that; you can continue your education without dropping out entirely.
As for government work, I'm not sure where you got that idea from. I did government work for 14 years and never needed any certifications. If I had, the company would have paid for it and it would have been on company time.
Sure, there is some noise; papers get rejected where they should not have been. And other papers that should have been rejected, do get in, etc. However, by the time you're applying for a professorship, you're abilities should clearly shine through that noise.
I'm not intending this as an indictment against academia. They're faced with a hard problem: many more candidates than job openings. They couldn't possibly do whiteboard interviews like in software, just because of sheer logistics. I don't know how academia could do it differently. Software can do it better because there's a LOT more money in software.
Being smart and knowing your areas are only some of the requirements for being a professor. Having just those two is insufficient.
If you look at the batch of assistant professors that start every year at good schools, did they pick the wrong people?
There's no implication that the letters are obtained unfairly, but that doesn't necessarily mean that the resulting outcomes are fair. The point is that if you find yourself in a situation where you can't get hold of these things and yet you are, in fact, really good, there's nothing much you can do about it short of waiting a few more years and hoping to build up a better professional reputation. In contrast, you can just show up at a coding interview, demonstrate that you can in fact code (at whatever level is required), and land a job.
Case in point: I moved from academia to coding by doing this (without any relevant qualifications or having worked professionally as a software engineer). There is no equivalent progression for someone who wants to move to academia from coding.
Prestigious invited talks don't come out of the blue, but usually as a result of consistent work that people care about.
If a researcher can't get their papers published, in an activity where that is a key metric of success and the key communication medium, what's the basis of the 'really good' assessment?
Look at the list of keynote speakers at any major conference you understand. Are those the wrong speakers? Did they get this privilege unfairly?
Every job application process has its own kinds of luck and failure modes. The time scales of academia lead to very different distortions than those in software engineering.
I don't understand your rhetorical questions. Clearly, yes, conferences choose bad speakers sometimes.
I readily agree these selection processes are not perfect, and institutional nepotism in particular is an issue in academia.
You can get a coding job just by acing a coding interview (and having basic social/professional skills). So this part of your comment did appear to suggest that merely publishing papers can be sufficient to obtain an academic position.
What possible reason would I have to interview someone if they had neither relevant experience, nor a degree? Should I just ask random people I see on the street to come in for an interview?
If you're talking about people who have no experience in the sense that they've never written a line of code, then no, obviously not. But professional experience and relevant qualifications are not necessary.
As with any job application, you need to have something going for you. It just doesn't have to be any of those two things.
The other losers are people who have skills and aptitude that is actually needed, but don't have the thing that interview measures. Yet other losers are people forced who have to work with those who ace interviews and get rewarded, but are not actually good in actual work.
The side note is not just that hiring don't really measure what matters for job performance. It is also that companies themselves don't really seriously care about it nor spend time thinking about it. That affects not just hiring, but also promotions and other rewards. Which in turn causes additional problems and unhealthy workplaces (excessive crunch being one of those, huge amount of socialization that is expected in some companies another, ridiculous technological decisions too and so on and so forth).
But, I also think that it will end up split into different kinds of interviews for different positions. The older I am the more I believe that there is no single "good in tech" aptitude and that such notion is nonsense. Rather, different tech jobs require very different amounts of abstract thinking, logic, patience, memory, aesthetic feel, detailed knowledge of some sub-area, ability to communicate, self control, punctuality and so on and so forth.
You can be quite crappy at assembler and heavily talented for enterprise java for example. You can be good at smaller projects and completely fundamentally fail in large codebase many people situation.
I agree also in theory, but as you said there are vast differences in speciality. Some programmers are far more product focused and have an eye for design and communication, and some only do well when they're deep in the weeds of some obscure perf optimization. The latter gets hired quicker, while the former can often do a lot of useful things for an organization.
So here's the selfish-as-a-hiring-manager side of not liking the current style of interview questions: I don't want my bar to be so low that studying for a few weeks or months is all it takes.
One or two medium-level problems to make sure they're not full of shit about being able to write code at all, sure, but the rest is gonna be a lot more targeted to the role.
For anything non-trivial, as your code grows the amount of time required to understand it will grow too -- even if you're using "standard" frameworks, etc. -- because the business logic driving your design decisions is learned with experience. For example, we have a guy at our large company who's a terrible programmer but we keep him on the team (albeit somewhat quarantined) because he's been there forever and has enough institutional knowledge to be valuable.
As your systems grow even more, there will not be off-the-shelf solutions. You'll have to sit down and do some real-life architecting and that won't be learned in 2 weeks. Even if you could perfectly document all your systems and design intentions (you can't), well documented decisions still take time to be read and "soak in".
Or maybe it is easier in large code bases because the worst programmers fail? I don't know, I haven't worked with many tiny code bases.
The challenge I'm still facing is crafting interview questions that most effectively match those two-week impressions.
My issue with purely sticking to coding questions is that I've seen a handful of people study enough to nail those and then be completely uncreative or unmotivated beyond that. Specificity seems to be a key thing in other types of questions, to at least weed out the hopeless. You built this thing? You had that experience? Tell me the details. Tell me the details of those details. Etc.
One of the things making it hard is that the true standouts are rare enough that I've only hired a couple of them, so it's hard to find what's meaningfully shared between them that's identifiable in a single day.
I'm not sure how you could have confused what was posted, to be interpreted that way.
You made up a question that wasn't posted. Please re-read the thread. Please don't attribute your words to someone else. It's transparently dishonest.
* Electrical Engineer - 95,230 USD
* Chemical Engineer - 97,360 USD
* Mechanical Engineer - 83,590 USD
* Biomedical Engineer - 86,220 USD
Software engineers are paid well, but there are definitely other engineering fields beating them.
Petroleum engineers, on the other hand, make 100+k in pretty much any region.
The point of this final exercise was for me to talk through my thought process. It was a debugging problem, and I eventually succeeded, but not without fumbling around for 15 minutes or so. The solution was a stereotypical example of being "right in front of you", but the nature of this exercise threw me off. When I look back, the analogy that makes the most sense to me is the boxing glove wall from the TV show, Wipeout [1]. It's a simple problem of getting from point A to point B with the twist of getting punched in the face, or the stomach, or the leg, at seemingly arbitrary intervals. I can see this as a good simulation for the reality of an engineering job (being faced with unplanned interruptions and having to bounce back from them) but, at the same time, I've never had to verbally talk someone through every keystroke and mouse movement that I make while debugging. I was frustrated with the exercise and with my inability to immediately diagnose the issue. The interviewer was amazing at getting me back into the right mindset after noticing I had fallen off the wagon each time, which showed me just how good of a manager they were. However, the more I realized how terrible I was doing, the worse I performed. I left with the unmistakable feeling of dread having set-up camp in my stomach. Despite arriving at the solution, I knew I had blown that exercise.
In the end, I was turned down. The official reason was that another candidate had accepted an offer for the position, but the hiring manager also told me that my programming skills were perceived as sub-par due to the final exercise. They said I'd be a great fit culturally, and that their team enjoyed the conversations we had, but my Python skills just weren't good enough. Being someone that really identifies with their abilities as a programmer, with Python being my language of choice, this verdict has kept me awake at night. I'll never know if the actual reason was due to the other candidate accepting or due to me being my own worst enemy during the final exercise.
The tech hiring process is one of the only times I've gotten 100% of the problems correct yet still failed. Half of me says that's bad, but another part of me understands in situations that require context like mine above. It's not the manager's job to babysit me when I psych myself out, or when I'm having a bad day. Engineers need to be reliable and stable enough to work efficiently on their own. Had I been alone, I would have found the solution much quicker. But you're almost never alone in a real work environment. Some of these exercises are measuring much more than just algorithmic competency.
My hypothesis is that the bar is still too high and that if you have a basic technical baseline you'd still perform well regardless of your white-boarding abilities. Google could run this experiment and in fact they might already have enough data to answer it with a causal analysis.
The key issue is how do you define "performance" both in the interview and in your yearly review... nobody has a clue how to actually measure performance.
http://www.businessinsider.com/how-google-hires-people-2013-...
In this case though, how is 'lots of money' wasted? It seems that Google hired good candidates despite some of the questions being bad. I think the point here is that Google is looking to increase the efficiency in interviewing, but they're already at a high efficiency level anyway so they continue to be successful in attracting and keeping talent.
What if instead of reading resumes/interviews/whatever else they did they just put all the names into a hat and made offers to everyone selected? This is your baseline, does your process beat this? If not, you could save a lot of time/effort using the hat selection method. (note that it is possible to be worse than the hat method)
1. It's good that companies like Google are able to reassess their hiring policies and learn what works and what doesn't. It's easy to criticize companies for doing things that don't make sense or that we know to be bad, but often these things looked like good ideas at the outset and you need some amount of trying new things (many of which won't work out and may have negative consequences) in order to improve things.
2. The way hiring works in tech isn't really that bad. It doesn't really measure what matters for job performance but tech pays well and so many people want to do it that you need barriers to entry. The real losers of the hiring process are the companies that waste lots of money on inefficient hiring practices. If you compare the effort required to get a high paying tech job (really just doing practice problems for a few weeks/months) to any other high paying, professional field we have it much better.