Hard to take this seriously with all the straw men and broad generalizations.
Reality check: there has never been a hotter seller's market for software engineering talent. The fact that you have not landed a job does not mean that supply is not short in general. Rather than blowing your stack at some recruiter who you heard on a podcast interview, you might want to reflect on yourself and how you might be coming off in job interviews.
As far as low pay goes, yeah, welcome to the labor market. It's easy to write a blog post about how companies need to pay more, but hard to reconcile the reality that if they don't have FAANG cash flows, "market rate" for developers may not be viable, regardless of management's good intentions or lack thereof.
And with regard to bad interviews, remember interviewers are individuals, with skillsets all over the map. Once you get more senior it gets even more frustrating to be judged by someone who has a fraction of your experience. Trust me when I say there is no value in dwelling on this or getting your undies in a bunch. Suck it up and figure out how to play the game (read CtCI, practice on interviewing.io, ask for feedback) and land the job, then do the best work you can every day. Angry screeds will not change anything about the industry and will not help you.
When I graduated with my CS degree, I was _thrilled_ to be offered 50k. Now new grads feel lowballed at 200k TC. So hard not to say that the market hasn't adjusted somewhat.
At the same time, part of the reason companies even have to pay so much is because they've made interviewing so damn hard. I personally know many people at great companies like Google and Twitter who are _desperate_ to change, but they are too afraid to interview. They feel they got lucky and got through the process once and are unlikely to be able to repeat it, and they might be right. The industry has taken "false negatives are better than a false positives" to an absurd extreme and then complain there's a shortage.
It's one or the other. If you're saying "a false negative is ok" you are implicitly saying "it's totally fine if we fail to hire good developers", and you can't say that then turn around and complain it's too hard to hire good developers. Which is _exactly_ what all my recent employers have done.
> It's one or the other. If you're saying "a false negative is ok" you are implicitly saying "it's totally fine if we fail to hire good developers", and you can't say that then turn around and complain it's too hard to hire good developers.
This is it in a nutshell, good summary.
So many of these companies have built an arbitrary interview process that takes pride in rejecting nearly everyone, regardless of actual skill in building products. So with that criteria, yes, it is hard to hire anyone. Which doesn't mean there aren't tons of perfectly competent people available, it's just that none of them can pass the silly interview because they haven't spent 10,000 hours memorizing leetcode.
Typically someone will say "the bar is high", but that's not at all the case. The bar is in the wrong zip code. Because that kind of interview process measures nothing relevant to job performance. So the best developers, who are busy building successful products, will inevitably fail because who has time to spend on irrelevant interview prep.
Interview for the job based on actual experience and you'll find, like I do, that it's not hard to hire competent people.
I spent nearly a year interviewing at various companies and never landing a job despite decades of practical, relevant experience. It was extremely demoralizing and worrisome, and I believe the majority of the issue was extremely difficult interview processes.
The size of the company didn't matter - in fact, the smaller the company, the more difficult and onerous the process was. One place with six employees asked for a full day's work (offering $150 compensation). One place turned me down because I didn't have enough Scrum experience and the Scrum Master - a real job title apparently - didn't think I'd be a good fit.
Sometimes I wonder if small companies are just full of bitter google rejects who have decided to make the interview process miserable to boost their own egos. I went through a year of being unemployed not too long ago and it was very painful. Receiving no feedback is the worst part by far.
A recent project required some work in jquery. All of the other developers stated that it would be difficult and take them too long because they were not familiar with it - being react devs themselves - so it was left to me. I was shocked. The idea that jquery could possibly be described as being more difficult than react is amusing at best. Sure, it was largely an excuse on their part, but I was left speechless nonetheless.
I guess my point is that nearly 20 years of dev experience leaves me with the ability to do the old and the new. I wish this was more respected by companies in general.
No offense meant, but if you are surprised about the existence of Scrum Masters, then that interviewer is not at all wrong for wondering if you have enough Scrum experience.
Unless you are being hired as a Scrum Master, “not enough scrum experience” should not be a hiring consideration. On the other hand, it being a hiring consideration is such a negative signal that mossing out on a job because of it is almost certainly dodging a bullet.
It’s true too that 4 out of 5 scrum masters will lament the bothersome dearth of experienced scrumee programmers. Never a shortage of scrum masters, or ceos or vc or debt. But labor you can arbitrage for 10x profits are always hard to find domestically.
Scrum is something management does and the developer has to "bow" down to. It's not something you can learn before the job because every place implements it differently.
> Maybe it was not enough experience working in Agile if you don’t know scrum ceremonies and stuff
You don't get experience with Scrum ceremonies, or other any kind of “ceremonies” unless they happen to be in the application domain rather than the dev process, working in a place that values “Individuals and interactions over processes and tools”.
As a new grad, was I supposed to feel lowballed at getting an offer quite a bit less than that? I know senior devs who make less than that. Is this just for stanford/mit grads?
Most schools have post-graduation survey. Quick google shows mit's 2020 class had 70 bachelor students responding to the survey for jobs in the tech industry, with base salary of:
$97,750, $118,000 $129,000 for 25th, 50th, and 75th percentile respectively
IIRC this number is typically just the base salary so you can roughly double it to include bonus and stock.
Not that I doubt there are jobs which pay this, but from what I've seen of the market, if money is all you're concerned with you should not be turning your nose up at a 200k TC offer.
Google pays new grads like 180 and they’re pretty much the top of the industry in terms of pay scale. Throwing hyperbole in just undercuts the point they were trying to make.
Probably any country that's not the US. Very few companies in the world have FAANG-level cashflows or Silicon Valley-level funding to be able to pay developers high salaries.
Yes, a new grad "feeling lowballed by 200k" was hyperbole because I waste too much time on Blind. But FAANG new grad TC is pushing that number, which is a stark contrast to my new grad numbers ~2010. But it was probably confusing for me to phrase it that way.
I had $200k+ TC new grad offers from FAANGs in 2013, and one of them wasn't even for a role in the Bay Area. It's not a stark contrast at all. The market has been consistently willing to pay strongly for new talent.
Wildly is about right. The last decade has been the highest real world inflation I've experience in my life and I'm not particularly young anymore so been around for a while.
“ I personally know many people at great companies like Google and Twitter who are _desperate_ to change, but they are too afraid to interview. They feel they got lucky and got through the process once and are unlikely to be able to repeat it”
Is this just a perception issue or have they actually tried interviewing a few times with negative results?
While property prices have definitely risen, consider that every other industry has not seen the same level of income growth. We are still privileged to command this kind of salary as tech employees. (Yes we worked hard etc but I also try to remember that the median household income in NYC, where I live, is $63k).
Software engineers should not compare themselves to a basket that includes (presumably) labourers, tradesmen, etc.
SEs are educated, highly-skilled individuals and should thus be compared to the VALUE the NYC society places on other highly skilled, in-demand individuals.
Be assured that NYC lawyers, radiologists, and bankers don't compare their remuneration to an average that includes dustmen, baristas, and hot-dog salesmen.
Software engineers did ten years ago. That you think the proper reference class for SEs is higher professionals, not the general population, or even engineers generally speaks volumes about how things have changed in the past decade or so. There are lots of actual engineers being outearned by boot camp grads with two years experience. That’s nuts, and it’s quite new.
How is SE today less complex than 10 years ago? It seems to me that even as tools today are more powerful and basic compute and storage are cheaper, non-functional requirements have only ballooned.
e.g. Lotus 1-2-3 was probably far easier to develop than Google Sheets presently.
I don’t think the complexities of SE, on the whole, have changed substantially in the last 10 years. If anything the tooling has gotten better.
Lotus 1-2-3 was 40 years ago, not 10, but still. The Lotus devs, of which there were only a handful, were writing in ASM, for an insanely memory constrained platform. I bet Google Sheets is insanely complicated too, and has all the multiuser requirements. But those devs have all the resources of Google backing them up. I’d call it a push.
> At the same time, part of the reason companies even have to pay so much is because they've made interviewing so damn hard.
I don't agree at all. Pre pandemic I worked as a professional software engineering interviewer for a largish recruiting company. I did 400+ ~2hr interviews over about a year. We did not put forward the vast majority of people I interviewed.
Lots of people on HN, and certainly lots of people who get rejected time and time again seem to have the perception that:
- Most candidates (their friends in collage) all have reasonably similar aptitude
- Doing programming interviews doesn't offer a lot of signal, and there are lots of false negatives.
- The hiring bar is too high
Aka, "I passed all my CS classes! Why will nobody hire me!? It must be something wrong with interviews, not me!!"
All of these points are wrong. There is a massive difference between strong and weak programming candidates. Weak candidates can barely program at all, no matter what their background would suggest. We did multiple quantitative assessments. The various assessments all end up strongly positively cross-correlated. So we can tell we're getting a clear signal through our interviews. Weak candidates generally wouldn't fail just one part of our assessment; they'd fail all of them. And most strong candidates would demonstrate that in almost every section of our interview.
We passed / failed based on a ML system which tried to guess who we could place. After a couple of months I was calibrated enough to be about 95% accurate at guessing what the AI would say. Its surprising how little ambiguity there is. Only about 1/10 people were "on the fence". Almost everyone I interviewed was either a clear yes or a clear no. If I interviewed you and I didn't recommend moving forward with the hiring process, its probably not because I didn't like you, or because the interviewing process is broken or the hiring bar is wrong. Its probably because your programming skills just aren't strong enough yet. My notes were filled with "This person is amazing and I love them to bits. But we can't move forward because when push comes to shove, they just aren't very good at programming."
The harsh version of this is: The hiring process is fine. If you keep failing job interviews, the problem is probably you.
I think there's two real issues with interviewing. One is that some candidates get massively stressed out, and can't perform under pressure. Secretly my job was all about trying to help candidates relax. After 1 year I still wasn't good at it. I bet most interviewers at most companies are terrible at this.
The other issue is that most companies have no interest in hiring junior people and training them up. They can't afford it. You could hire a junior, spend 9 months paying them a (low) salary while they're net-negative to your company's productivity only to have them leave and work somewhere else as soon as their skills are up to snuff. Companies are incentivized not to bother doing that at all - which in turn narrows the funnel of people who can make it to high quality mids and seniors.
> I personally know many people at great companies like Google and Twitter who are _desperate_ to change, but they are too afraid to interview.
You know you can start a job hunt before leaving your current role, right? I personally recommend everyone interviews around every 6-9 months, no matter how much you like your job. There's a huge peace of mind from knowing how much you're worth at other companies, and keeping your resume and interviewing skills fresh. As covid shows, you never know when you might need to look for a new job.
So, assuming this is all essentially right from the employers point of view, what can senior developers do to make the selection / hiring process more efficient for themselves? The thing is that there are a lot of spammy recruiters as well. And dealing with them costs a lot of time. At least if one does not want to do a shotgun approach to applications, one has to be really selective on where to apply, with very little solid information beforehand.
What I can think of:
* be selective where to apply
* prefer job advertisements on companies web pages, as they give often much more information on the role, than a typical recruiter will give out
* do not apply to job descriptions which are not at least a n 80% match with the own qualifications and interests
* a job offer is not entirely different from a requirements specification, so a good engineering company should be able to write something quite specific
* if one stated requirement is not matched in the application, explain and point to an equivalent qualification (say, no years of experience in Go, but 10+ years experience with each of Java, Python, and Ruby).
* as a reasonable coding task should not require preparation by experienced people, do not prepare for them
* Interviewers have a reasonable interest to learn about the candidate's skills in programming. But it is hard to measure that with coding interviews, especially since since like architecture and design decisions become much more important for actual senior work. It might be more efficient for the developer to put some personal programming projects on github, and put the URL in the resume - qualified interviewers can then ask about the code and gain insight from the reasoning behind it.
And, another question, how should one handle recruiters and interviewers which apparently have not read the resume? Or the ones which ask one to apply even if the specified required qualifications do not really match? (e.g., have never worked extensively on Windows, a lot of experience with embedded C++, but recruiter asks to apply for a C# job?).
For HR people it would certainly help them if there were more information about the company, tools, actual tasks, and some words on what the core of business is - and how software relates to that.
I don't think spending so long on the other side of the fence has given me much special wisdom, but the first thing to mention is that, if you don't have a warm lead, you will need to take the time to prove to the company you're applying to that you have actual programming skills. Nobody wants to waste time doing this; but companies have very few reliable signals outside of an interview to differentiate you from someone who's vaguely terrible at programming. And programming job ads get flooded with low value candidates. They can't tell you apart from your resume (people lie) or your github profile (Its easy to clone semi-popular projects to pad out github repos).
> be selective where to apply
100%. And talk to your friends and get warm leads when you can. You can learn much more about what its like to work at a company by talking to people who already work there. Go in for lunch. Get a sense of the company culture. If you have skill, everyone is hiring. Ignore the recruiters and choose where you want to work.
> do not apply to job descriptions which are not at least a n 80% match with the own qualifications and interests
I disagree with this actually. Again, if you're a senior developer with skills, figure out what the company is doing and decide for yourself if you want to be part of that. Technology match matters here; but job ads are pretty uniformly terrible. Nobody knows how to write them well. I certainly don't.
> architecture and design decisions become much more important for actual senior work
Yes; from the people I interviewed, I found senior developers were competent but still a bit slower than mids at raw programming tasks. (This makes sense, because they often don't do it as much). In comparison, senior devs were much better at debugging problems and at architecture whiteboarding style questions.
> And, another question, how should one handle recruiters and interviewers which apparently have not read the resume?
The first thing to know about recruiters is they don't work for you, because you don't pay them. The way recruiting should work is like acting - you get a manager (recruiter) who knows your skillset well. They talk to lots of companies and find you a stream of good gigs you like. You pay them $10k for that service, or 2% of your salary or something. But programmers hate paying for this, so instead all the recruiters work for the companies. They get the same cut, but our experience of working with them is awful.
I'd avoid most recruiters whenever you can. Use HN's job board and things like that, and skip to talking to the actual team managers and engineers as quickly as possible. Recruiters hunting C++ devs for C# roles is just lazy people being lazy.
And who cares if your interviewer has read your resume? Its disrespectful, but it doesn't matter. Roll with it.
What was the placement rate for the candidates that you put forward? Based on your statements, I would expect this number to be very high, but from my understanding of the industry, including recruitment companies that do technical assessments, I would be surprised if it was that high.
I'm not sure how to reconcile a recruiting company well-known for doing rigorous technical screening having a 40% placement rate, most candidates being a clear yes or a clear no, the hiring process being completely fine, and the hiring process not producing many false negatives.
A 40% placement rate implies triplebyte has the hiring bar lower than companies want it to be. Ie, even with rigorous screening, they have a high false positive rate. (Well, that assumes candidates are totally ordered by desirability, which is not at all the case).
There are very good reasons why developer compensation has swelled to the levels that we are seeing today.
Technology firms have grown astronomically. They’ve also built processes and systems to onboard new developers and enable them to generate a lot of value. Developers are being compensated higher to reflect the efficiency gains made my technology firms.
Is it unfortunate that firms that are unable to generate that much value suddenly can’t hire developers? Must be for those firms.
But there’s nothing wrong with compensation growing astronomically and nothing moral in it being low.
absolutely. Google generates $1.5M/employee/year in a high margin business. Considering that the engineers is the main revenue producing asset it is not surprising that Google pays $600K+/year to the best engineers they can get to continue generate those $1.5M.
>Is it unfortunate that firms that are unable to generate that much value suddenly can’t hire developers? Must be for those firms.
yep. Our BigCo generates paltry $350K/employee/year. Looking at our salaries - we're relatively cheap engineers, and the company wastes our time in a myriad ways, and it is no wonder that we can't hire anybody here really - one can say we do experience the shortage of engineers. In SV we regularly lose people (who get 2-3X increases at new places, and only morons like me (even when i got an offer from Google it was just L5 and a very low one, basically just a match of what i have here) are still sitting here), and we're able to hire only in cheap remote locations.
IME, yes people are hesitant to leave sometimes out of a fear of the interview process, but I think this is no different than other industries where people generally are hesitant to take action that has a chance of of 0 payoff with a lot of upfront investment.
I don't think that's unique to software engineering, and I don't think its more pronounced in our industry.
The standard tenure of most engineers is about 3 - 5 years, a very short amount of time. People try and leave all the time. How long it takes someone to leave is likely a good proxy for their risk aversiveness. But people do switch a lot.
I had a VP of Engineering tell me once that 17 months is a standard tenure and that we should be happy with that. I think turnover was part of the strategy at that point though...
I don’t quite understand, switching is good for the employee but in what world is it good for the employer? On-boarding/institutional knowledge/etc all suffer.
Ye it is really strange. Maybe it is some kinda of rationalization. Or people believe in that new people bring new ideas or something.
My experience is that even the best engineers wont catch up for a year or something, to an mediocre one with years of experience in the project/field, if the project is somewhat complex and not routine. In 17 months it is really hard to do anything magnificent.
Unless you're desperate, it's best for all the industry if people don't. We can't mature the software industry hiring practices by playing along.
> Angry screeds will not change anything about the industry and will not help you.
Granted, they won't help the OP directly at the moment. But there is value in constantly calling out how broken hiring has become in this industry. Change won't happen by keeping quiet.
I do my little part (in a technical leadership position) by never interviewing using the algorithm monkeydance. I don't care if you can regurgitate this or that algorithm on a whiteboard. Because we don't do that in the day jobs I'm hiring people for. I interview based on your real world experience because at my company we build real world products. I've never hired anyone to a role of sitting in a room rewriting algorithms on a whiteboard (almost certainly never will), so I'm not going to interview for that irrelevant skill set.
To anyone who has been less than ~15 years in this industry, it's good to know that it wasn't always this way. Interviews used to be sane, based on experience. It's a relatively recent phenomenon how things have gone so wrong.
Okay, but I just don’t think it makes sense to say that companies who cannot afford to pay market rates for software engineers are experiencing a shortage of software engineers, unless there is something preventing market clearing.
There are different markets. It's easy to hire full remote juniors on upwork for next to nothing. Hiring a senior staff superhero full-cyber stack-ninja who happily relocates to where you are... now that's not that easy. And thus on the low end you have a market glut and on the high end you have a shortage.
No, sometimes there is no zone of possible agreement (value produced is below market rate). In this case you can both have shortage and unemployment at the same time.
Example, you have labor force of 10 people. All jobs have mandatory stay of 2 years. 6 companies have an opening each that pays 1 mil/year. The openings are staggered so 3 jobs are available on odd and 3 on even years (and last 2 years). 50 jobs are posted with a salary of 100k/year. These salaries represent value produced to company and cannot be raised. All applicants have equal chance to get a job they apply to.
The minmax solution is to not take a 100k job because of opportunity cost (you won’t get a chance at the 1 mil job next year). So you have both 40% unemployment and massive labor shortage (56 openings but only 10 viable candidates).
You might as well make an argument based on the premise that pigs can fly. Contracts like that are basically unheard of in the US, outside of top executives and a few rare industries like professional sports.
>The minmax solution is to not take a 100k job because of opportunity cost (you won’t get a chance at the 1 mil job next year). So you have both 40% unemployment and massive labor shortage (56 openings but only 10 viable candidates).
>These salaries represent value produced to company and cannot be raised.
This means the company needs one employee at minimum. If it loses that employee it will not produce value. Therefore it is in the best interest of the company to hire two people, the first position is compensated as much as possible, the second is compensated one dollar more than the lowest competing position that got filled.
Thus, the top offer becomes $899999 and the lowest offer becomes $100001. However, there is a problem. We have 12 positions but only 10 people. The companies will have to outbid each other on the lowest position until all salaries hit market rate, which is the average of the top ten original positions (6 times 1 mill 4 times 100k) that market rate is $640k for everyone.
The 100k jobs never get filled and they shouldn't get filled ever, because a lack of customer demand will never be a shortage. (the assumption in your scenario is that training costs exceed $1000k and therefore it never makes sense to increase the labor pool)
The mistake you made in your scenario is that you did not mention price controls enforced by the government. In a free market companies will negotiate and adjust their salary. The lack of training is acceptable for a thought experiment though.
If the value produced to my company by a software engineer is below the market rate for a software engineer doesn’t that just mean I shouldn’t want to hire a software engineer? Like if I run a performing orchestra I probably don’t want to hire an anesthesiologist at market rates because they will provide very little (if any) value to my business.
No, you can be existentially important to the company and still not produce market rate worth of value.
Example: Virtual Widget Co has one employee. The company makes $120k/year in revenue (and so max cap for compensation is ~100k/year because of whatever other costs). If the employee leaves, the company would not be able to continue and will fold. However, the employee is one of the 10 from my previous example, to minmax their own income they should leave the company despite being indispensable to it/the company folds after they leave. No other qualified person would apply for this job either. In fact, it might even be that the average unqualified person’s wage is far below 100k but even that doesn’t help.
A better statement would be “Virtual Widget Co shouldn’t exist because it doesn’t have a viable business proposition”. But this can be counterintuitive in the context of 40% unemployment (4 out of 10 in my example). A more real-world analogy would be “lots of businesses are viable only in the presence of slave labor.”
Yeah I made a simplification so you can explicitly compute expectation values and see that there is no ZOPA, but in the real world there is a thing called opportunity cost and people do choose to stay unemployed while looking for job because some jobs pay too low. This is essentially what I tried to demonstrate in my simple example.
Likewise, if "market rate" is above "value produced by the employee" it doesn't make any sense to pay that much.
There are lots of companies out there that need some tech and some programming, but when the company revenue is only a few million that has to span a few score employees, and costs... its not possible to pay the small handful of devs six figures and keep everything in the black.
Likewise, there are new grads that are scoffing at working for 2x per capita income for the area in the midwest when that's less than 100k (and then complaining that they can't find any jobs).
There is a mismatch of expectations - possibly on both sides of the table.
Market rate is whatever employees will take and employers will pay. If employers are having trouble finding employees at their rates, their rates are below market rates. If employees are having trouble finding work at their desired rates, their rates are above market rates.
>Likewise, if "market rate" is above "value produced by the employee" it doesn't make any sense to pay that much.
It also means that somewhere out there is a business that can actually produce enough value to pay market rate and you should work for that company instead.
I still remain in the "there is a mismatch of expectations" camp. If there is blame to be placed somewhere, I would assign the majority of it to new grads (and boot campers and self taught devs).
With the dominance of tech in the mindshare of people looking for a job, they're only looking at well known tech companies. Apple, Google, Facebook, etc... and these are also the places that can afford to take a risk on a new dev as they've got the institutional inertia to help carry someone along.
The flip side of that is that many people entering the job market don't consider companies like Dominos (only pizza company with a software patent), UPS (that whole 'don't make left turns' navigation thing), Target (early leader in data science), or McDonalds (hiring for some neat stuff in AI drive throughs).
Next, new grads are often expecting that the wages that the big tech companies can offer are standard across the field. I've more than once seen on Reddit a new grad getting an offer (that they applied to) in the northern Great Plains and then backing out when they were offered 70k to work in Fargo.
Another version of the "where are you applying" is that they're only applying to companies in Seattle, SF, and LA and then complaining that they can't find a job.
The idea that seems to be consistent with these new grads is a "I am worth $100,000 and I won't accept anything less." There's a consistent statement that the person is worth that much rather than the work that they do is worth that much.
Spend some time in /r/cscareerquestions to get more of this.
Those trying to hire aren't blameless in this. Expecting developers to fit nicely into the same payroll box as everyone else who reports to a manager in the office with a white collar job could very well mean that the offer is well below what someone with the necessary skills would accept.
My rough ballpark for what a dev should get (with large error bars) is 2x per capita income for the area. That tends to get fairly close to acceptable.
Would the economy benefit from increasing the number of software engineers? In that case it is a shortage from the governments perspective and they should work to increase the supply either via immigration or by encouraging students to study those fields.
> In economic terminology, a shortage occurs when for some reason (such as government intervention, or decisions by sellers not to raise prices) the price does not rise to reach equilibrium. In this circumstance, buyers want to purchase more at the market price than the quantity of the good or service that is available, and some non-price mechanism (such as "first come, first served" or a lottery) determines which buyers are served. So in a perfect market the only thing that can cause a shortage is price.
> In common use, the term "shortage" may refer to a situation where most people are unable to find a desired good at an affordable price, especially where supply problems have increased the price. "Market clearing" happens when all buyers and sellers willing to transact at the prevailing price are able to find partners. There are almost always willing buyers at a lower-than-market-clearing price; the narrower technical definition doesn't consider failure to serve this demand as a "shortage", even if it would be described that way in a social or political context (which the simple model of supply and demand does not attempt to encompass).
Infinite money is not required. As you raise the price of engineers, the quantity supplied of engineers may or may not increase, but more importantly the quantity demanded of will decrease. Once that happens, every employer willing to pay the market clearing price for an engineer can employ one, and every engineer willing to work at the price has a job. Hence, no shortage.
Are the 900 other companies are willing and able to increase their bids to poach the 100 engineers? They cannot all increase bids indefinitely - at some point, only 100 companies will be able to afford the 100 engineers, and at the point the market is cleared and there is no shortage.
Perhaps, but regardless, the other companies could still attempt to bid up, and if they're unwilling to, then they can hardly complain about there being a shortage.
Yes, there is. People are not spherical cows who will forget that they wanted top tier engineers.
Edit: here's the definition that everyone is using, which you posted earlier
> In common use, the term "shortage" may refer to a situation where most people are unable to find a desired good at an affordable price, especially where supply problems have increased the price. "
Simply wanting something at a certain price and not being able to get it is not a shortage. There’s no shortage of penthouse suites at five star hotels just because I would like to stay in one but I’m only willing to pay $75 a night.
In economic terms, there is no shortage. There's a shortage in common parlance terms, sure. There is an easy solution - pay market rates. When people say there's a shortage of engineers, they mean there's a shortage of engineers at the price they're willing to pay.
Yes. And when people say there is a shortage of food, they mean "at the price they are willing to pay". But new engineers and new foodstuffs will not spring into existence when you add a zero to the price - therefore there is a shortage.
You might want to say but oh, more people will become engineers if salaries are higher! But that doesn't ship products this summer.
There are often real food shortages because of price ceilings. Actual food shortages can be seen when the shelves are empty and food cannot be bought at any price.
No, they mean there is a greater lack of engineers compared to other occupations requiring similar levels of education and therefore we should put more effort into educating and importing engineers. Saying we shouldn't focus on getting more engineers in those cases is just dumb, the economy would greatly benefit, you just want to protect your currently privileged position at the cost of society as a whole.
There is a lack of people willing to work for less-than-market-prices in every occupation. I'm not against encouraging people to become engineers or hiring foreigners. But there's simply no shortage if it is possible to attract engineers by raising the salaries you're willing to pay; you're just too cheap. And the side benefit of increasing prices is not only lowering the quantity demanded from employers unwilling or unable to pay market rates, but also raising the quantity supplied by enticing more people into the field with higher salaries.
>No, they mean there is a greater lack of engineers compared to other occupations requiring similar levels of education and therefore we should put more effort into educating and importing engineers.
Importing engineers is just poaching engineers from other countries. It's the same thing.
Educating engineers is a matter of compensation. Given a high enough salary people will get the necessary degree. The only other thing you can do is cut education quality and just let more people pass.
To be fair, if engineers from other countries can earn more money in America, that's an indication that their skills are better put to use here than elsewhere.
No it isn't because you can train 900 more engineers. If companies aren't willing to train 900 more engineers then demand is only 100. Willingness is expressed by the price. If the price is high enough people will train themselves even if the companies themselves aren't providing training.
Let's say you are a forward-thinking manager in a company making artisinal flowerpots. You know tech is the future and will set your company apart, and you want to build a top-tier team to take you there. You are willing to pay twice the compensation per engineer as google.
Now a deluge of engineers show up for interviews. How do you tell which ones are top-tier and which ones are third-rate? Even tech companies struggle with this problem; surely you'll have no chance.
You know you'll get mostly third-rate, because those are the ones looking for jobs. So instead of overpaying, you adjust your pay downward to compensate.
So it looks like there's a shortage to the company (because the top-tier engineers aren't appearing even though they are willing to pay), but to top-tier engineers it looks like they are underpaying.
Tangent: I've thought about this "bootstrapping dev hiring" problem before (you don't know which candidates are good because you don't have anyone technical to interview them)
I wonder if there's a business opportunity for a firm of experienced devs who do nothing but interview devs for other companies
It can go beyond hiring developers - companies may need help with deciding on initial MVP, organising development process, and regularly checking for a while if things go well.
You can invite an experienced contractor that can help you with bootstrapping development: deciding on MVP tech stack, hiring, and making sure the new team can deliver proper work.
Sure, you need someone to refer a good contractor to you first, chicken-eggs problem.
I wonder if there are companies that can help with it as well - not shops that try to convince you to outsource the whole development to them.
Eh, I don’t like this theory because it’s hard to get real numbers until after the interview. The employer should know precisely what they’re buying at that point.
> companies who cannot afford to pay market rates for software engineers are experiencing a shortage of software engineers, unless there is something preventing market clearing
By definition, the market rate should involve zero shortage. That said, search costs and regulatory barriers are significant frictions. In the midst of an unforecasted surge in aggregate demand and you have an explicable event.
Good point, but it sounds like you’re disagreeing on the terms, not the ground reality of the situation.
Lots of companies can’t afford to compete with G / Fb / etc for principal engineers. (And many companies who should hire good people cheap out and don’t spend the money.) Thus lots of important, otherwise valuable projects are staffed by people who struggle to take technical responsibility for the tasks in front of them.
This becomes self reinforcing - senior engineers have a lot of market power. They (we) generally don’t enjoy working on projects with mountains of technical debt alongside the processes which have a track record of creating them. “You’re really talented. Why would you work at a bank / corporate?”
Following that, wouldn't it be more efficient if companies said from the outset what their rate is? That would be a lot more efficient. Of course, the money the company is able to pay depends on the process and the business environment, and the company wants to hire as much qualification as it can afford. But nobody is helped if somebody goes through the interview process only to learn that the salary at offer will never match what he/she wants.
((BTW this is why in my case, I decided to leave the UK for mainland Europe - most job offers in the UK were at little more than half the compensation from what I had earned in Germany before. And the difference was even larger when factoring in the cost of housing!)
FAANG salaries are not the market rate, it’s a market rate for specific companies for high qualified developers.
On another market, I have a small agency, and I simply don’t see how a developer could provide enough value to a client on a typical web project so that we could bill the client enough to pay the developper that kind of salary.
That discussion motivates me to try to increase our rates though.
Edit: clarification of "justify that kind of salary".
Totally agree. I have an acquaintance in "evolutionary biology". She is unemployed for 1 year and trying hard to get a job. I get a "hey how are you" on LinkedIn at least weekly.
That! Is how oversupply on one side and shortage on the other side looks.
>It's easy to write a blog post about how companies need to pay more, but hard to reconcile the reality that if they don't have FAANG cash flows, "market rate" for developers may not be viable, regardless of management's good intentions or lack thereof.
Working for less than market rate is a misallocation of labor. Of course this is under the assumption that your skills are not far below the average developer. If the market rate is high, there are more profitable companies out there that need the labor more than your business, taking labor away from those companies is a net loss for everyone involved (your own company loses potential customers, the worker loses out on salary, the competitor loses out on labor).
harsh, but true. I also feel the author's struggle, in my opinion there are a lot of factors to consider why some of us don't get what we expect.
The only thing we can do is to constantly improve and give our best in every interview we got
If you can’t pay market rate salaries, your business is not working...
EDIT: It seems people took this to mean I think everybody should get maximum salary, when what I meant was you should get a fair salary. Maybe I don't understand what market rate means in the US.
market rate =/= "most extreme salaries from the largest tech companies". By statistical definition, the highest salaries can't be the median income for newgrads.
As a follow up to your edit: I think we agree on what market rate is, but what market rate actually is for tech is subject to a wide variety of answers. So that may be where the discrepancy comes from.
that and the article in question giving questionable numbers like:
>50-70k is a junior’s salary. Your people with 10 years of experience with C++ or whatever should be paid closer to 300k
50-70K out of school is normal in the US, but not necessarily all of US (70K in expensive areas like San Fransisco would be low balling, even as a new grad). 300K, even after 10 years, is not normal, not unless you started at a top company and/or have been aggressively chasing pay raises, internally or through job hopping.
BUT, while abnormal it's also not a surprising number to hear either. It depends on so many factors.
Note that 70k for one person in SF is considered low income/needs assistance/basically not a living wage by hud.gov. The bare minimum is somewhere around 90k.
At about ~140k for one person, you will still have difficulty renting a single housing unit because you will not be able to meet % of income = rent calculations. I have experience with this (and unrelenting corporate managed rentals charging several hundred in nonrefundable application fees just to reject for low income at 6 digits..).
"market rate" usually applies to a single good (or goods that are fungible between themselves). i think for your car or engineers we would say there are many different markets depending on skill level, location, nationality etc
The mistake is that companies want a certain quality standard for as low a price as possible, which means their salary expectations don't match their quality standards but they put out press releases telling everyone that it's not the case.
> It's easy to write a blog post about how companies need to pay more, but hard to reconcile the reality that if they don't have FAANG cash flows, "market rate" for developers may not be viable, regardless of management's good intentions or lack thereof.
Is that a sign of monopoly? When a handful of corporations have vastly more resources than the rest of the industry?
No, that's just reality. There are vastly more small companies than large in every industry. They all find their niches. Swift Energy still exists even though Shell and Exxon are a million times larger. Do Shell and Exxon have more resources, throw their weight around more, etc? You bet. Are they monopolies? Not in any plausible way I've heard anyone describe.
Out of Facebook, Apple, Amazon, Netflix and Google - Apple's interview process is actually quite gentle. It's definitely the most human focused out of all of them.
I flipped the bird at Facebook and Google, and got frustrated with Amazon's to cancel my interview mid process.
In my understanding, Facebook and Google have centralized interviewing, whereas at Apple each team did its own hiring (my team of ~40 had their own recruiter, did all their own interviews, etc.). Amazon I believe is similar to Apple but the teams are larger? When I interviewed there it was all for the ads org, and there weren't people from other parts of Amazon.
I actually had quite the opposite experience, Apple absolutely grilled me at the spot for its interview, even though I did pass it, but I didn't take their offer.
They definitely grilled me... It's just that they actually had humans talk to me and answer questions, not just throw a website with an automated judge and intentionally confusing problems. (My first language isn't English)
Facebook was very robotic in their process, with a lot of demands for preparation.
Google and Amazon aren't that far off.
This person sounded really experienced, so I looked them up on LinkedIn. 7 months at their first company. 9 months at their current company. That's it, aside from non-programming jobs before their bootcamp.
The whole thing reads like inventing scenarios that didn't happen or embellishing them.
> A bad interview is when you ask them the definition of some specific thing in some specific framework like “Tell me what a closure in javascript is.” then treat them like they’re stupid if they don’t know.
Not that believable, but okay.
> I once had an interviewer ask me if I was a wizard with GO, C++, Rust, and C over the phone. Then when I said I had some experience with rust, he immediately cursed at me and hung up.
Didn't happen.
> Nobody in their right mind is going to move to San Francisco, California to be a “Lead developer” for only 70k with zero equity.
Are any companies actually trying to recruit like this? And is it successful beyond just throwing up a hiring post and not getting anything? I put in a limit buy of $3000 for 1 BRK/A on a whim once.
Somewhat relevantly, a closure isn't a "specific thing in a specific framework." Its a concept that exists in many languages, and has no real relation to frameworks.
I would never treat someone like they're stupid in an interview, but being completely unfamiliar with common programming concepts and treating them as irrelevant or trivial things is definitely a red flag.
I know approximately what a closure is, and I am sure I have used such constructs instinctively in my work many times. I don't have a formal Cs education, but have never failed to not be able to finish my coding work because I didn't know stuff.
Once a guy asked me to write out merge sort on a whiteboard and I couldn't. I didn't get the job. Surprisingly I'm doing just fine in my current position and am very productive (as much as I may say so myself) and have never heard complaints from anyone that I don't know what I'm doing.
So if you don't see a CS degree in the resume then don't ask what a closure is or to implement a merge sort in the interview. Ask them to solve a real problem. The top computer scientists didn't discover the merge sort for years or decades and you want me to figure it out on the spot? Or you just expect me to memorize useless shit like this? Give a problem a programmer would encounter on a day to day basis that wouldn't need a lot of googling. Let them figure out how to solve it and see if it works for you.
You probably won't need merge sort in your day to day programming, but closures (sometimes called lambdas), definitely. Every time you create a function that captures some variables outside its scope, congratulations, you've just used a closure.
Yeah, without knowing the term closure or lambda(which are not necessarily closures but could be as an implementation detail) I'm not sure how one would effectively communicate with others about code in a high-functioning environment using high-level languages. They are very widely used.
i now know of closures, and have actually used them intentionally, and rarely, and def not enthusiastically.
i lived mostly in the java world, and discovered closures when i was getting wacky results while playing around with a Clojure looping example.
then ran into similar situations about once a year when doing something in javascript -- usually passing some function for a callback, and needing access to 'this' in the original/calling scope - which only confused things when i needed access to 'this' in the (local?) function scope, too.
guess i'm not against closures -- they just seem mysterious to me.
ditto lambdas. they seem like a good way to write esoteric code, and write more error-prone/less-defensive code -- that, for instance, might be more likely to produce NPEs, and generally be less maintainable b/c of the focus on brevity instead of clarity, and be geared more towards expert users/coders instead of the generalists (like me) who are often brought in to maintain older code.
That's true. The problem in this case is that they are weeding out applicants based on their knowledge of terminology. Talking about a concrete code sample may not fall into that trap.
> "I don't have a formal Cs education, but have never failed to not be able to finish my coding work because I didn't know stuff."
...that statement looks kinda sus. In a code review I'd maybe get you to simplify it or break it up to confirm the negatives end up meaning what you wanted them to mean.
If you claim to be very experienced in JavaScript but then say that you are ignorant of closures, then that's definitely a red flag. That language relies heavily on closures, more than others, and almost every programming pattern in the browser involves capturing some sort of state about enclosing scopes etc. given the asynchronous nature of things.
The inordinate amount of space the article devotes to complaining about 'credentialism' just reinforces the impression that the writer hasn't taken the time to know his tools/languages/frameworks at a deeper level, and is dismayed to have been found out in interviews.
The person may know what is and how to use it without knowing its formal definition in programming language theory. I personally find interview questions that ask you to regurgitate definitions like an exam to be poor indicators of real world skills. It would better if the interviewer first established terminology to avoid confusion and then ask how they would use such language constructs
I don't think it's unreasonable to expect someone applying for an engineering role to know the technical terminology of their field. Especially if they've been "programming for many years" as this person has.
Adding to this, I think even a little bit of genuine esoterica is okay in an interview process so long as:
1) You're looking for someone with deep knowledge of that subject
2) You don't treat it as an automatic fail when they get it wrong
If I'm interviewing for a senior role, and I ask them a few super obscure questions about the language/framework/platform I need them to be an expert on, that serves as a litmus test for their overall depth of knowledge. Those facts individually may not be required for the job, but they give a read on how deep the person's knowledge goes in general.
But, as you pointed out, I wouldn't really even put closures in that category. For JS it would be something more like, "What does '{} + 12' evaluate to?"
Again, it's just a signifier. If you know the answer (or can explain a good guess!), you probably also know a bunch of actually-useful dark corners of the language. If you don't know the answer, you may still know all those other things. It's just one data point among many.
You're right! Though the original question - '{} + 12' - is extra tricky and actually evaluates to 12 ;) I'll leave figuring out why as an exercise for the reader
at this point, i'd love to know when the answer is just '12'.
i remember going at it with some dude back in the day who was 100% certain, and got visibly upset, when i stood my ground that java only used pass by value. i allowed that even object references were being passed, but that they were passed by value.
>at this point, i'd love to know when the answer is just '12'.
Ctrl+Shift+k in a browser (firefox) opens a console. Just write {}+12 there and hit enter.
My guess is that {} is (in some circumstances) evaluated as a block of code (instead of an empty object). Since the block is empty it evaluates to undefined. The +12 is considered another block of code ( the + operation takes here only one parameter - so it is not a sum ). Consecutive blocks of code are evaluated to the value of the last block of code, which is +12.
{}/12 for example doesn't work at all - which is a hint that the + is not a summation operation.
Edit: I'm wondering why we use 12 and not 42
Edit2: Technically you are correct about java being pass by value. But at this point I'm questioning the sanity of the distinction. It feels more and more like a philosophical discussion.
> > ask (...) “Tell me what a closure in javascript is.” then treat them like they’re stupid if they don’t know.
> Not that believable, but okay.
To me, it sounds very believable. I have been asked about defining what closures are multiple times.
I switched a couple of times between backend, frontend and mobile, and I had to learn bunch of interview questions that never came up in real life.
In different communities, there are different concepts that they love to ask, even if in the end at your day job, you rarely use them.
The JavaScript interviews are always about quirks very specific to JavaScript that the interviewer learned last week. They then act like without that knowledge you can't possibly contribute to their Angular dashboard.
JavaScript people always go through some examples of the "you don't know js" book, and they ask about the quirks of the language. My opinion is that the code they ask about would be rejected at most companies PR review process, because they are tricky, unclear, surprising. The "You Don't Know JS" book is a great book, and you shouldn't use 95% of the code in there if you want to scale your team without very-hard-to-find bugs.
Java and Android people love their design patterns and clean architecture questions, and they would be floored if you told them that you don't need 13 layers of classes just to call your backend and build a plain old Java object from a JSON.
People also love asking questions they themselves could barely answer. Yesterday, the team lead of my team had to accidentally clarify the event loop in a technical meeting, he was squirming, his clarification was terrible, yet we expect juniors to nail the question, and if they don't explain it exactly like we would, we act like the candidate is a "script kiddie".
If you're looking to get hired as a front-end dev at any level above entry-level, you definitely need to know what a closure is - not just for its utility, but because it can cause nasty bugs when you implement it unknowingly.
If I were hiring a mid-level or senior-level front-end engineer and they do not know what a closure is, that'd be a red flag for unfamiliarity with a core language feature. It's on par with not knowing what a decorator is in Python, or reflection in Java.
Yeah, I think this post is much too generalized compared to what the author has really experienced. It is pretty clear reading between the lines that they're finding getting an entry level job frustrating.
> Are any companies actually trying to recruit like this? And is it successful beyond just throwing up a hiring post and not getting anything?
During an active season (spring, fall, usually) I get one of these a day, or every other day at least. Other times it slows to a trickle--1 a week or so. Usually it's some "I have an urgent requirement for a 6 months contract position for $45/hr. with (litany of skills/responsibilities that screams shitty Dilbert-esque cesspool). This is for in person only at (place on the east coast which would require me to uproot my family and move across country)" style content. Some of the more amusing ones are for contract positions in the Bay Area--those usually have people who, bless their hearts, think they're making an effort with $75-$80/hr rates.
Is this one of those "We couldn't hire locally so we have to get someone in on visa" type situations? I know that happens here (Australia), at least pre-covid
I've seen some "top performing" code, that I had to just trash... because making any changes to the hack job of top performing "just ship it" people is a nightmare.
I'll give the benefit of the doubt to someone with 25 years experience that they know the difference between a true 10Xer and one who 10Xes by leaving 20X of tech debt in their wake.
Bootcamp grads haven't been in the workforce long enough, so whether they can weather the fickle winds of the technology landscape is an open question. That's where the CS degree shows its worth: technologies change but fundamentals change less. Comparison-based sorting is still O(nlogn). You still have to partition and break down large data sets in order to work on them. Time and space tradeoffs will always exist and will need more than a bootcamp education to be able to evaluate properly.
meh - I had basically 2 data structure courses, which is not a "year of classes" since the class met for 1 hour, twice a week for about 20 weeks, and times 2 for that second semester. So I have 20 * 2 * 2 or 80 hours of O notation and heap sorting.
The rest of my CS degree consisted of a lot of stuff I used in class (assembly programming) and maybe I got something out of that. I also took a functional languages course which was taught with Scheme (a lisp dialect) which is a little iffy on practical skills. A formal database class (which was an elective)
So I know boyce codd normal form and o-notation, is that really much of an edge over the bootcampers after a few years?
And to be honest because everyone brings up O notation every time we have this talk I'm pretty sure most bootcampers learn that by looking it up and probably binary trees. Yeah. so I'm really not very convinced from a practical level how much more they're pulling.
It seems to me I was in the wrong classes altogether - the real money at this point is in ML and there's not much a CS degree helps with in that area really - so yea, the fundamentals did kinda change, right?
No. Look around you in any tech organisation and see how much value is generated by the people who code vs. data scientists, and how many software people there are vs data scientists. ML is very popular and the startup ecosystem has latched on to it for funding but the fundamentals of CS have not changed. Sure, there's real money in ML but there's plenty of lucrative opportunities in software development.
Your post somewhat proves my point: you are here (and presumably thriving) in software dev despite taking many courses that you deem only tangentially related, years ago. Whether the same can be said of bootcampers remains an open question, because they haven't been in the industry long enough. Anecdotal evidence from software dev managers I know who have tried hiring bootcampers has been overwhelmingly negative (but they are often comparing BS/MS/PhDs who have spent 4-10 years immersed in various aspects of CS to bootcampers, which isn't fair).
I own an agency. Yes there are shitty agencies, but there are also _plenty_ of shitty companies hiring directly. We have shared our developers' bafflement at how poorly they get treated by Internal Recruiters at the hiring company several times (and generally never worked with the hiring company again).
I had a few like this particularly when I was first entering the field professionally, but not so much anymore. I had one that wanted me to move out to some random town outside myrtle beach for around $17/h iirc.
If he had only that much experience and he applied for some senior position that required years of knowledge, I'm not sure I would curse at him, but I would definitely be really angry at him and whoever let his resume turn into an interview.
we hired a confident 2 year out bootcamp grad that was able to pass our interview process and he nearly destroyed our company, twice. There is a reason the interview is difficult to pass, being a dev is a job with an insane amount of responsibility, you do not want bad people in there.
It sounds more like your company has failed to implement robust processes to catch mistakes before they're big problems to me. No individual should have the power to destroy the company except maybe a CTO or a lead sysadmin. For everything else important there should be layers of security and QA checks, with automated sanity checks on config and data for really important stuff. If a new hire can deploy stuff without multiple people seeing it before it gets to production then everyone in the company is responsible for accepting a process that can lead to serious issues.
This is what I call the "Perfect World Fallacy". Yes, in a perfect world, you'd be absolutely right. But that's not the reality we're living in – in particular, that's not the reality small and young companies are living in.
When you're scaling up, or when you're short on staff, and there are fires to be put out everywhere, you just don't have the capacity to design and test those perfect processes. Where are they supposed to come from?
> layers of security and QA checks, with automated sanity checks on config and data
Ha! I've never, ever seen any company which comes even close to that platonic ideal.
Yes, in a perfect world, you'd be absolutely right.
A lot of companies choose not to do process oriented work, and just wing it instead because they believe they can go faster. That's fine. It's a choice driven by resources.
What's not fine is complaining that someone you hire is "bad" because they get stuff wrong when you're forcing them to work without a process-based safety net. People will always make mistakes. If your belief is that everyone should be perfect because you've chosen the no-safety route then you don't get to complain when someone nearly sinks the company. Expecting people never to get things wrong is unreasonable, and it's the exact reason why we have processes to catch problems.
> If your belief is that everyone should be perfect [...]
Well, you seem to believe there's such a thing as a perfect process. How is a non-perfect employee (or a group of non-perfect employees) supposed to come up with a perfect process?
> [...] because you've chosen the no-safety route [...]
Who said anything about no safety net? Maybe there was a process, or a safety net, but it wasn't perfect and didn't catch those mistakes?
I didn’t fire him because he made 2 mistakes. I fired him because I was giving him 10-15 hrs/week of coaching and mentorship and he wasn’t improving at all. The process that was bad was our interview process and our process change was changing our interview process.
Pretty strong disagree on this. I prefer working on teams that optimize for execution speed and just hire people who won’t go up in flames in that environment.
Focusing on process and making the safest process will kill your team. Your best team members don't want to be hampered by a process that slows them down to protect them from their worst team members. The advantage you have as a startup is speed, don't throw it away so easily.
You recognise this and you didn't implement processes to catch problems after the first mistake (obviously, because there was a second mistake). If there's a third mistake I think you're going to have to accept it was partly your fault.
I don't think that. I think that when someone fucks up so badly it almost ends the company you review all your processes and work to limit the possible damage any one person can do. That would be a matter of putting in lots of additional checks for things to start with, and then removing them as you figure out what things don't need multiple people's oversight.
That sort of bureaucratic process is horrible and annoying, but it's less horrible and annoying than everyone losing their jobs when the company fails.
We're very fortunate in tech that we can automate 99% of this stuff. Stopping someone pushing bad code that fails tests or hasn't been peer reviewed is a straightforward case of adding some deploy rules to a repo. It's much harder to fix processes where things are manual checklists people need to follow.
In a company there are seldom human failures, those are process failures. If deploying means sshing into prod server and messing around, anybody is going to eff that up sometime. That person is then not a failure, having to do those error prone tasks is the failure.
> The general rudeness is ridiculous. I once had an interviewer ask me if I was a wizard with GO, C++, Rust, and C over the phone. Then when I said I had some experience with rust, he immediately cursed at me and hung up.
> This experience is fairly common.
Is it? I've done a fair bit of interviewing on both sides of the table, and can say with complete honesty I've never heard a curse said in anger in any of them. I've also never heard of it happening from a co-worker or friend.
I interviewed at a small company just for an internship several years back. It was an iOS position, but again, internship/jr. level. I said I wasn't an expert but wanted to learn and had spent some time developing some basic iOS apps on my own.
Guy proceeds to seriously ask me about low-level memory management, i.e. ARC (Automatic Reference Counting) vs. other methods (this was roughly 2013 or so).
I attempted to give an answer from what I knew just reading the docs, as I hadn't written complex-enough code for it to matter. Mentioned I didn't have first-hand experience using it, so that's my frame of reference.
He basically laughed and went off to tell the recruiter it wasn't worth having me finish my interview loop.
I understand for an experienced iOS engineer at the time, those would've been entirely valid questions and it'd be reasonable to expect enough time spent using them that a quality answer could be given.
But I was honest in saying I hadn't gone that far and this was for an internship.
Of course that was also when I realized that in the real world, there are small companies who tend to want FTE-level of productivity out of young engineers/interns for that pay level who aren't experienced enough to know it.
Edit: Coincidentally that same day I reached out over Twitter to the CEO of a company I admired, also in SF, and asked if I could just tour the office since I was in the area.
That CEO spent his lunch hour with me, had a good laugh about the interview story, and worked with one of his teams and recruiters to get me in the schedule to interview. Got an internship there the right way, spent two years interning, went full time for 3.5 years, and that was the beginning of my full-time career.
I have a feeling this will get me a downvote, but I grew up in a very blue collar town and the idea of paying one's dues is not crazy to me. I see a lot of people entering the tech market as if they don't have anything to prove, like their degree says it all. In any industry, you shovel some shit early on, IMO. I was a good programmer, but I got my start racking servers in a data center. I crawled under raised floor to run cable, replaced batteries, worried about cooling, and generally did a lot of work no one else wanted to do. I was a programmer already, and I think it was a waste of my ambition for $COMPANY to not give me a job writing software, but I don't mind the idea of people paying their dues, and I think I'm better for my experience. Careers aren't supposed to start with you having a big corner office. It is surprising to me how many people feel entitled enough that they truly believe they ought to start at the top.
>I don't mind the idea of people paying their dues, and I think I'm better for my experience. Careers aren't supposed to start with you having a big corner office. It is surprising to me how many people feel entitled enough that they truly believe they ought to start at the top.
he is trying to pay his dues. its an intern position. at the very low level.
As usual - it depends. FAANG internship is way more valuable than other big names and big names are much more valuable than anonymous web shop hiring 3 people.
So if they went directly for big name that isn’t exactly paying their dues.
FAANGs have massive intern support programs and their interviews aren’t usually like this. Interns are the ultimate try before you buy so for orgs with the ability they’re worth it.
That's not paying your dues. Being a software engineer forced to work as a network technician (not even a network engineer) is akin to having the junior accountant just get everyone coffee.
Maybe writing tests is paying your dues, because it often feels like a thankless job. Building UIs in a JS framework... Those could be "paying your dues", or more precise getting real world development experience.
But there's a lower limit to that "paying your dues", when it comes to educated professions.
It also sounds like an incredibly bad idea to put a junior engineer with no network technician experience in a network technician role. Have fun when your server goes down at 2am because something is fried, somewhere!
In mechanical engineering, it's considered good practice to make recently-hired engineers work as blue-collar operator in the shop for a while. When it's proposed it's even usually appreciated by the engineer as a rare opportunity to learn.
Ye you need oil and saw dust on your hands to design machines properly. In a SWE analogue running the milling machine would be ... using computers? Workshop experience is harder to come by than computer dito.
Does this have anything to with what the parent comment even described? Expecting someone to apply for an internship with extensive iOS skills is a bit of a joke.
It kind of reminds me when I got asked for an internship experience if I had any experience doing large Python 2 to 3 migrations. The job description didn't even use the word Python. (I later found out through Glassdoor that this company paid interns about the same rate as the entry rate for the H&M down the block.)
I'm not sure I understand your argument. Are you implying that in the end, I did the least amount of work to get an internship?
If so, that's awfully wrong. I still had an interview loop and all at the company I joined. All he really did was refer me to a recruiter and matched me up with a team that he knew needed an intern. I'm sure his referral meant something but it wasn't an automatic job offer at all.
Seems like an unfortunately odd leap to consider that not doing the work to get the job.
I really don’t see what you went through as “paying your dues”. Would it be normal for a doctor to start their career as a vet, and work their way up to humans? Would it be normal for a car mechanic to be asked to start on lawnmowers and work up? Not really
And being a junior programmer isn’t “having a big corner office” or “being at the top”. It’s literally the bottom of the software engineering ladder
that would be the equivalent of a developer internship i guess? they're still doing a doctor's job in residency, they're not wiping arses or manning the reception desk
I think it’s really easy for people to accidentally have a net negative impact on the productivity of a team. Especially early in their career, especially if they’re only there for a few months.
Having interns is probably still worth risking that - they bring some life and variety into an office and they’re only around for a few months anyway. But I would be leery about adding a junior engineer to my team if we’re using manual memory management and they don’t get it. You might have to obsessively code review all their stuff to make sure they don’t introduce memory bugs. Memory correctness in iOS programming probably usually doesn’t matter that much, but a bit of wariness is reasonable and understandable.
Overworked engineers might also not want to spend their time handholding an intern if its not in their KPIs to do so, and they don’t consider that to be part of their role. This is a cultural thing as much as anything else.
> Guy proceeds to seriously ask me about low-level memory management
Some internship candidates would have been able to answer those questions.
I interview a dozen or so internship candidates every year, and i see a lot of variation in what they know. They're all good students from good universities, so they've got a grounding in theoretical computer science, and they've all done some coursework projects and one or two group projects. But some have done a lot more than that. One was into competitive programming. One had built a business around automated eBay sniping. One had built a few iOS apps that were making money.
My approach is to hire anyone who has any practical experience (a group project is fine) and doesn't try to bullshit me. But i could imagine some people focusing more closely on the handful of people with deeper experience. It depends on what you want your internship programme to do.
I once, 30 minutes into what was supposed to be a 1 or 2 hour phone interview, had an engineer at Google cut me off in the middle of their standard "write code in a Google Doc" with a "oh, I have a meeting I have to run to, good work we'll get back to you."
I assume it was not, in fact, good work, as I did not progress to the next interview.
I think a phrase like "typical" would be inaccurate; possibly "common" as well. But, I think, most people who have interviewed a decent amount have at least one story like this. Cursing is another step beyond, but its not insane; many of the people on the other end simply get drafted, they don't want to be there, and in some companies even see you as a threat to their career advancement.
I had a Google research scientist telling me during an interview that they don't like their job and don't recommend it. At a different occasion, Google's VP showed up 15 minutes late, asked one question, and stopped paying attention for the rest of the interview too busy with their laptop.
I understand that these are probably outliers but I will not be reapplying soon.
I interviewed for a company that was (maybe still is?) the leader in industrial cameras. I was being vetted for a EE role by a bunch of non-EEs until I got to the one poor woman who was the only EE left in the company after they had gutted their in house development and switched to using fancy enclosures around SZ commodity cameras. I was asking probing questions and had her on the verge of tears during the interview. Glad I never got a call back from them.
It wasn't an interview but when I was first starting my engineering career I was in a little three-way meeting with my manager and the department director in a tiny break-out room presenting some automation I'd developed to save time provisioning DC infrastructure.
The director was not paying attention at all and was pecking at their iPad. iPads had just come out and every VP/director was carrying them around and chicken-pecking them during meetings.
I stopped presenting and said I would wait until they weren't busy anymore ;D Was a bit irritated as they were the entire reason we were in that room.. Luckily I had quite a bit more tenure than that director haha(and a lot of political cover).
Absolutely. It can be quite painful in the short term, but the long term benefits (both for you and that particular relationship) can be huge, especially if you're naturally averse to confrontation.
Well... There are cases when you just need to cut the interview off.
Google is purely consensus company, where one "outlier" can literally block staffing of a whole department. So if that one person was against you - you had 0 chance.
I think it depends somewhat on what the cursing at me really means - if the recruiter said something like:
"Screw you, you little shit, I can't believe I wasted my time with your worthless ass!" and hung up that would be one thing, if they said "oh damn it" and hung up that would be another, both still rude but quite different. I'm assuming of course it was probably something like the second but the phrasing makes it sound like the first.
I think cutting off an interview is fine if it's clear that it's not going to work out. It saves everyone's time. Maybe he could have been less rude about it.
Yeah this sounds more like a crazy anecdote to me. I once had a new CTO come in at a place I’d been working at for about a year and a half, and he refused to interview any candidates that weren’t Muslim (as existing staff were replaced 1 at a time). While this is extremely fucked up, I would be surprised if I could find another tech company in the state where this happened. Cursing at someone for having experience in Rust sounds…similarly absurd albeit more benign
I was surprised to learn that in Northern Ireland, you are legally required to ask candidates whether they are Catholic or Protestant. If they decline answering, you must make an educated guess and document that. The goal is to ensure you are not hiring all Catholics or all Protestants.
Northern Ireland is in a unique situation. The Troubles were horrible. I can’t imagine having to write regulations to put a society back together. I should not judge the wisdom of this approach. It is just so different from what I am used to in the U.S., that it is hard not to be confounded.
What’s interesting is that of the other developed countries, the US actually sounds the closest to this. No other country that I know of (maybe Canada?) will ask you to describe your “race” when applying to university for example
Heh. That’s true. I wouldn’t have been at all surprised if we had to ask about race. I guess each country/culture has to address its particular fault lines. Like I said, I don’t envy folks drafting laws to try to rebuild civil society.
It may sound crazy but I’ve seen something similar happen at a startup I used to work at. The founders (Muslim) very clearly preferred to hire people of similar backgrounds. All their recruiting efforts were focused on Muslims and they went so far as to hire clearly incompetent developers over much more qualified applicants simply because they were Muslim. I’m talking about hiring someone fresh out of school vs someone with years of experience simply because the new grad was Muslim. One guy on my team dared to speak up about it and was accused of being racist. He had to do cultural sensitivity training as a result.
I wonder if it is possible that the recruiter said something like "ah, damn" which would be unprofessional of course, but seems in the general range not-completely-absurd human reactions.
I just recently had someone ask me not to curse when I said “ah, damn” in relation to some trivial thing (from memory I was just expressing disappointment that a project wasn’t going ahead, or part of a project).
It’s the first time in my life I’ve ever met someone (over 10yrs old) who considered “damn” to be cursing but apparently they do exist.
It is informal speech. Some people choose to use informal speech in work environments. Others believe it to be inappropriate. I'm in the latter camp but I don't push my language preferences on others - just as I don't push my coding style. So now you've met two people, but in reality you probably are familiar with many more who are silent.
i usually say 'darn' just to be safe, unless/until everyone knows each other, etc.
and i'm still surprised when an interviewer drops an S-bomb or F-bomb or whatever.
when i moved from north (US of A) to the south, back in the day, some religious folks would cuss by saying things like 'Dah-gommit' and things like that.
I haven't gotten it from interviewers, but I have from tech recruiters. Specifically remember being cursed at for "not bothering to learn Rails yet". I did not put Rails on my resume or LinkedIn and the recruiter reached out to me, apparently without thoroughly reading anything about me.
But I have been laughed at on a phone interview before. It was for a game dev job, and I was told by the recruiter ahead of time "They just need anyone with any game dev experience at all," so I didn't spend too much time studying for the interview. I had developed and released several full games, even popular ones, but they were all 2D Flash web games.
So I was completely unprepared for 30 minutes of being grilled on 3D graphics math and console development. I answered to the best of my ability, and could have done better if I hadn't been misled by the recruiter, but no, it felt like I was being toyed with by the interviewers (kept hearing laughter multiple times after I answered).
I got a different and (equally good) job in the industry and the company that interviewed me ended up closing down about 6 months later, so it worked out for the best anyway.
I have had a very similar experience at a tech company. Was told they just wanted to have a chat (I wasn't applying for a job posting), and then suddenly it was a full-fledged interview that I wasn't prepared for. I got humiliated and was angry as hell for being misled. I still remember it to this day.
It reminds me of a recruiter I spoke to who asked me how much experience I had with "winforms". I said "None, I've never heard of that" and she couldn't believe it. She went into this tirade about how five years of experience with winforms was required for this job and how could I not know anything about it, and was I sure I didn't have at least some exposure somehow to winforms somewhere.
Very odd experience and the only time I've never had someone get angry in a context like that. I guess if you're a recruiter and recruiting for a job that lists winforms as a requirement you may think that's a super critical thing and not have any conception of the relative importance of knowing things like that.
I didn't go forward with the recruiter and I've never bothered to check what winforms are, but I assume it's some kind of library for creating GUIs in Windows and I further assume I could have been productive with it in a day or so.
Sounds more like the recruiter was frustrated and panicked that they still couldn’t find anyone suitable, and was trying to nudge you into inventing some winforms experience in order to get to the next round
> Furthermore, if you really want a C++ developer you can just expect a developer to learn C++ on the job if they have any adjacent experience with any other language.
Is this really accurate? C++ is a very different language than even Java, not to mention Python or JS. Languages have their own quirks and attributes that often matter at some point. Especially C++.
I am on a team where we are constantly building stuff with new technologies that nobody on the team has learned, so a certain extent I understand the sentiment, but we are under no impression that we are doing that good a job at it.
C++ is one of those languages where people have deep expertise. They are on standards committees, they have a high profile in the industry. But yes if you have general programming experience you can certainly pick up modern C++ and not make a complete mess of things. It’s a multi-paradigm language with lots of gotchas that take a while to learn and require a career to memorize and stay on top of. But I think if you are an average developer in, say, a functional and OO language, you can be expected to become an average C++ developer with a little effort.
Maybe... if there are other experienced C++ developers around who can show you the ropes. But C++ has enough footguns that I wouldn't want the only C++ developer on a project to be someone who just picked it up. That's just asking for trouble.
I think if you want somebody to learn the syntax of C++, and more/less understand some code, then that would work.
But many places are using C++ only because something about the problem domain requires it, often performance. Understanding C++ and cpu architectures well enough to write high performance code is a completely different beast than just understanding c++ well enough to write code.
Understanding C++ syntax is a long ways from writing C++ that's not full of memory corruptions, as others have mentioned.
So it's not just "train somebody in C++", it's "train somebody in C++ and writing memory-safe C++ and writing fast C++".
Yes and no. You can write c++ code that handles memory in a safe and consistent way. Or you can write code which silently leaks and corrupts as it goes. The language doesn’t care and unfortunately even if you do everything correctly another programmer can mess with your allocated memory and silently break everything.
It can be pretty safe, but it requires restraint and selecting a good subset of the language. There's still plenty of footguns that an inexperienced person might hit.
And footguns that an experienced person might hit. One family of such footguns is:
const auto &foo = something(args);
…
other_thing(foo);
Depending on exactly what you’re doing and what type something(args) returns, this can be entirely correct and idiomatic. In other circumstances it accesses a reference after its lifetime.
One can debate whether the const belongs there and how many &’s to use, but, unless something has changed dramatically in the last couple years (I’ve been focused on things that aren’t C++), there is no answer that is universally safe and efficient.
The reference itself is indeed valid, in the sense of existing, until it falls out of scope. But the object it references may not be, so using the reference can be UB. Consider an std::vector v with length known to be at least 1:
const auto &ref = v[0];
v.push_back(42);
cout << ref;
That works fine until push_back reallocates out of place, at which point you may start to notice that it’s actually UB.
Rust will not permit this problematic usage. GC languages tend not to offer this pattern — you can reference a boxed vector element with different semantics than the above C++ code, and you mostly can’t reference an unboxed element. C++ lets you do things like this but has little ability to statically verify correctness.
(Doing the above maneuver with a vector is a bit silly: it saves typing, and indexing a vector is extremely fast. With a map, though, indexing is not so fast, and keeping an iterator or a reference around may be a big performance win. At least if you keep an iterator around, dynamic checkers have a better chance of noticing errors.)
I think the point is just that unlike Rust there's no compiler enforcement that you only use refs in their lifetimes: you can easily accidentally cause a use after free.
Some times it can be pretty indirect: eg if the ref ends up pointing into some std container then it might need invalidated by making an otherwise unrelated change to the container.
It's not even so much that the footguns exist but that the consequence of hitting them is "undefined behavior" ie: anythign from core dump to reformatting your hard drive. Compare to Java where the consequence is one thing doesnt work right and someone has to debug it. Rarely it takes down a whole server side process but even then you get a lot of instrumentation and diagnostics to manage it and / or figure out what happened.
C++ is a nightmare language but this specific complaint is completely overblown. The compiler isn't going to format your hard drive (I know that one blog post exists - that is a deliberately constructed example).
A C++ program with UB is just buggy. Same as a java program with bugs. The program does something you don't want it to do. That's what a bug is. The compiler isn't going to maliciously introduce code that you didn't write to order pizzas.
I think there is a factor of UB that makes it have a steeper learning curve than the corresponding issues in other languages: with Java a lot of that category of bad code will throw exceptions and you'll get useful stack traces. UB often results in some seemingly nonsensical runtime state (eg something being null immediately after a null check, or a null dereference only leading to a segfault later in a place that locally has no pointers).
Compare mutating a container in a way that invalidates a live iterator: in java it's a specific exception that you can read on stack overflow, and in C++ it's just a use after free that might still appear to work correctly a random percentage of the time.
I think if you're looking to write a simple HTTP server with some API functions that talk to some RDBMS at less than 100 requests per second, yeah, C++ is pretty hygienic and safe these days.
If you need to play around with memory management strategies like non-default allocators then yeah, the knives are still very sharp and will cut you if you're not careful. This comes up a lot when writing C++ extensions for scripting languages like PHP, Python, etc and you have to interact with objects managed outside of your C++ code.
C++ these days still supports all the syntax and programming style of C++ in the 70s. You probably mean "you can program in a hygienic and safe way in C++", which is true, but also is not necessarily a feature of the language but of the programmer (just a few years ago I interacted with some theoretically senior C++ programmers who claimed mixing raw pointers with smart pointers is fine because they're senior and know what they're doing).
Ask developers to safely define a string constant that is accessible outside of that translation unit. Now do it without C++17, which many companies aren't using yet.
Things have gotten a lot better, but even these incredibly basic needs can be really tricky.
Leaving aside the hyperbolic fringe, I'd guess that what you've heard is that it's possible for a team with discipline and experience to develop in such a way that they sidestep C++'s memory pitfalls. The situation being discussed here is the exact opposite.
For example, while I'm not particularly fond of Python as an engineering language, I've never worked on a team with poor enough process that we deal with (eg) production runtime failures due to typo-ed variable names that would have been caught by the compiler. And yet I'd never claim that it's impossible for such a problem to exist, given arbitrary levels of talent composed in arbitrary teams and processes.
I can't comment on whether this holds for C++, but I've experienced it at my current position with Elixir. While it's a high level language like most programming languages I know, it's still a large paradigm shift to a purely functional language. And yet, I could get to the level where I could make useful contributions to our backend within a few days. I went through Elixir's "Getting Started" guide, and afterwards, I just learned concepts as I needed them. Yes each language has its quirks, and I guess C++ has gained quite a few of them over the years, but you can get quite far with a basic understanding of a language, and an existing code base to learn common usage patterns from as well.
normally i would agree with you but no. not for C++. having worked with C++ in the past I would not venture to say I know C++ today (it’s been a while) or have high hopes that I would just pick it up in a few weeks like any other normal language
People undervalue other people’s skills and contributions and overvalue their own skills and contributions.
I notice this more and more in hiring process. Teams expecting new member to perfect fit wrt hard skills over soft skills. Frankly, hard skills can be taught, soft skills can’t be taught and take long time to modify behavior.
As someone who studies math (one pf the hardest skills), no, sometimes skills just can’t be taught. Some people just don’t get it. Unfortunate, but that’s the way it is.
You can teach someone math who already graduated with basic science degree in much shorter time than it will take to teach a math whiz to consider opinions from someone else’s point of view.
I haven’t been able to articulate it as succinctly as you did, but this is so true and Ive used the principle to push for many hires who didn’t do so hot in their technical round.
If a person is excited about technology and is familiar with translating ideas into code, that’s really all that I’m really looking for. Writing good code, understanding OS, networking etc are things that can be looked up and learned by people who are motivated to do so… there are so many resources to learn from.
One caveat here is that for “senior” hires, the expectation is opposite: not that they write perfect idiomatic code, but they’re able to write solutions. I think the practice of less technical interviews for higher level seems somewhat paradoxical: you want your Software architects and Principal Engineers to be able to code with a degree of competence.
Yes and no. A good programmer could learn it, but it exposes concepts that python and java abstracts from the programmer.
C++ requires you to think quite a bit about memory. Modern C++ not so much. However the kind of job that requires C++ will probably require you to know some hardware / embedded which is a completely different domain than web devs and could make java / python transitions even more difficult.
You can pass everything by value, write very child-friendly C++ code, using std::map like Python dict and std::vector like Python list, and still VASTLY beat the speed of an interpreted, weakly-typed language like Python.
But nobody does that. Chances are someone on the team takes a shit about unnecessary memory copies, the code will be littered with a smattering of pass-by-reference and pass-by-pointer, there will be std::shared_ptr, std::weak_ptr, std::unique ptr everywhere, and if you're lucky some intern will have committed some C-ish C++ code that will leave you gift of memory leaks, and now all of a sudden you need everyone to understand all the nuisances of the language and how memory works.
> But nobody does that. Chances are someone on the team takes a shit about unnecessary memory copies
It’s not just performance. In any moderately complicated C++ program, you will want a function to mutate its argument, and this falls apart.
Sure, you can write in a pure functional style with immutable data structures, but I wish you luck implementing an immutable data structure with asymptotically reasonable performance without using pointers of some sort.
Unfortunately many programmers underestimate the speed at which computers can copy flat regions of memory these days and overestimate speed of code littered with pointers and indirection. Often using pointers to avoid copying a few bytes leads to worse performance.
In my experience a combination of pass-by-value with move semantics provides good code readability and almost optimal performance in most cases, so that's my default. Unless a profiler disagrees in specific cases, of course.
A map or pretty much any nontrivial data structure is not a flat region.
In any event, waiting to optimize until a profiler tells you to is a reasonable practice as long as you pay attention to scaling. It’s very easy to write, for example, a JSON parser that performs fine in small tests and has a nice small n^2 coefficient. And then someone throws in a bigger input than you tested and your game takes ten minutes to load.
> A map or pretty much any nontrivial data structure is not a flat region.
Not necessarily. A hashmap can be implemented in a way it stores both the keys and values in a flat memory region, as long as keys and values are fixed size, and such a structure is way more efficient that traditional array-of-pointers implementation, where fetching each key requires following a pointer and getting the value requires following another pointer.
Low level stuff, I happily code off the top of my head in pure PIC and AVR assemblies, is not same as C++ low level stuff.
(IMO) C++ is quickly becoming that middle ground language that is destined to be a niche language in a decade. It's not low level enough and not high level enough to give people dealing with assembly code or business logic code a reason to switch.
>A good programmer could learn it, but it exposes concepts that python and java abstracts from the programmer.
Education varies wildly, and overall in industry you will not apply 100% of your learnings. I'm sure I forgot plenty of algorthms that others use daily. Likely, others forgot plenty of low-level memory management than I use daily.
Let's not turn this into a programmer measuring contest. They are different concepts and tools done for the purpose of solving problems, not flexing IQ's. coments like this are no better than the ones you complain about.
I develop business backend servers in C++, no problems there and no hardware / embedded is required. I also happen to be familiar with electronics and do develop firmware every once in a while but I mostly use plain C for that.
That sounds like you're trying to stab yourself in the face...
The unfortunate bit is - there is a lot of people that are learning Python or TypeScript that can develop that business logic as fast as you at a fraction of the cost.
>"That sounds like you're trying to stab yourself in the face"
Sounds like you have no idea what are you talking about. It was exactly Python project I've recently completely rearchitected, rewrote and greatly improved. Client can't thank me enough as it performs hundreds of times better than the old one. And from what the client told it was developed in less time than the original Python version.
In general I use multiple languages including Python. I just do not see anything in Python that noticeably speeds up development of big and complex projects vs modern C++ ( or any other decent language for that matter ).
You just have to know what are you doing. Language is secon
Here's what I expect will happen when an average developer is "to learn C++ on the job":
The inexperienced developer will write code that is subtly wrong. The senior developers will spend more time debugging than the time would take to write the code themselves.
The new hire will effectively have negative productivity.
And when the new hire has learned enough, s/he will get a new job. The comapny will not have recouped the investment on the developer.
I've been writing C++ for like 15 years now and still need to visit Stack Overflow 500 times a day to do my job. It is not a language somebody picks up on the job.
Yes, for typical corporate development tasks which is the bulk of the tech job market. As long as they are reasonably seasoned vs what you need done and you don't throw them in to the deep end on day one. Every language has quirks and corner cases but after you've learned enough of them, the oddities don't tend to trip you up for very long. Learning the specific frameworks and business knowledge tends to be the lions share of the learning that needs to happen... takes longer but also not a big deal.
Realistically, the majority of developers spend their days doing rather mundane work with CRUD/data-munging probably being a good description for most of it (regardless of whether it's server/desktop/mobile/web) which isn't rocket science. Now if you need an expert to write a memory management system for language X on OS Y, that's a different story.
Coming from Pascal/C/C++ to Java in early 00's I really hate it the style of non-existing global variables. To use global variables I had to declare another class? Such heresy!! To this day I still hate Java, personally, but when it comes to a real challenge I really don't care the programming language. Programming languages are tools, each fits better for a particular problem and my clients pay me to solve their problems, not to bitch why one language is better than other.
That ain't happening with C++ unless you have a very good understanding of the bazillion things C++ lets you control. Just deciphering the STL errors when you compile is a headache. C++ gives you way too much rope to hang yourself with, compared to even languages like C, which is already a tough thing for someone who's never worked with a language where there is no garbage collection and typing is not strict.
If you are at a company with highly automated style checking, strong developer education resources, and a culture of using sanitizers all the time - you can let people learn C++ on the job.
But if you are just writing code with code review from other team members as your only option? Oof. C++ is a barrel of knives. Incredibly safe looking code can actually be filled with horrible horrible nightmare bugs.
The problem with C++ is that every firm has their own flavour of C++ that they use.
Someone experienced in C++ will be able to pick it up a lot faster than someone transitioning from the Java world, but there's always going to be a fair learning curve for a new hire.
I've probably spent ~1000 hours writing C++ in my life (admittedly, years ago) and objectively speaking I wouldn't hire myself even as a junior C++ dev.
Yes, tech hiring is entirely broken. I’ve had so many interviews and have been turned down a lot. It sucks but you can’t take it personal. You have to realize interviewers are dealing with time shortages, incomplete information and therefore looking for cues you’re a good fit. Most of those boil down to personality.
Whenever I start interviewing, it takes a few fails before I finally realize: my talents are not (at all) what interviewers care about. Talent is just the icing on the cake. Once I remember that, I focus on being personable and start getting multiple offers. It’s always been like that.
I literally can’t relate to this on any level. I’m an HM at a company that pays on the order of a FANG and at best matches one of these credentialist barriers and yet we can’t come close to hiring targets on devs.
I don’t get how people can see the plethora of individuals under 10yrs experience in SWE and other tech roles in SV/NYC/SEA with incomes of $250-600k/yr and think this happens without a “shortage” of talent.
Shortage in quotes because it’s hard to define in context of supply/demand but it’s clearly the case that devs have a lot of bargaining power.
I've mentioned this on HN before, but I have 10+ years experience, a BS in CS from a top 10 school, worked as SWE at Google for over 3 years, I've done 100+ leetcode questions, studied grokking the systems interview/designing data intensive applications, I live in the Bay Area, and I've _still_ failed 90% of my onsites last few years at the top tech companies (Stripe, Lyft, AirBnB, Square, Dropbox, etc).
Reasons for failure vary, you don't get much feedback but when I've gotten it it's been distributed across coding/systems/behavioral.
I've also been rejected at resume round by companies like Instacart and Coinbase.
The interview bar has gotten insanely high it seems. And I left Google way back without anything lined up assuming in this job market I could waltz into a good job with some modest prep but that has not been the case.
I objectively have top credentials, and I find tech interviewing an absolute nightmare. The standards have gone through the roof and one slip up and you get dinged. And the system is way more arbitrary and subjective than anyone admits.
Now, this isn't a woe-is-me story becasue to your point, there's a lot of companies paying top dollar and I have a decently paid job. Furthermore, I'm not failing interviews at random startups but as senior engineer at top companies that would probably offer $400k if they made an offer. They have the right to be extremely picky and subjective, but let's at least admit that they _are_ extremely picky and subjective.
The "I'm a HM and can't hit dev targets", reeks of ignorance as to your own process. I wonder if you do things like tell your interviewers "a false negative is better than a false positive" ? Or let one interviewer use some arbitrary criteria to dock a candidate and then pass on them because of one bad score? Because you probably do lack perspective on how many good devs your company is rejecting if you're only sitting on the HM chair and not seeing what it feels like to go through these rounds as an IC SWE.
Interviewing is a skill of itself for sure. Random offer, if you want to get some honest no-consequence feedback dm me and we’ll do a mock interview. Have hired a lot of people and want to pay it forward for all the people o have rejected not because they err bad but because I was bad at interviewing. Send me a message.
This seems like the most relevant anecdote in this thread. When I talk to friends about how they interview, it’s never about skills. Some say they’re not actually hiring, but they interview experts for free advice. If they are desperate, they hire for exact experience. I don’t know who out there is hiring new grads at giant salaries for Leetcode skills, but I think they’re mostly looking for impressionable followers.
> The interview bar has gotten insanely high it seems.
Software developers are starting to commonly earn doctor-like salaries. Doctors typically burn ~12-15 years between school and residency before they start getting paid serious salaries.
A top 20%-30% software developer can be earning $150k in their mid to late 20s, outside of the Bay Area.
It's no surprise that the hurdles are going up for such high compensation. Software devs in the US as a mass employment field (1.5m people) are the best paid large group of people in world history. Combined wages (not total compensation, that's far higher) for the 1.5 million software devs in the US is in the neighborhood of $215 to $250 billion per year. It's doubtful anything like this concentration of huge globally important industry dominance + very high pay will ever been seen again anywhere else in the world, it's an outlier economically to put it mildly. Enjoy it while it lasts.
I agree to the extent that it might not last and "make hay while the sun shines."
At the same time, I disagree it's that unprecedented. There's about as many lawyers as software developers and the compensation distribution is surprisingly similar (including some bimodal aspects). Yeah they put in 3 years and took some debt but it's not that significant big picture, many CS students get an MS.
There's a lot of doctors in my family. It used to be a gold mine field and now it's much less so, as hospitals have a lot more power over the doctors than they used to.
If you want a really good bang for your buck, look at salaries for nurses who get some specialization like CRNAs, who can make similar money to SWEs, with about 2 years extra school work.
I mostly agree we're in a golden age of software engineering compensation and as I mentioned in my first post, these companies have a right to be picky. Still, to some extent I think engineers of all stripes were relatively underpaid relatively to some other white collar professions historically and its just been catching up a bit.
Employees don't seem to have enough bargaining power to meaningfully control working conditions, though. Maybe these are worth a ton of money to the company, or such desires are an outlier. But here is my experience:
I'm a professor of computer science, and frequently get recruiters trying to get me to jump ship to industry. I'm open to it in principle. I'm reasonably happy in my job, but there are certainly things I don't like about academia, and the pay is not industry-level. But it's generally a rewarding job, and has various perks, like private offices and considerable control over your own schedule.
A question I ask recruiters: I have a private office... could you match that? So far, the answer has always been no. They can double or occasionally triple my salary, but they can't offer me a private office. I am not sure what to make of that. They are willing to offer me $100k+ over my current salary, but are absolutely unable to offer me an office with a door.
The hiring managers don't have that power. Not sure if you have done an interview loop but I assume that as a tenure track/tenured professor you're going to be L6+ individual contributor in a research group. In that interview loop you're probably going to have a decent amount of face time with a director level or VP. IMO if you're actually interested in making the jump the right play is to get the job, and then negotiate the office with the director/vp that you'd be reporting to, they will 99% of the time not let office access be something that stops them from hiring a staff+ engineer. Feel free to ping me directly if you want to ask more questions.
I've had similar experiences with desks, even though desks are a much easier problem to solve than 4 walls that make an office. $200 at IKEA would do it. And yet it's still an unsolvable problem to many companies. Desks have been the main reason I quit two of my past ten jobs.
One was at a euro stoxx 50 telco. They had a desk with a single plate that 10 people sat at. I had to sit with the project team I was working with who, unfortunately, weren't all the same height. But the plate could only be adjusted to one height for everyone which was way too low for me. Every day at the office, it felt like working at a coffee table and my back and knees hurt like crazy. I was fighting the corporate system for half a year, including making a fool of myself in front of the global director of human resources and company medical officer. This was ultimately unsuccessful as I was a freelancer, not an employee, and earned me the scorn of my direct manager. The whole experience was so undignified and humiliating that it was ultimately one of the main reasons I quit that gig. After all I was just trying not to have to endure physical pain.
The other occasion was at a well-known Wall Street investment bank back in 2010. They put the computers in the space under the desk that should normally be legroom and every day at the office felt like a long haul flight in economy class.
My boss's boss, a partner at that firm, privately owned a floor in a highrise residential building in Tribeca. Yet, during the work week, he still basically never got to see daylight. Our business unit wasn't high enough in status to be able to swing a work area on the outside of the building that had daylight. He had an office but still no privacy. One of the walls of his office, facing his underlings' open plan space, was made of glass. Glass walls is something that these firms do these days even for very high-ranking executives to create witnesses in cases of allegations around what may or may not be happening behind those walls between colleagues of opposite gender (or preempt those kinds of goings-on or allegations).
> They can double or occasionally triple my salary, but they can't offer me a private office.
You might have more luck if instead you asked about working remotely full-time. It's not the same if you want to go into an office, but companies are seriously thinking about their post-covid office plans.
True, that's an interesting possibility with the current trend towards remote work. With enough of a pay raise, I could solve the private office problem by just renting the office myself out-of-pocket...
I think the author is talking about pretty large, well-known companies (e.g., FAANG -- see his first point). Many people applying to these well-known companies are auto-filtered by resume software, which artificially decreases supply.
Small and mid-size companies have a different problem: people haven't heard of them and don't know to apply. My company is in this situation. We have a good culture, I think, and pay very well but people don't know about us or don't think of us as a "tech" company, even though we do quite a bit of innovative software development.
Hiring at these companies is very different from the bad examples described here, except for the indexing on degrees (if you don't have extensive experience you're not getting hired without a degree). They don't test trivia and don't typically look for "X years experience with Y framework". I remember seeing that in lots of smaller, lower paying companies' job postings on websites like Indeed but I've never seen that at a big bay area tech company unless it's something sufficiently broad like "infrastructure" or "frontend"
The difference is that big tech companies aren't meant to be applied to over the internet. Seriously, it's like throwing your resume into a black hole. Referrals are the same way, honestly. The only good way to get hired is to get a recruiter to message you on Linkedin. I have never got an interview at these companies from applying on their websites and have made it to the first round of interviews every time if I was contacted by a recruiter.
And because of that, it should be no surprise that nobody is scouring the internet to find your company and send in an application on your company's website. Everybody has been conditioned for that to essentially not work. Even though it's expensive you really should be paying third or even first party recruiters.
Except none of his points apply to FAANG companies either.
>A bad interview is when you ask them the definition of some specific thing in some specific framework like “Tell me what a closure in javascript is.” then treat them like they’re stupid if they don’t know.
FAANG companies do not interview like this. I've done interviews with most of them twice in the last 5 years and all questions are the typical algo stuff.
Then his whole rant about credentials... I am a self-taught dev with no degree, none of my interviewers ever cared about that. Every interview is about whether or not you can solve the algo question.
Is this auto filtering happening at the senior level for FAANG? Amazon keeps reaching out to me (a junior who already failed one of their interviews) on LinkedIn. Google did as well at one point.
If I am somehow worth personal attention as a not terribly impressively pedigreed and inexperienced developer, are they really dumping seniors through crappy filtering software and missing them there?
The stakes are lower. As a CTO (hypothetically) I get to hire 4 junior devs, 2 senior, and 1 architect.
Hire the wrong junior? No biggy, he'll be less effecient but we may yet turn him around. Anyway, I get three more tries. Anyway, he'll leave after 2 years. They always do.
Hire the wrong architect? I'm stuck with him, for a very long time. Moreover, I now have the wrong guy for a high-impact job. And one that is very visible.
So you betcha I'm going to be much more picky, the more senior the job becomes.
> I think the author is talking about pretty large, well-known companies (e.g., FAANG -- see his first point).
Except almost nothing outside of some amount of resume filtering fits his points. Seriously, go to levels.fyi and look at the pay of the FANGs (ex. Amazon). You think his bad pay point is a problem for them?
Personally, I’d happily accept being a lifeless drone, at least for a few years. Save the extra income and invest it. Reap the dividends.
Having said that, I don’t know how bad those roles actually are. Obviously, it’s not worth it if it affects your mental health… and unfortunately yeah, that is an issue working in this field.
The difference between both taxes and the "next in line" isn't large enough.
Hedge funds pay as much as Google/Facebook, but work and life balance at SV companies is much better.
Compare my two offers from a few years ago - well known hedge fund in CT vs a food delivery tech company.
Well known hedge fund paid $250k+50k bonus for expected minimum 50hour weeks and 20 days of vacation time.
Food delivery company offered $170k+200k in stock over 4 years for 6 hour work days in a relaxed environment and unlimited PTO.
It's at the point that it's not worth the money. Sure it's about $3k extra monthly income.... and if you're not burdened with student debt, it's not a game changer.
They are the minority with a VERY small staff, compared to most others. (Also HRT engineers work a lot, not leasurely 40 hours per week)
Pointing to extreme outliers is not giving your opinion much credence. Because I can point to some people who work in crypto, that earn $600k+ without breaking a sweat - in Singapore with Singaporean taxes(which blows HRT salaries with US taxes out of the water)
As a perfectly competent dev having immense difficulty getting anyone to consider me for any position, I cannot see this as anything other than false.
I have a job now (and by all accounts my employer is really happy with me), but the interview gauntlet I had to run to get here was absolutely ridiculous.
Then it seems like your replying to me with your experience not matching isn’t very reasonable, eh? I’m being very explicit about the US SV/NYC/SEA experience.
Well that would be the expected outcome, no? The author claims a problem exists in hiring and sets out articulate what that problem is. If the problem exists, then as a hiring manager, it's a good bet that you are, at some level, involved with that problem. For your stance/perspective to lie anywhere from a harsh opposing view to merely unable to unable to endorse the author's perspective ("what is water?") would be unsurprising.
(Note that this is true just as a matter of logical consistency and is not particular in any way to hiring itself; try replacing "hiring" here with "skub" and it's still true.)
If you accept non-US people, tell me what company you work for so I can send my resume.
Because all the issues the guy pointed out I am on receiving end of them right now.
And although I've been in leadership roles before and started programming when I was 6 years old (my dad taught me), I started lately to see if sending my applications to junior developer roles will get me any replies (people don't even tell me they got my application, except the occasional robot).
I'm pseudonymous for a reason but here's a list of companies, none of which I am employed at, that have similar pay and issues with staffing:
Uber, Doordash, Asana, AirBnB, Pinterest, LinkedIn and literally so many more. Especially if you are willing to accept mature but not yet liquid equity and then there's Stripe, Airtable, Robinhood and so many more.
Post your resume. Tried to go to your personal website but it wouldn't load.
I’ve interviewed with many of those listed. They’re not struggling for talent. They all have a very high hiring bar. I’ve seen them reject many people (besides myself) on trivia and whether or not you studied the right set of problems on LC.
For instance, could you regurgitate topological sort out in less than 20 minutes to solve a problem? You forgot the implementation but generally know what it’s used for? Failure. You’re a failure. Even if you know how to solve the problems but get tripped up on some simple parts of the algorithm because you haven’t really studied or used it in years, failure. Same with system design type interviews and other stuff.
The bar is very high for people who will never use any of that work. It’s hazing.
From the hiring manager perspective it’s a numbers game of time and risk mitigation. Firing people sucks; managing people out sucks. Not firing people that should be fired sucks. Unless you’re in a big company with centralized hiring and onboarding, having headcount that needs an expensive ramp up period sucks.
If you’ve done a lot of different things because you’re smart and creative, maybe I’ll have to spend more time making sure you’re motivated (so you’d have to be worth the extra time cost). It’s also common to see people with an ungrounded perception of their abilities, and I often see breadth-heavy people suffer from an inflated sense of their own abilities due to lots of small scale, diverse wins.
Most people don’t understand how valuable a hard worker who will agreeably take orders and deliver consistent results is; magnitude doesn’t even matter that much. Unless you’re single handedly driving significant business metrics (e.g., directly saving millions of dollars), from my perspective, my job success is tied to predicting your output. If I succeed, I get to expand the teams or build new ones. If a product release is late or buggy, it’s also wasting tons of other teams’ time or damaging customer relationships besides pushing the eng roadmap back.
We reject a bunch of faang people for having experience we don’t find valuable. If you work at a big tech company, but don’t have an impactful role, you’re potentially not going to succeed in a small startup at the level you’re demanding.
Finally, one bad hire can ruin a team (i.e., one bad hire converts others into bad hires). “Bad” is subjective and can refer to different things. At the end of the day, it’s my job to define it and make sure we’re avoiding it. You can ask about this in an initial phone screen, or in a follow up conversation because it’s not secret, but I can’t talk to you about it after we reject you due to lability.
I was a professional game designer (still a designer, but more a hobbyist now) with extensive (>10 years) game, mobile, full stack web and enterprise development experience, and all of that is current, as I'm developing games, including mobile games, in my spare time. It's very possible to do both.
Because the shortage is self induced. First of all you mentioned only super expensive locations. I would need 600k in SV to equal the mediocrity I enjoy in Texas. So while that sounds like an insanely huge number it doesn’t really say anything.
Second, at this point in my career developers at large companies aren’t expected to write code. Save that for startups. Instead developers are expected to debug things and string tools together like a homemade necklace. If you are an established company and want somebody to write original code you have a lot extra work to do to ensure a good cultural fit.
Me neither. Every single point the author makes does not match my (or any other dev I know) experience. The only explanation is the guy is in a really bad tech market, in which case, move.
If your place pays FANG ish and allows full remote (as Facebook does) feel free to hit me up. Preparing final round at facebook but it's a crapshoot (philosophecles0@gmail.com)
Grad students and postdocs seem like a fairly untapped source for tech recruiting, especially outside of the CS department. Physics, neuroscience, econ, biology, and many other fields now involve lots of programming and data analysis, sometimes under demanding conditions (real-time or huge, noisy data sets). Many of the people are smart and highly-motivated, but making a tenth of the numbers you quoted (and with rubbish job security to boot). It should be like shooting fish in a barrel.
And yet.... they don't seem to be on many company's radars. I'm the only one in my group who is ever contacted by recruiters, and it's an undergrad CS degree.
Yes, you'll have to screen to figure who tweaks "the script that gives the numbers" and who's more like a developer. Recruiters might need to put in a little legwork to figure out how different kinds of researchers map onto open reqs. You might want to somehow prep non-traditional candidates for a developer interview, or figure out an on-boarding track. But you can afford a whole heck of a lot of that if a $250k/year job is sitting open.
From talking with my PhD and MS friends, it's mainly about time. PhDs work around 40-60 hours a week. Full time MS students are juggling courses, research, and part time work, also around 40 hours a week. That usually leaves little time and energy to apply for jobs and practice interviewing.
As a terminal MS student, most of the interviews and offers I've gotten were from professor recommendations to their industry colleagues. I researched computational linguistics and dynamical systems in my undergrad, and in grad school I researched HPC and distributed systems. I still interview poorly because I don't invest enough time practicing/applying compared to reading papers or doing grad student grunt work. On paper, having an MS can also be a negative signal.
Paying that much for a tech worker doesn't mean there is a shortage of them, it means FANG companies are gambling on "rockstars" to try get an edge.
Flood the market with very good but not exceptional workers, and the top salaries won't change much.
Flood the market with exceptional workers and it probably won't change much either, FANG will just be even more selective with their top salaries.
Top devs have a lot of bargaining power not because companies need some "X amount" of development work done but can't find anybody who will do it. They have bargaining power because those companies are competing against one another and they're hoping the next billion dollar idea will come from one of _their_ employees first.
If you aren't playing this kind of roulette, I don't understand why you would try to compete in the same job markets. You can get developers for far less. And yes that may mean moving elsewhere, SV is obviously heavily selecting for such developers (people who can get those salaries will tend to move there, those who can't will tend to be pushed out).
If you are playing in that space but you just can't afford to pay for its inputs then it doesn't automatically mean those inputs are in a state of shortage, sometimes it just means your business does not create enough value to to pay for said inputs. This is the market's way of telling you to fold. Capitalism is a harsh mistress.
> If you aren't playing this kind of roulette, I don't understand why you would try to compete in the same job markets.
Ever since Blockbuster failed dramatically, large brick and mortar company execs are worried that SV will take their market. And, for good reasons too, I'd say. Software is eating the world etc.
Another broken thing is LeetCode style of programming exercises asked for a job asking 15+ yrs of experience. Not saying we do not solve complex stuff on a day to day basis, but foundational problems are already solved & we have patterns/solutions/libraries available. We do not do DFS/BFS on a day to day. We do have Stackoverflow, Google to figure things out.
FAANG companies - filtering candidates by asking tough LeetCode questions, which is understandable. But what is with Startups? If someone can solve hard LeetCode problems why would they join Startups? They will join FAANG. Startups are blindly copying FAANG before becoming FAANG themselves.
> FAANG companies - filtering candidates by asking tough LeetCode questions, which is understandable
Not sure that I agree it is understandable but I definitely am glad they make this bad decision. I dodged the bullet on interviewing with a FAANG and failing on one question (the recruiter told me it was the answer on a single question that kept me from getting an offer) after doing an onsite in SV.
I did not know what I was worth and would've felt compelled to accept an offer that would've been 30-50% less than I could command at the time and I would've had to move somewhere with 4-5x the cost of a home than where I live now. I didn't get that offer, and after a little bit more time I got an offer somewhere where I earn 2-3x as much as I originally said I was worth to the FAANG (based on places like glassdoor, etc.).
The culture is better, I can work wherever and whenever I want, and would have to go out of my way to not make impactful decisions that go to prod for millions of customers multiple times a week. It'd take 2-4x my base salary to get me to walk, which I could possibly command, but I don't feel any desire to look because I didn't fall into the FAANG trap and enter a cycle of pretending consultants selling quiz books know what software engineering is and jumping to be able to survive in SV.
I messed up something on a whiteboard with an apathetic interviewer about a special tree inversion or something - who gives a shit - and I have been extremely happy that happened every day since.
I don't like leetcode either, beyond some very simple problems to demonstrate basic proficiency[0], but if you're going to force poor junior developers to do them, it's only fair that seniors suffer the same process. If it's only an expectation for junior developers then it's just an advanced form of hazing.
[0] on the level of "here's a list of strings that are names in Lastname, Firstname format, turn them into a list of Firstname Lastname", or something dead simple that's designed to definitively rule candidates out
> ...this moronic interview practice would alienate an obvious asset
> The lack of faith in our fellow humans is disgusting.
This kind of catastrophizing and dismissive language makes me want to ignore everything the author says. If you think being evaluated in an interview setting is somehow unfair, I think you should consider whether your attitude is the problem. If you are actually good at leetcode and continue to fail onsites, you're almost certainly giving off red flags in some other behavioral category.
At my (FAANG-ish but not in the acronym) company, many of the candidates we fail are leetcode gurus who have a negative vibe. Maybe they're technically pretty good, but they have an ego on the level of Linus Torvalds. Or maybe they trash talk their current team or boss, or avoid giving straight answers to simple questions about their background. Or they've got 8 years of experience but can't talk about anything they did to grow the younger people on their team. Maybe they launch into brain-dumping a solution they memorized from a practice problem without explaining their approach. Or perhaps they are aggressive and stubborn when given corrective hints.
As a dev who will be on the same team as the candidate in the event an offer is made, my primary incentive is to vote no on any assholes I cross paths with in the interview. I don't give a shit if my no-asshole standard means the company needs to spend another 3 months and $100k on recruiting costs to get an equivalently skilled non-asshole candidate for my team. I consider those costs part of MY total comp.
Beyond the junior level, success usually means working well with others and bringing a growth mindset for yourself and others to each project. Mentoring others. Learning and teaching. Being a steward and doing unglamorous work for code health. Slinging feature code is a minor part of it in big companies, so you need to figure out how to signal all these other forms of value in the interview. And avoid sending out red flags.
For me, leetcoding people is basically asshole behavior, on the part of the company. The whole idea of "let's have a tournment where we have candidates grind on arbitrary problems for months as a part of preparation, mhwahaha (evil laughter)" sounds like something out of Donald Trump's playbook. No wonder it tends to select for (often, money-driven) assholes who see it as par for the course, while many mature and reasonable people are put off by it and never even bother to apply.
I feel like unless there is an alternative and the labor pool is large enough companies are not incentivized to look at other ways of evaluating engineers.
I’m glad that there is a “shortage” of engineers. Likely this isn’t a problem that can be solved anytime soon. The past 2 decades were a brief time when FAANGs could provide a ton of benefits (both financial and non financial, such as eg dev tools) which attracted hordes of people to them. They successfully shaped the industry and now most tech firms are expected to provide great benefits. The number of startups and unicorns is large enough to stem the flood of engineers that they used to get before, and now they will be forced to use different strategies.
Another article with content that I agree with (high level points) and at the same time disagree with (reasons supporting said points).
The industry is rife with credentialism--but it's more due to the extremely self-centered approach developers use. I don't mean self-centered as a colloquialism for "arrogant," I mean it as in they tend to hire people who resemble themselves (i.e. their skillsets) rather than who is best for the job. And the credentialism changes in different regions/tiers of tech companies. That's why FAANG tend to target elite private school grads, and why line-of-business shops tend to target Programmer/Analyst III types.
There are gatekeeping algorithms in resume filters that lead to a sort of hivemind in the community. On the other hand, a ratio of 5:10,000 could just as likely indicate a poorly presented resume as bad algorithms.
Interview questions are problematic. The author has a big miss on the rest, though. Asking a person to implement Japanese Go (or anything, really, for which it is applicable) with flood-fill is exactly the same as asking them what a closure in Java is. It's just a pig with lipstick on. And that is a problem, of course. And completely omitted: the criteria that establish just what progress toward a solution counts as acceptable at a given level.
Education is inaccessible, probably the only point of the author's I can't really quibble with too much. Companies are being exceptionally short-sighted here, and doing themselves a disservice.
Can't argue with the last bit about pay and benefits, either, really. It gets better the higher tier of company one goes to, but even at FAANG engineers are undercompensated (though arguably perhaps not suffering from poor benefits).
Not enough full stack developers with 10 years of experience willing to work for 75k, “possible equity”, and catered lunches on a “fast-paced high-growth” project that just completed a series A. (actually saw this description)
I think "developer shortage" depends on your expectations of developer skills. I currently recruit a lot for several different positions and there is no shortage of applications.
But 50% can't do FizzBuzz and many do not fit into our environment of a small team where we do not need (can't use) specialists (yet).
If you only want to recruit from the "best 20%" [1], you can only recruit the best 20% of the people who apply to your job offerings, which is different from the best 20% of the market - most founders I know want to recruit the best 20% of the market though and fail.
I think everyone who's complaining about how the developer shortage is fake should spend some time sitting on the other side of the interview table. Author's faith in people's innate goodness won't last beyond the 3rd interview/screen. I've been on both sides of bad interviews: sometimes it's a mismatch, or the interviewee is having a bad day, but sometimes, the interviewee is just bad.
Filtering out bad candidates are the best outcome, the absolute worst time-sink for everyone involved is getting a bad hire. In a past life, I joined an organization, and my cohort included a bonafide conman with no prior experience, or requisite skill. The man could talk himself into (or out of) anything. It took a surprisingly long time for the team to realize he was getting other team members to do his work for him in the guise of "needing help" (several weeks).
I doubt he's still in industry, but my guess was it provided good, "easy" money while he was laying low for previous misdeeds. When I said "bonafide conman" - I meant he was using a fake identity and was quite literally on the run. The police got in touch with the org not too long afterwards asking after him - he was re-using an alias the police knew, and his employment/background-check likely popped him right back onto their radar. The police had wanted to set up a sting operation, but found no takers on staff - his alleged past crimes were linked to organized crime, so I can't say if the fears were overblown.
Yes, this is what he's really missing. I think he has a lot of good points (but not all--sorry, but while you can get the basics of a new language quickly the main time cost is learning the library) but he utterly overlooks all the trash.
The companies doing the hiring see a lot of trash applying and take all sorts of steps to filter it out. The trash keeps applying everywhere, the companies try even harder to filter it. The companies see the filters as saving them time on interviewing trash, they don't see the good ones being filtered out.
I'd like to see some sort of meaningful certification of developer skills, but it would be awfully hard to do without being subject to being gamed.
At a previous company we asked candidates to calculate the median value given an array of numbers. We also gave them test cases that covered 100% of what we wanted.
23% of applicants could not produce a working solution.
It might be 40% or 55%, I don't keep records [1], but I'm 100% sure it's not exactly 50%.
Numbers are rarely shared, so I have a lot of questions, what is your ration when recruiting? Lower? Below 20%? If you do not use FizzBuzz what to you do use then? Fixing bugs? Homework project (do you find it on StackOverflow afterwards?)? What is the ratio there? Or don't you check for coding skills? (One of the old blog posts talks about 90%).
The ratio depends on where your job ads are I assume. If your ad is on some remote only website, you get more applicants but also a higher ratio.
If you only work with recruiting agencies, from my experience the ratio is lower, but you pay EUR 20k commission.
[1] Sadly I can't get our HR software to track these ratios over channels.
How can someone possibly call themselves a programmer (let alone a developer applying for a job) when they can't even pseudo something like fizzbuzz ? How can they use any API, tool or even copy code from SO without knowing how to write a foreach and a conditional inside?
From some developers I've worked with in the past, they ask their colleagues a lot, try cut & paste until it works and ask detailed questions on StackOverflow or similar sites.
The bigger the team the longer they can stay with the company until they are made to leave. In some very large companies I've worked with, with large teams, they stay forever even when colleagues are unhappy with their performance. In those companies it is often more important to have all positions closed than have (good) developers in every position.
When looking at CVs - not scientifically - some stay only some months with a company or stayed for a long time with a large enterprise.
At a previous role many years ago, I was part of the hiring process for someone to replace me. (moving to a new job soon) I had 3 years of Java experience, and 4 years of coding experience in general. So pretty junior role. And we thought it would be easy to get someone.
This one guy we interviewed had 15 years of C# experience. I thought great, he might not know Java, but he can pick it up quickly with that much experience. I was a little concerned that someone this senior was applying for such a junior role, but so far he was much better than any of the other candidates.
Just as a sanity check, I asked him to write something similar to fizzbuzz. It was actually even easier. He couldn't do it. And I thought that maybe he thought I expected him to do it in Java, so I said he can do it in C#, pseudo code or any language he likes.
He couldn't even write a single line of code. I ended the interview right there.
I don't know how deluded this guy was. Or if his CV was made up. Or if he just conned his way into his previous roles. There are countless people like this. It is surprising what you'll find out there.
> How can someone possibly call themselves a programmer… when they can't even pseudo something like fizzbuzz?
Agreed. On the other hand, I can count the number of times I've used modulo professionally on one hand, so I wouldn't be too shocked to encounter a competent programmer who had't heard of it.
If I do FizzBuzz people can invent an API function rest_of_division() if needed, or can_be_divided_by(). FizzBuzz (or something more complex) for me is a coding check, not an API/syntax knowledge test.
I honestly don't think pay is an issue in tech, but most of the others the author brings up are valid points. The crux of the issue in my opinion is the fact that NO ONE HIRES JUNIOR DEVELOPERS.
Companies don't want to take on the burden of training junior devs and then complain when there aren't enough senior devs to go around. Obviously it makes sense from a business perspective, but taking a step back, training junior talent in this field should be a top priority for everyone.
When developers change jobs after about 2 years at a company, what's the incentive for any individual company to take on the burden of training junior talent? By the time they've got the experience to contribute on their own, they're gone.
I really don't understand this idea that is often repeated. You take someone who can code in a specific language and maybe a specific framework, and it takes them years to become useful?
Are people understating the capabilities of young devs or are they all really slow? Another possibility is that what they're learning in those two years are company-specific, in which case being senior wouldn't change much.
Totally agree and I thought about mentioning this in my comment. Yeah, part of the blame for this problem is on us as developers for creating a culture that encourages constant company hopping.
> on us as developers for creating a culture that encourages constant company hopping
lol. It's not like _us developers_ like the stress of interviewing every 2years. It's just that we know that we're undervalued and underpaid and have the luxury to prepare for job hopping.
It's a matter of _fair_ talent retention, not of _developer encouraging a culture of company hopping_ (???). Or give me example to change my mind, maybe I've not understood what you meant by that.
That culture goes both ways, and more on the companies in my opinion. Why would anyone stay more than a couple years when there's no path for advancement and raises don't remotely keep up with the market?
This can be flipped around too. Companies have tools to incentivize people to stick around too: vesting schedules, accrued leave, even regular cash-money raises. Why don't they use them?
Is there a book about transitioning from junior to senior? I'm at a company which has no more senior devs, so am looking at alternatives for my growth.
Obviously it is not a perfect substitute, but the senior is not likely to be replaced soon.
I've always found the focus on 'languages' in hiring to be a bit odd, and perhaps a hangover from olden times.
Any programmer with enough experience can become competent in any programming dialect fairly quickly. But it's the level of knowledge of specific frameworks relevant to projects that is what we really should be a measure of competence.
Having gone through the job hunting process recently i did find this a bit frustrating.
Ok, you want a 'JavaScript' developer... Thats like walking into a restaurant and saying 'I'll have some food please'. At least some places made the distinction of throwing in React or Vue or Angular somewhere in the posting. Sometimes all three!
What does it mean to have X years experience in node ? I use npm all the time, does that count ? I assume they mean the express framework or it's cousins, but almost no job listing mentioning node spelled that out.
Same applies to Java - probably the most widely varied language in terms of use cases and contexts. I've built some web stuff in Spring and Hibernate but I know nothing about its use in embedded systems.
While I believe this is true for most “high level languages” (JS, TS, Java, Python etc.) I think when you’re doing low level languages like Rust and C/C++ you really need to hire for those languages
The article doesn't mention the #1 problem with tech hiring: leetcode. Some advice for recruiters: try starting your emails with "NO LEETCODE" in the subject line and watch your response rate from senior experienced engineers skyrocket! There is an artificial "shortage" caused by this barrier.
The last place I interviewed at used leet code as a filtered. The code problems were fun and challenging. I score a 850 out of 900 points. I failed the next round of interviewing after mentioning something about enjoying writing original code, software shaves off stability concerns and tech debt the more portable it becomes, and seniors aren’t in a position to force juniors away from deliberately doing foolish things.
There are also a lot of engineers out there with 1 year of experience x 10 (or even 20 times), or even 20 years of experience with some narrow niche technology that no longer applies - but want to be paid like they have been keeping on top of things and learning broadly for 20 years.
A solid experienced engineer is worth their weight in gold. A lot of folks consider themselves solid experienced engineers who couldn't program a hello world in any modern computing environment. This is quite unfortunate, and more chaff to sort through.
Not defending leetcode. At least it shows someone is trying?
I’m not one to do the boss’s work for them, but you’re observations aren’t wrong. Your expectations are. Personally, I am thankful to be young, single, and have a lot of free time to keep up with things myself. But I have no interest in the society you seem to desire. This business of expecting constant self-education from workers alienated from the product of their labor or any reason to appreciate the daily grind they’re tasked with is asking for a spiraling mess of societal consequences that I am starkly against. I don’t know any simple solutions. I’m afraid socialists might be right.
It doesn’t have much to do with me frankly. And I’ve seen this in every society I’ve been exposed to, from India, Japan, Switzerland, Bulgaria, Germany, France, UK, you name it.
If you aren’t able to do the job (defined by your peers and the market), you either don’t get paid, or you have to force the market to pay you or change the job, despite not doing the original job (often through legal threats/strikes). It’s a market protectionism vs market need thing.
We seem to be advocating here that the best solution (software, market) should win, and that’s what I’ve seen in the global marketplace where legal threats like strikes generally have low impact.
What I’ve seen in other areas where the legal situation allows more leverage from labor is happier but fewer and lower paid labor, in often a much smaller market. Essentially a ‘I got mine’ type setup where incumbents get good slots and it’s super hard to get into once established because the pie overall is smaller and guarded. It screws over the newcomers and unestablished in favor of the incumbents.
China has started to export some really amazing home grown tech (including software) in some verticals, and if you think they give a rats ass about EU, US, etc. programmers - well, they don’t. Just like French don’t really care about Japanese labor conditions.
So we either wall off that software (often to everyone else’s detriment - those would be good products for less cost otherwise for people to use) to protect the local labor/market conditions and cause distortions elsewhere, or.... keep up? Japan is notorious for the protections it has, and is terrible software wise almost everywhere. Pretty solidly stuck in the late 80’s when they were the newcomers and were actually innovating.
And if we aren’t even trying to keep up, well - that just means the people who are will win/define the end state won’t it?
It’s the harsh reality of the real world. EU has been going the way of protectionism for a long time, which is great from a ‘retirement community’ type sense, but there is a reason there aren’t many cutting edge tech firms originating there. It’s pretty clear from the constant handwringing from the EU on anything regarding tech or competitiveness that they know it too, but can’t make the trade offs to fix it. Great if you’re already established and looking to keep things cushy, pretty terrible if you’re trying to get established though.
Like the thread with the folks who broke into tech by problem solving a case as a kid - imagine if they wouldn’t have been allowed to shell script until they’d gotten certified or joined the appropriate union?
It’s also why salaries are generally so much lower there for engineers. The real world doesn’t much care about what we (as producers or market participants) want in an abstract ‘it’s not fair’ sense, it’s about the economics of the markets and the needs and who can meet them best. If someone can get me firewood for $5 at the same or better quality as the person selling it for $10, it would require a lot to not take the $5 person up on their offer for the vast majority of people. It’s what has led to a massive expansion in wealth for all humans, as we constantly look to optimize and create more value for less cost.
If someone has 20 years of experience in tech x, but I use tech y - and they have shown zero interest in, and can’t demonstrate how to apply that experience in tech x to tech y - why should I or anyone be paying them for something that is not applicable or helpful to me at all? So they can feel like it wasn’t wasted? Good for them, bad for me.
What you say is an empty statement because it doesn't rank which skills are the most important to a software engineer.
Coding is the core skill of software engineering.
For other skills, say, communication, you will need to have an adequate amount of it, but you don't need to be godlike (e.g. think Bill Clinton's level).
If you have the Bill Clinton's level of communication, you will likely be in other positions.
Now if you have the Bill Clinton's level of coding, you will be software engineer.
I agree that coding is the core skill of software engineering, no question about that. What I don't agree with is when we make it as a deciding factor in interviews for mid and senior levels. At such stage, I'd assume someone who worked for few employers already know how to code and there are different standards of skills we need to hold them for, such as designing relatively complex systems and understanding tradeoffs, communicating these trade offs, how they deal with priorities to ship a functioning software etc etc.
I think we should limit the algorithm problems in an interview to either college graduates/engineers entering the field, or that's an essential part of the job (unlike most Web development)
Leetcode implies complex, contrived algorithm scenarios presented to be taken apart in a brief interview (usually at most 40 minutes for the coding question). Real world scenarios do not resemble leetcode questions, and hard real world problems are solved with more time and careful thought.
This creates serious inertia. Once you are 3-4+ years into a job, you probably haven't done much leetcode studying in a while outside of you doing interviews yourself. Interviewing at other companies is actually a pain in the ass, so it's often not worth the bother.
It's automated and mostly mindless. They are looking for "smart" solutions, that fail to account for testability and code maintanance.
I fail a lot of leetcode challenges, yet I've built a critical data platform for Grubhub, IBM, Expedia, etc... some are still in operation to this day.
Well, there are some problems that make it hard to hire.
- Being in Outer Nowhere. It may be a nice place to live, but if you go there, you're trapped. No other employer unless you move.
- Being in an obscure technology niche. If you spend five years working on railroad locomotive motor control, you have a hard time getting a job afterwards.
- Going to a company that's in a mess and has no one with a clue. This is a setup for either overwork or failure.
- A staff job, rather than a line job. At a "tech" company, developers contribute to revenue. At a company that just has an in-house IT unit, developers contribute to cost.
1. Too much reliance on automated filtering of resumes
2. Companies asking for too much years of experience with specific tech/language/stack
3. Developers dismiss other developers (for using javascript, apparently?)
4. The 'asking about language trivia' interviews are bad, it would be much better to make candidate solve a small task from scratch
5. Restatement of (2) but with individual engineers instead of companies
6. Companies don't comp the employees education enough
7. Lowballing everyone's offers by default to save on labor costs is bad
What is interesting to me is that this is NOT a FAANGMO criticism. The point that applies the most to FAANGMO is probably 7, but even there the lowballs are not that low.
Also fairly amusing is the suggestion to stop asking programming language trivia in interviews. Made me double-check the year of the article.
Absolutely terrible developers exist, some have 5, 10, or 20 years of experience. I have worked with at least two of them in my career. One was a co worker at a startup. He seemed smart and confident but he just didn't do any work and focused on things like "optimizing code linting" and breaking our DNS, telling us it was fixed then laughing at us while we had to wait 24 hours for the new fixed DNS stuff to resolve. Due to a comedy of errors by our companies management, he was able to last 12 months and was fired on vesting day. More recently at a different company, we hired a guy with 4 years of tech consulting and free lancing experience and he nearly destroyed the company twice in two months and I then fired him. He did surprisingly well on our interview that we designed to be less crappy than the general tech interview loop, but in retrospect his success was clearly a sign that our interview loop was extremely broken. Having "false negatives" isn't great, but having a single false positive can literally destroy your company. People with multiple years of experience just may be the crappy developer that destroys your startup.
The main thrust of the article is that companies should be open to hiring junior devs with no conventional credentials (degree, specific work experience). This is somewhat reasonable on the surface. But it ignores the question of how much time senior people will have to invest in order to train junior devs with no discernible credentials (which are a proxy for actual ability to deliver robust, maintainable code). Or how many such juniors can be hired in a given team without letting the product go to pieces. The amount of supervision untrained junior devs will need in order to get decent work output from them is quite high: it is often better to be picky and recruit a much smaller number of senior devs with proven work experience and/or credentials. Ditto with a mix of senior devs and junior devs who do have good credentials.
That being said, one thing I have noticed is the insane pickiness of companies these days. Series-A startups that are very likely to die expecting FAANG-level coding skills but with out FAANG-level compensation or career progression opportunities. Startups that run on AWS refusing to hire experienced developers who do not have AWS experience, but have delivered plenty of robust shrink-wrapped hardware/software product. Consumer-oriented startups turning up their noses at devs with enterprise backgrounds. Young, growing companies taking 6+ months to hire, waiting for the perfect unicorn candidate while they can be hiring more realistically and adding value (and going to market faster) much sooner.
The interview loops commonly run 5-6 hours, for even the smallest of shops, and time is wasted on banal 'culture-fit' interviews (read: we won't hire you if we feel like we can't hang out with you after work; we won't hire you if we don't feel like you are 'one of us'), ridiculously hard DP-type questions that almost always require one to have solved the problem prior, poorly-trained junior interviewers who are lacking in the background needed to properly evaluate interviewees' prior work experience, and so on. One is left wondering if such companies even intend to hire!
I think there's also a power struggle. I've seen so many shitty job offers, where a company thinks it can hire developers like a commodity and have them implement whatever crap idea they have come up with.
Unless they have a truly great product at hand, the only ones applying will be the ones desperate for money. But no good developer wants to work on some potential shovel ware that's dead on arrival.
There's so much software being made these days, and most of it isn't all that useful to be honest. There are also so many old century companies still failing to adapt to the internet age, trying to force their way into it with half baked copy cat strategies. I'm not going to put all my passion into someone else's dubious pipe dreams or some vision-less experimental venture.
Good developers know they are valuable, and that their work carries the whole product. Jobs at companies that make beneficial, useful software are usually highly contested, but for companies that struggle to attract developers the issue might be more then just the job market.
To be honest - if the people that are completely clueless about tech are paying well - I'll happily take their money, whip up the easiest thing and leave.
Remember that you pay a mechanic not to tap your car with a hammer, but for the years of experience to know where to just gently tap your car without breaking anything.
We just make more money and can generate a lot more income.
I moved from a 2/5 to a 4.5/5. Doesn't mean it was necessarily a satisfying move. There's 6 - great mission and product, which the first one had and the new job is weak in, but it factors for a lot more than the other 5 in attractiveness of the job, at least for me
This. I never understood The attractiveness of working for Facebook, Twitter, Netflix, etc. other then money. How is the Dev work there helping society at large?
Once, I got approached for a job at Amazon to help "build the next big e-billing system"... What an uninspiring thing to do.
I care little about what the product/impact is and mostly care about how interesting the work is on a technical level. I am pretty fond of theoretical research even when practical usage is very unlikely and did a math major mostly for fun. One thing the companies you listed share is large amounts of data and as I work in ML having large datasets is really nice to play with. Also large tech companies tend to have better data infrastructure and more time can be spent focused on ml tasks vs data engineering tasks. What the model actually does is of little interest to me and I've worked in a couple different ml areas now.
I do have an eventual interest to do research focused role, but interesting impactful research I think requires either high management (professor leading a large lab/research director) or making your own thing. The first I lack the experience for and the second doing a startup feels too risky to me today. If I was wealthy enough I would probably try making a research themed ai startup.
It depends on whether you care about the overall product or just the puzzles involved in the product.
I get my overall high level fix from outside of work activities, so work is enjoyable mostly for the little puzzles it generates every day. I am sure that there are some fascinating considerations for a mega e-billing system, even if it isn't all that interesting in itself.
Yes! But that isn't something that all (or even most?) companies have full control over.
Most people aren't going to be passionate about building, oh, I dunno, software for insurance companies, but it still needs to get done. There might be a handful of "disruptive" companies doing something in the space, but 99% aren't.
There's a lot more "boring" software (even in the startup world) that needs to be built than anything else. The problem is really that these companies don't seem to be self-aware and they don't adjust #1-#5 (especially #1) accordingly.
That's the thing, it is something companies have control over, if they have a dynamic and passionate CEO, and are willing to take on risk. Or at least, if it's a big established company, create pockets where groups are able to work on entirely new initiatives.
I feel like this is largely a myth propagated by business. If you feel powerless to control things like your pay or work life balance, then they control it by default. I found once I learned to set boundaries in my personal life that doing it at work was easy because I don’t have to care about an employer’s feelings and my income skyrocketed.
Problem no. 5. Companies already have too many developers.
At some point there just aren't enough qualified, talented, experienced, good developers left to hire, because they were already hired. Some companies simply have too many developers, and the bar already isn't high. They think that just because they can afford to pay a developer, that that's what they should be doing, rather than reorganizing and utilizing their existing resources better.
Want to become a plumber? You'll have to apprentice for 4-5 years (at minimum wage) and work 2,000 hours and/or 250 classroom hours. You can then take a state-accredited exam and become a licensed journeyman plumber, renewing your license periodically.
Want to become a software developer? Go to 130-440 hours of boot camp classes with no on-the-job training. Congrats, here's your insane starting salary, now go struggle to make a rudimentary web app with no idea why somebody keeps asking you to run this thing called the "ping command".
"""
You should not be testing people’s ability to recall some obscure definition in an interview. You should be testing people’s ability to tackle something they can’t recall off the top of their head. And, you should allow them every tool they have available.
If they’re totally unfamiliar with the problem, and yet they make significant progress in just one hour that should be interpreted as a good sign this person would provide a lot of value to your company
"""
I think this is extremely important. A developer that can make a lot of progress on something they haven't seen before is often times just as good as a developer who can tell you the big-O efficiency of reversing a red-black tree off the top of their head. Although the latter may indicate a very interested systems-level hobbyist, which is also an excellent value in terms of an engineering quality but impossible to tell from a whiteboard interview if they're a hobbyist or if they just studied.
I mean, this is the whole point of the dreaded coding whiteboard interview, no? You can't memorize your way out of it, and with any luck the interviewer will be looking at the big picture of how you tackle the problem and what headway you make, instead of sniping at syntax or the names of library calls.
I would also be interested in this, but it's also something simply crammable. It's impossible to know from a limited interview time just from trivia whether or not someone just crams last minute.
I'm more interested in knowing if they can debug something nasty or opaque with patience and using deduction instead of flailing. Chances are the person who can do this might also be able to explain why a red-black tree inversion is a certain O-notation, but its not strictly necessary.
Just as a counter point, developers that have such a knowledge about algorithms and efficiency tend to be able to sort through different possibilities and branches investigation for new problems much quicker than a developer that has to look up everything on the way. Although that's something that can just come from experience too.
Honest question: just how often do you actually need to worry about algorithms in your day to day work? The vast majority of software dev, even/especially in hot startups and the like, is bog-standard CRUD and 99.9% of the time the correct response to "I need to do something slightly complicated" is "call an existing library function".
I can't tell during my limited time in an interview if a developer has that knowledge because they crammed (and therefore will forget quickly on the job) or if they actually study and understand this stuff.
I can tell during my limited time in an interview if a developer is capable of making logical deductions and not flail when exposed to a problem they may not have seen before. And, better yet, if they do study algos for fun, this will become apparent!
Writer doesn’t seem to know what drives a lot of things and seems to suspiciously get a lot of poor interactions.
I have never been cursed at for anything by an interviewer. I have never heard anyone I know tell me they were cursed at.
The older guy who had his school paid for? Guess what? College was insanely cheaper back then. Also, it was extremely rare. Today, all the education you need to learn any language is available for free in any medium you like. Even CS fundamentals.
I can get cooking with a programming language I’ve never seen in my life in a matter of days because most programming languages are either very similar to each other or they’re similar to some paradigm most of us already know like functional programming.
The companies looking for 5 or 10 years of experience with a language aren't looking for someone to "get cooking" and learn as they go. It's true that most experienced developers can quickly pick up the syntax of a new language and start writing code quickly, but every language has its nuances and pitfalls and you're not going to know them all after a month or two of writing code.
At a certain level of experience, you do have an idea of what kinds of things can be nuances and pitfalls, though. And for certain team/codebase sizes, the effort required to learn and adapt to the specifics of the in-house systems will almost certainly dwarf the pitfalls of the general parts of the language/platform/stack.
There's some shortcomings of the algo-oriented interviewing practices FAANGs are famous for, but IMO one of the things they get very right is that language/stack knowledge is considered less interesting compared to general problem solving skills (and I say that as someone who failed to get an offer on his last round of trying).
I once applied for a job where I knew the hiring manager already but of course I had to go through the whole interview process. The job description was rather generic with phrases like "3+ years of experience in C++/Java/C# that I think I fulfilled pretty well. Next day I got a standard rejection email from a "noreply" address without any explanation why. I called the hiring manager and asked if he could figure out what happened, I didn't expect to drop out at the resume stage already. He came back to me telling me that the keyword "C#" was not in there, so I was automatically filtered and rejected. I didn't know that "experience in C++/Java/C#" apparently means experience in ALL of them, all these languages/keywords must appear in the CV somewhere.
Two things I learned here: 1) If I didn't know already someone at that company, I would still be clueless why I wasn't accepted. 2) The first hiring stage at big companies is indeed a silly keyword filtering process.
If you've ever been on the other end of the pipe for hiring you'll understand the need for filtering. The alternative is to never list jobs and hire through networks, which has other problems.
> That means, in this horribly simplified universe, that the entire world could consist of 1,000,000 programmers, of whom the worst 199 keep applying for every job and never getting them, but the best 999,801 always get jobs as soon as they apply for one. So every time a job is listed the 199 losers apply, as usual, and one guy from the pool of 999,801 applies, and he gets the job, of course, because he’s the best, and now, in this contrived example, every employer thinks they’re getting the top 0.5% when they’re actually getting the top 99.9801%.
Upwards of 90% of applicants for many roles - talking about external postings, it's usually only 50% for internal - have clearly (in my experience) not even actually read the job posting, let alone have an understanding of what the job would entail or any of the requisite experience to be successful in it.
Many of the remaining 10% have read enough they'll try to fake the requisite experience or understanding of it, but on the job would fail almost immediately (and not in a coachable 'oh yeah, we use bit x instead of y here', but in a 'have no idea how to use the calendar App we use, despite claiming years of hands on experience). Only a couple % of applicants for a public posting will have the actual experience and ability to do the job.
And that is before we start talking about fit with others/ability to work in the culture effectively, and other soft skills.
I've had candidates apply for senior Java developer positions that couldn't write out the most basic class structure on a white board while claiming 10 years of experience (like class Foo {}), candidates applying for engineering managing jobs that struggled with basic arithmetic, candidates applying for executive admin jobs that had no idea how to process an inbox at all (except to sort everything with a billion filters - except I needed them to, you know, actually figure out what needed to happen and sort out the junk, not categorize the junk for me to sort through), and a million other weird things like that. I had a lawyer who wasn't a lawyer once. That one I filed a criminal complaint against.
Sometimes it may be brain lock, but in many cases I think it was fluffery and 'fake it till you make it' thinking.
A large part of being a successful company is figuring out how to filter out the frauds/incompetents/won't actually fit or work outs, from the people who can get things done and can work with everyone who is already there without making a giant mess. It's surprisingly hard. Most don't do a good job at it.
> It’s hard for me to fathom that such a large proportion of candidates are terrible.
It’s not that most candidates are terrible, it’s that most job applications are 90% mismatched. Don’t forget many many people are applying to multiple jobs, and most of them are great candidates for something, just maybe not the high paying lead role as the first job out of college.
As someone who’s done a lot of hiring and mentoring, I often tell people to apply lots of places and punch above your weight class, a little, for some of it. This is just like applying for college - you put in the app to Harvard on the wild off chance you’ll get in, you put in the app to your state school so you have a safety, then you apply for a range of schools, half of them long shots. Turns out, Harvard rejects more than 90% of their applications... because they get a lot of them, and most of them are long shots. This does mean they have some filters in place, for better or worse.
I see this same advice play out among applicants - many of them are applying for jobs that they might have only half or a third of the qualifications for. But maybe that’s okay, especially for junior positions. Many companies hire people who don’t have 100% of the listed qualifications, so as an applicant, it might be worth checking if you pass their filter, and as a hiring manager, it might be worth learning how to avoid interviewing people who are obviously more hopeful than qualified.
Why is that hard to see? With a lot of simplification about "good" and "bad" candidates...
It's the natural outcome of there being a very small group of bad candidates who apply for a lot of jobs, and a very large group of good candidates who don't apply for jobs very often. What if there's only 50 bad candidates in a particular region, but they all apply for every posted job opening? That's a lot of chaff to get through on every single job posting.
Things aren't that simple for a lot of reasons, but the basic idea holds - you don't need a huge number of people applying for jobs they're clearly unsuited for in order for those people to add up to a huge portion of applicants for any particular job opening.
Really good point. The really good candidate/engineer/whatever might end up only doing 3-10 interviews over 10 years, or less. They do well and get rewarded where they are at, and get picked up quickly when they do interview - and with a good offer.
The really badly interviewing candidate might end up doing 50 a month for a year before they stop looking - and be on the market in another 6 months to a year, where they do it all again.
You'll see the bad pennies a whole lot more often than the good ones.
I've interviewed a ton of bootcamp and "I took a class on Udemy so I'm a Full Stack Engineer(TM) now" candidates in the past year. There have been some really good engineers hired from bootcamps, but a lot of people just didn't learn how to code.
Bootcamps are hit or miss, but sometimes I think they spend more time on having their students create shiny LinkedIn and GitHub profiles to impress recruiters than teaching them how to write software.
That or the "I've been working with Drupal for 10 years" and now I'm applying to a position looking for 4ish years of Java. Sometimes I need someone with experience and that's just not going to cut it.
My favorite is getting word doc resumes filled with red squiggles. How am I going to trust you to care about accurate code when you can't be bothered to spell check a resume.
We were hiring for a front end dev, and had 40 applications in a few days. Majority were either still in uni, in another continent, or just had 0 experience/ education that was directly relevant, not even a portfolio at times.
Majority of 'decent' applicants that passed the filtering step very obviously followed some tutorial once, and promptly listed it under their skills. Many didn't have much, if any, work on GitHub. During the interview process a few were clearly fabricating their experience, and would get very uncomfortable if we asked for any more details.
I don't get it - it's disrespectful of our time, and a waste of theirs, to lie. Do they just hope they will get that first job without any relevant knowledge, train on the job for a year, and be a proper dev then? Like, we're hiring for a business not a bootcamp. If you can't be semi-productive within a few months, who knows if we ever do get some return on the investment, both in terms of other dev's time, and in terms of compensation.
Ended up filtering more on ability to communicate, parse requirements, and how well they could pick new skills up, than what they already knew. This was for a lower/mid range dev, in terms of experience.
A good number of people apply to positions that list "5 years in Java" with 1 year in Python, because it's impossible to tell if the role being fulfilled is specialized enough to justify needing half a decade of deep java knowledge or if it's something someone can learn on the job if they're clever. For hiring managers who really need that deeper knowledge that's a lot of filtering.
Not surprising to me, It's a field that pays an insane amount of money for such low barriers to entry (notably, it does not require expensive credentials). And there's swaths of stories out there about people going from 0-100 in a matter of months.
Additionally, this may be a popular opinions, but there are a lot of places where you don't have to be particularly competent where you can earn more money than you could otherwise.
I've been on the other side of hiring. It was in Europe and it wasn't an American superstar company. A long queue of folks after bootcamps and attempting to requalify from various non-IT industries...
You can't talk about a shortage of something if you aren't specifying the price you are offering. It's like me saying there's a shortage of new Porsche 911s because I only have $20,000 and can't seem to buy one anywhere. If I had $100K in my pocket, I would not observe any shortage. Same thing for tech workers. You can't just offer the usual compensation and standard benefits and then say "See, we just can't seem to find anyone! Obviously there's a shortage!"
Every time I hear of developer shortages the next sentence involves increasing the H-1B visa pool.
I’m now in upper management. I’m told I can hire as many Indian developers as I want (based in India) but must limit my US development team. Why? Cost of course. There is no real shortage, just an attempt to clamp down on real wages.
I'm also in the same position as a manager, but to me it makes perfect sense. Roughly speaking a staff+ engineer in India will be $60-100K/yr total comp including benefits (and I'm talking IIT talent, way above market wages) with skills equivalent to or better than one in the Bay Area at $500K+. Our best development right now happens out of our India office.
I mean you cannot deny that there is zero merit to the rule. A good developer in Bangalore is $35k a year. A good developer in the US will set you back no less than $120k + 40% for all the benefits and payroll taxes and other associated employment costs.
If by "clamp down on wages" you mean control expenses in a general sense, i guess you're correct, but you sure are making it sound sinister.
What's not emphasized in the article is that these days nobody wants generalists anymore. Companies don't even want front-end/back-end devs. They are specifically looking for React/Angular/Vue; or "GraphQL proficiency"; or Spring/Django/Node/etc.
On the one hand, recruiters spam you with emails without a single mentioning of any language stack. At the other end of the spectrum - "at least 10 years of experience working with X is a must".
It makes it difficult for experienced developers to hop from one language stack to another. And then we see comments on HN like "I love Clojure/Rust/Haskell/Julia/Elm/etc., but I'm getting paid to write ... in something else"
Google pours piles of money into Angular. Businesses want Angular developers. People aspiring for Google salary pay fortunes for Angular bootcamps. Instructions unclear, stuck sending CVs.
As a college student, 1. is the one that worries the most. Automatic filtering is scary, and there's no way to test how these ATS systems are viewing my resume.
Difficult when you're an immigrant. I moved to Canada for this reason, and though the tech scene is great here (Toronto at least), it sucks how everyone here talks about how "terrible" the tech scene is wants to move to SF instead. Feels like a never ending cycle.
People will always find things to complain about. Toronto isn't SF when it comes to tech (nowhere is), but it still has plenty of opportunity. Don't listen to the complainers. Just focus on becoming a good SWE for now, then worry about maximizing your earnings.
Automatic filtering is annoying, but there are plenty of tools that will scan your resume and tell you what keywords they find. I once spent weeks crafting a catchy looking resume with a fixed width font and ascii art. It didn't get any responses, and I didn't understand why until I put it through one of these scanners and realized that the program I had used to save the PDF had strangely encoded all of the text in reverse, so I wasn't passing any of the automatic filters. The takeaway: test your resume with a scanner!
It sounds like you could have just opened the PDF that was generated to double-check it too. Sending off a derivative file without proofing seems like a big YOLO move to me
A lot of these scanners went down a few months ago when one of the API services (not sure which) stopped working, but if you have a newer link please do send!
If you're a college student, you should be single minded on having at least one (and ideally two, since the first will be lower caliber) internships under your belt. This will get you past every single new grad filter screen. If you can do this and handle junior dev algorithm questions, you will have plenty of new grad offers.
Also, if you are even vaguely talking to a recruiter (e.g. via career fair) then they are not going to screen you using an automated system.
There is software out there for optimizing resumes to ATS. It basically is keyword matching. One tool will allow you to paste the Job Description and your Resume. You can give it a URL, and they'll detect ATS type, and give you further recommendations for file formats and things.
In any case, it's like an arm race for SEO. What was once a useful measure will lose meaning as everyone adopts these tools.
You are still quite young, it doesn't hurt to take 1-2 years to build your experience in this industry before going to top companies. And believe, they are not that picky.
When you are a college student, it is really hard to distinguish yourself from your peers, unless you are truly outstanding, otherwise most resumes look likes clones to each other.
> Education is inaccessible
Full-time undergraduate tution at University of Washington is $11,745 for residents.
Washington State University's online program is $10616/year for residents (and only slightly more for non-residents.)
Community College is something less than $3000.
There are a lot of people make bad financial decisions around education (I was one of them at one point), but if one is willing to constrain their decisions to in-state options and are able to get some of the financial aid then college education (espicially in STEM or Health careers) remains a good tradeoff. Going to an out state school or a private school without huge financial incentives to go... well, understand you are buying a luxury good and status, not making an investment.
Besides, if the author is proposing that companies pay for education, poo-pooing $8-10k in grants is insane. It is easily 100% for some part time program, and is a huge chunk of the cost for even brand name in-state programs at the undergrad level.
Edit-
I'm not saying student debt isn't a major problem, it is. However, it remains unnecessary for most students to go into horror story levels of debt to get a degree, especially if they are able to work while going to school or live rent free with relatives. After all estimated costs for housing, food, and other living expenses dwarf the tuition costs ($18k/year at UW).
I am an aspie that has gaps in my resume. I moved to a fairly remote location while I was working on starting my first company. There were a few "software" companies there. The quality of the engineers was very low, as was the software they were producing. I wanted to do some work for a while to gather up some more money. These places were obviously desperate for engineers. They had ads every week for months or years. I went to the interviews. All of the technical tests were easy. Often they didn't even get their own answers right. None of them hired me though. It was very obviously for the aspie personality. They were obviously not that desperate.
You can say "oh you're an aspie. Oh you have gaps in your resume". Ahh... exactly how desperate are they if they can pick and choose while having such terrible in-house talent? The pay at these places was pretty terrible. Looking at their history, they often resorted to using off-shore people. Most of their upper management are really just family members making a passive income from the company. None of this suggests to me any real crisis or shortage in labour, just people wanting to keep raking in easy money.
I was rejected by a startup because I didn't aks a question about the company and they thought that I was not interesting in the company.
RIP: All the time I took for completing the application writing a cover letter for the job.
There's no "hiring shortage" if you pay people enough. Saying there's a "hiring shortage" is really just a way of saying "we'd like to be able to pay our employees lower salaries."
I can agree that once you've picked up a few different programming languages with different paradigms (functional, OO) you can probably pick up another adjacent language on the job pretty quickly.
However:
"Furthermore, if you really want a C++ developer you can just expect a developer to learn C++ on the job if they have any adjacent experience with any other language."
When I apply I am overqualified for the job. I have too much experience and they don't want to pay me for it. I don't think there is a lack of developers, I think they want Superman at Jimmy Oslen prices. Then they end up hiring a Jimmy Oslen because he has a CS degree and agrees to work for less.
I once applied for CEO of Microsoft and got told I was overqualified because I ran small businesses.
When I am hiring, for every ~30 post interview rejections I always get an angry follow up email explaining in details why my hiring process is bad and how I should fix it. I politely reply “thank you” and silently also thank my hiring process for correctly rejecting that specific candidate.
Not sure how much sympathy I have with this specific set of complaints, but what I do think is that if tech companies still don't have enough staff by now (several decades in after software has become one of the worlds largest professions) - well, it's their own fault. Industries need to foster the creation of the workforces they need to survive. That means occasionally not rejecting every resume that doesn't have 5+ years of experience with your exact tech stack and being willing to invest in cross-learning and education. It also means investing in your own staff as they progress to ensure they can climb in experience and skillsets to become the experienced staff you need.
Definitely. Last time I was looking at least 80% of job postings obviously had no job behind them or were duplicates. H1-B setups, recruiters simply trying to build a list of clients, multiple ads for what was obviously the same underlying job, a few that continually posted the same ad but didn't look like recruiters etc.
I suspect the actual garbage rate was at least 90%.
Admittedly, I do not live in a tech hub and relocation is not an option.
But I have a story myself: A certain company that is probably in the top100 biggest of the world, one time attempted to hire me, but their hiring process was a mess and they forgot me in the middle.
Then I noticed they kept complaining on media about not finding anyone for that job. 2 YEARS later, after they posted another complaint, I decided to apply again, and even mentioned the previous hiring process.
The HR department said they were sorry, explained that the previous time it was a contractor and they were bad at their job and got fired. So I thought this time I would get hired.
Went through their entire process... and then HR sent me a sad letter, that the headquarters in the company home country, blocked my hire because it would violate policy.
The policy in question, is that for that job, people needed experience. But also, they needed a local. But... they were the first company offering that particular job in the country, ever. So you have this company trying to be the first company to hire for a particular job in the country, but wants someone with experience, complaining endlessy about it on the media. I felt bad for the employees that were dealing with that bullshit.
(the job in question was Game Producer, I have a bachelor degree for it, but back then this company was the only company in the country with such job opening. Some other game companies DID exist in the country but all of them imported producers from their other studios, so for example there was some french and canadian producers in the country)
>A bad interview is when you ask them the definition of some specific thing in some specific framework like “Tell me what a closure in javascript is.” then treat them like they’re stupid if they don’t know.
Is this a good example? Isn't "what is a closure?" more of a smell test "do you know the language" question?
Maybe asking "oh you know python? Tell me how to implement and use a metaclass" without access to the documentation would be a better example.
Damn. I've been coding in Python for 10+ years and never came across this "metaclass" thing. Starts wondering whether I'm rusty and un-hireable. Curious what it is, I read the first result on Google, which goes through an example that I don't understand the point fully, and it concludes with "metaclasses can easily veer into the realm of being a “solution in search of a problem.”"
Oh well, good luck hiring python devs :)
I'd agree more on the closure part in javascript though.
It is absolutely, without question, easier for a decent dev to find a job than for a non-tech giant to hire devs. I have done both and talk to companies as part of my current job about their hiring and attrition every month. We are in one of the most in-demand industries in the world.
If you are a decent developer, and you can't find a job, one of two things is happening:
1) You are being too picky: You're applying for jobs out of your league or that aren't a good fit for you (yet)
2) You need to fix up some skills. These could be coding, or they could be working with people, interviewing, presentation, etc.
When I applied for jobs, I fired out 140 applications in the space of 7 days and had multiple offers to talk (and then jobs) two weeks later, and I have no degree. But I didn't have fantasies about FAANG and driving a Tesla in two years, I applied at small companies that needed people like me. 5 years after that, I'm making very comfortable money from moving up gradually to better work and now have an hourly that is FAANG competitive. (I did freelance for 10 years previous to that, so the FAANG competitive compensation was 15 years in the making). People are impatient and don't want to look at their own assumptions and decisions critically.
The work you do at a FAANG is generally much simpler than what you prepare for the interview. If I were them I would just split the streams: hard interviews and high pay for incredible talent and just pair programming / entry level pay for entry level developers.
I have senior engineer friends who got hired at Google for basically doing overpaid crud API all day. You could have that for a fraction of the price and without wasting a senior's time on that crap.
FAANGs complaining about lack of developers have only themselves to blame. I rarely heard it's a problem for them, though: the high salaries attract a never ending stream of talent willing to prepare for whatever interview they can think of.
Smaller companies with lower compensations and less valuable stock have much bigger problems. Finding people who are able to code is not trivial if you don't have FAANG's money.
You have no idea how many people I've seen coming to mid / senior interview (no algorithms, just pair programming) lacking basic programming skills.
Tech companies lowballing employees? That's news to me. On the whole the market seem very good for tech employees.
Also, what company is only paying 50-70k to Juniors but 300k to Seniors? It seems like most companies that pay well do it across the board, not just for Seniors.
I great many salient points. I've been a hiring manager for many years now, and in the last few years a candidate twice so I've had recent exposure to the 'current trends'. It's difficult to strike a good balance between filtering for candidates that will be a good fit, and missing out on ones that would be great, but don't fall into the job description square box. I also wrote some comments on this problem last year https://www.linkedin.com/pulse/thoughts-hiring-engineers-rob...
You keep talking about rent seeking behavior. Rent seeking is when an asset is owned or monopolized in such a way that the owner can experiment with putting up prices without delivering any extra value. It is a very secure and sought after position: Bill Gates’ company is successful in the software business, so he buys farmland and timberland. You have every reason to criticize the hiring practices in the software industry, and I’m sure you are at least partially right. But these practices have nothing to do with rent seeking.
I will discourage anyone to work in europe as a software developer. Salaries are so low that you will probably make more money in the most third-world countries.
I was kind of following along and agreeing in many aspects with the article, until I got to the following:
>You should be giving people obscure algorithms in interviews. For example, ask a candidate to make a playable game of Japanese GO, and ask them to use flood-fill.
In my opinion, asking algorithmic questions in interviews for say a front-end development position is one of the core fundamental problems of hiring right now. Asking someone who will be spending their time taking Figma prototypes and making them work with your API or backend is what most front-end/web developers will be doing.
If anything, algorithmic questions are exclusionary and do not tell you anything about a developers ability to solve problems. Oh, you remembered an algorithm from your compsci classes or you went to one of those GitHub interview prep repositories and memorised some of the things companies ask: well done. I have friends who work for companies like Facebook and Google, they all "prepped" for their interviews like they taking an exam.
What about the self-taught developers? You know the ones who did coding bootcamps, courses that Twitter developers are flogging for a few hundred dollars to help you get better at Javascript and CSS. Algorithm questions are biased towards academically taught developers, not the ones who taught themselves (and in web, there are so many self-taught developers).
The honest truth is the times that you do need an algorithm, you are going to look it up. I can't think of a developer that I have worked with in my 13 years as a front-end developer whoever solved a problem with an algorithm they just knew off of the top of their head. Problems in web land are solved with Google and trying things until they work.
Part of being a good developer is knowing what to type into Google, not the ability to recall everything like a robot.
I can do a basic sort, I can do a FizzBuzz and that's really it. Unless the job specifically requires writing algorithms on a day-to-day basis, you can use StackOverflow, lift the code from a blog post or install an Npm package.
Part of this post seemed to be pieces of truth sprinkled with what are clearly exaggerated claims and lies. I seriously doubt the following quoted situation happened:
>The general rudeness is ridiculous. I once had an interviewer ask me if I was a wizard with GO, C++, Rust, and C over the phone. Then when I said I had some experience with rust, he immediately cursed at me and hung up.
An interviewer didn't curse the author because he said he only knew a little bit of Rust. This just seems completely fabricated to me.
All of the problems when it comes to being unable to find developers or perceived skill shortages usually come back to the hiring and interview process. Why companies feel the need to subject a developer with 10+ years experience to a multi-stage interview full of traps designed to make you slip up so whoever is interviewing you can feel superior defies belief. If someone has been working for 10 years, I think you can accommodate them with a more streamlined interview process that doesn't waste hours, weeks and sometimes months of their time.
It reminds me of the time I interviewed at a company. At that point, I had close to 10 years experience (a few months off) they were hiring for a front-end role. I attended the interview, the interviewer was sick (red flag #1) this was pre-COVID obviously. I went to a small meeting room, we spoke for a few minutes. He boasted how he had been at the company for a little over a year and had just been promoted to lead developer (red flag #2).
He pulled out some sheets of paper with questions, there were 20 of them. He then explained this is a written interview, to write the answers on blank sheets of paper to the questions. I had an hour. Some of these questions were coding questions, as in, I had to write code on sheets of white paper (red flag #3).
Instead of leaving the room, the person interviewing me sat across from me on his phone, occasionally glancing over at what I was writing (red flag #4). He kept sneezing and coughing, it was terrible. The whole thing made me nervous, I blocked up on simple questions.
One of the questions was to swap values in an array without introducing a third variable. Array destructuring was new then, but valid. I used that as the answer, he tried telling me that it wasn't a valid solution to the question and that he wanted another solution. I explained how destructuring was an up and coming part of the ECMAScript specification, but he continued to say it wasn't a valid solution. My answer was `[a, b] = [b, a]` which was very much valid.
It is people like the person who interviewed me causing these perceived skill shortages, not the lack of skilled developers.
Don't get me started on companies who don't even know what they are hiring for. Some of the job descriptions I have seen in front-end/Javascript are confused and often at odds with themselves. Asking for candidates with 3+ years experience in Javascript and then saying things like, "Experience with PHP or Python preferable" for what are being advertised as front-end positions, not full-stack or general web developer.
I am the lead front-end engineer for the company I work at, I am part of the hiring process. I refuse to ever ask algorithmic questions, coding puzzles or anything that will not relate to the average day to day job. I am honest and upfront when I say to candidates, "Sometimes a ticket will come through and it's to rename a text value on a button" or, "Fix some padding on a modal for tablet sized screens because it's cutting off the edge"
I also refuse to take up the precious time of candidates with take home exercises. More often than not, just sitting down and talking to someone, treating them like a human and asking about the things they have done is enough to know if they are a good fit or not. We need to stop treating developers like robots who don't need sleep and can solve complex exaggerated puzzle problems in the space of an hour while being watched and not being given access to the tools they have in the real world.
As a whole, I found this "article" really difficult to read. It reads as though the author is struggling to be hired and has written an angsty article throwing daggers in many different directions and making a lot of assumptions (don't get me started on the grammar and spelling mistakes).
I fully agree about algorithms--that's what Google is for.
However, I can see merit to making a playable game of Go. I would think a playable game of chess or checkers would be a better option, though, as people are much more likely to know the rules.
> Furthermore, if you really want a C++ developer you can just expect a developer to learn C++ on the job if they have any adjacent experience with any other language.
Yeah nope
Any language takes at least 3-5 years to fully master. Sure, the "10 years in X technology" posts are sometimes insane, but... also, there is a real, factual difference between "I worked with technology X once" and "I am working with it for 5 years".
> Any language takes at least 3-5 years to fully master.
That really depends on the language and their background.
Going from C to C++ and you can be pretty functional pretty quickly, and comfortable in a year. Your big hurdle then is whatever specific libraries you're using.
Smaller languages like Lua can be fully adapted to in about 2 months or less.
I mean, yeah, picking someone with 10 years of Python experience and nothing else, then expecting them to jump right into a massive C++ codebase won't go well. But someone with 5 years of Ruby experience and a side project in Python will probably do pretty well if they're dropped into a Python-oriented job.
Tech companies complaining about developer shortages sounds completely tone deaf to me: During this pandemic, society was carried entirely by "essential workers", especially in health care. Those jobs are notoriously underpaid. Those are the real shortages.
In tech we do not have a shortage of developers but an excess of dispensable jobs.
How else is an underpayment problem going to get fixed but by demanding better? This is more of a “both and” situation in that there is not one “real” problem but several problems which are not part of a zero-sum game.
It ain't just the software industry. Industries across the board seem to be running into the same self-inflicted pain: "Woe is us, we can't find anyone who wants to work for us... What's that, pay better and not rely on Kafkaesque recruitment pipelines? lol nah, clearly the workers are lazy and entitled."
Employers won't change their behavior unless they're actually pressured via the ostensibly-free market to do so. In the short term, UBI would give workers vastly more ability to negotiate for better terms on an individual level; this extends to longer term proliferations of both labor unions (which can sustain longer strikes when UBI at least prevents strikers from going hungry or homeless) and ideally-cooperatively-owned startups (wherein the founders have a safety net in the highly-likely event that the startup doesn't make it past the front of its bathtub curve, and wherein the company is less reliant on outside investment just to keep the lights on).
But whenever such solutions get suggested, they of course get shot down as "eww socialism" and the problems persist.
The things the writer complains about certainly happen, but thankfully haven't been the majority of my experiences. I don't have as much emotion invested into the hiring process, but I have been on both ends of it at various times in my career, and I can say both that (some) companies have ridiculous expectations and hiring gauntlets, and that it's hard to find decent developers. I think any hiring manager can tell you horror stories about devs with "ten years of experience" who can't write a for loop.
I take company complaints about worker shortages not to be literal, but to be part of public relations, marketing, and appealing to politicians. Annoying? Sure. But also part of the game. I understand the article is mostly about berating companies for being dishonest about hiring, but I don't think an appropriate counter is to be dishonest about being hired. The rest of my response focuses mainly on the perspective of a career dev looking for work.
Your mileage may vary with different tech scenes, but my take on these experiences:
"Problem no. 1: Companies rely too heavily on automated filtering." While true, if this is your first and major complaint, you rely too heavily on job submission pages. Get a decent recruiter, reply to some linkedin recruiters, and be open to possibilities. You should expect applying to a job board without an internal champion recommending you to have similar odds to cold calling someone to sell them insurance.
"Problem no. 2: The credentialism barrier." I can't speak to the author's experience with this, only to my own. No more than 20% of the time I've interviewed has not knowing a specific programming language or technology been any sort of problem in the interview or even mentioned. I have noticed this happens somewhat more often with Java shops, who expect you to be very experienced specifically with Java, but even there most of them are pretty understanding that you may have some catching up to do (again, in my experience).
"Problem no. 3: Education is inaccessible." This seems a fair complaint, though not specific to technology.
"Problem no. 4: Low Pay and Bad benefits." This is a surprising one to read in technology. Maybe I've just been lucky and in a good area, but tech jobs are pretty well paid, decent benefits, good vacation (not at AWS though, seriously guys, do better), and with a pretty low investment in learning some people skills and negotiating tactics you can drastically increase your earning power. Read "Getting to Yes: Negotiating Agreement Without Giving In." It's short and phenomenally helpful when negotiating salary and benefits.
I empathize with the author's annoyance about listening to what amounts to a PR campaign from tech employers, but again, I think the counter to that is pointing out that it's a lot of hot air, not complaining about how hard it is from a dev's perspective seeking employment. I am open to being wrong on this, however, and welcome dissenting opinions telling me how wrong I am!
Code that written by anybody you actually know is not trusted. I actually saw a channel op in ##javascript of Freenode just this morning refer to people who write original code as a form of Dunning-Kruger over confidence.
I also remember earlier in my career people reading resumes. Those days evaporated early in my career. A good fix was having open source contributions as people would really look at those. Those days are gone too. Reading code is just too hard, so project readme files are the new resumes to ignore.
So now the industry is stacked with developers who can neither read nor write code, can’t evaluate candidates, and fear anything that isn’t externally prepackaged. It’s like watching that movie Idiocracy, and yet people complain about talent shortages.
I find this somewhat counter intuitive because while many software developers seem generally of low confidence about actually doing the work of their jobs they seem generally over confident about security, as in information security. It’s weird because that confidence is the the most clear example of Dunning-Kruger and it isn’t based on anything.
Now, my learning from interviewing and reading job posts is this:
* Use React.
* Don’t bother with open source or a portfolio.
* Resumes are required but they are just weapons to be used against you at a later time. Include education, contact information, and job history only.
I know only part of the picture. But I suspect that the following factors are at least sometimes also in play:
* Many company start software projects as greenfield projects which are written by young, inexperienced, and cheap developers.
* These projects, when successful, grow, and become complex legacy projects.
* Some companies do not realize that it requires far more experience and knowledge to develop such a legacy project further, and expect to be able to hire young, inexperienced, and cheap developers, which pick up work exactly where the former developers were when they left.
* And then they might realize or not that it requires far more experience and skill to read, understand, an maintain such a project, then to start a small new project from the scratch. Yet the amount of work required to understanding and maintaining a legacy project can be a significant part of all the summed work of writing it over the years.
* And then, the companies might be in denial on how much skill they require, or they might not be transparent about the amount of work needed, in an effort to get new developers cheap.
* And in my experience, this is often with a general lack of appreciation of what the developers have actually created.
What comes to my mind is that I experienced an extreme case of this, many years ago when I was a young poor student. I found a leaflet announcing a job opening in an university from a company which sold a kind of embedded product. In the interview, they asked me if I knew how to write C, and if I had any experience with 8-bit assembly (which I had). When I came to my desk the first day, I found an 11-inch stack of 500,000 lines of print-out listings for Z80 (at that time, code was printed out in fan-fold paper). It was mostly generated from C code cross-compiled into assembly, an modified from there. It was commented in Japanese (a beautiful language, but I don't speak it). It didn't had documentation. It did not even have a Makefile. In the following weeks and months, I learned that a much more knowledgeable fellow student had offered his work for four times of my own salary. He was furious at me. The company was apparently not aware that he, being an assembly and embedded expert, was much more capable than me for doing this job. The company made tons of money with selling a specific kind of hardware, and the software, which had initially been reverse engineered from the hardware product, was a necessary companion product to their main offering. I also learned that the previous developer had worked as a contractor, and had left the business relationship after negotiations on his compensation failed. He had died shortly after that, and his widow was unwilling to provide any further information or notes he might have had. In the end, I could only achieve so much at that job - it was not that I wasn't smart but it was just way above my level of experience and knowledge (which was actually not bad). And it would have been years of work anyway. The company would have been far, far better off if they paid ten or even twenty times my salary to an experienced professional, rather than to a student. When I left, they gave me a shabby certificate of employment which even contained spelling errors. And I think that sums up the relationship they had with their developers.
Another thing that I have learned over the years is that while there are of course good and competent developers, and less competent ones, what more often than not makes a huge difference is how work is organized. It can easily increase or decrease the productivity of work by a factor of ten. And this can very much determine how much value good developers can create with their work. That means that if a company cannot pay that much, it might also be because its processes simply cannot generate good value.
So, in short, part of the mismatch which seems to crop up here could be that companies sometimes do not know what they really need, and also do not appreciate what they have in terms of people.
I empathize with your frustration and how it looks from the side of a candidate/developer, and frankly you and I share many of the exact same views. It wasn't long ago that I was in the same position. That being said, I've been fruitlessly stuck in _hiring hell_ (seeking like 10 to 25 devs) for too long, and would love to vent _my_ frustrations by addressing each of these directly.
> Companies rely too heavily on automated filtering
We use minimal to no "automated filtering"--certainly no AI that I'm aware of. Instead, we just focus on pipelines that we perceive as having generally higher quality candidates (e.g. angel.co, Hired.com) and review them all by hand.
As a result, we move more slowly and have a smaller pool. Sadly, this hasn't been working because apparently the candidates are only of marginally higher quality or there's not enough in particular roles. Probably the only way we could ever hope to expand to broader talent pools is by using AI, because we simply do not have the manpower to keep up with the _mountains_ of application.
> The credentialism barrier
> Expecting to find a developer who has 10 years of experience in a specific tool is insane. If you’re trying to find a rust developer and you will only accept them if they have been exclusively coding in rust since its conception you won’t find it. What you’ll get is a receding, inbred hiring pool.
I agree with this (frankly, only big old businesses with McKinsey managers still do this BS). In most scenarios ~2+ yrs is plenty. Sadly, even with this flexibility on my end, we're still in a huge shortage.
> I can get cooking with a programming language I’ve never seen in my life in a matter of days because most programming languages are either very similar to each other or they’re similar to some paradigm most of us already know like functional programming.
> Developers are creative. They try new things. They’re not going to be droning in one language forever.
If you think these are normal, average traits, you have a misunderstanding of the value of your talents. _Most_ developer applicants I see cannot do these things.
> Most developers I know will comfortably do coding challenges in a variety of languages. They do actual work in a variety of languages too.
"Most developers you know" are very far removed from "most developers in general". The developers you know were already hired through a grueling hellfire walk of filtering _countless crowds of candidates_ who struggle to spit out a basic print statement in Python while someone yells from the other room asking if they need help with the interview.
> The credentialism barrier pt. 2/3/4
You won't hear me argue with any of this. Any company that practices this has flawed leadership and hiring practices. Again, we are actually very proactive in avoiding these toxic practices, but sadly still have a shortage problem.
> Education is inaccessible
I can't really speak to this problem. Am I understanding this correctly? If you're turning down jobs because there is no education stipend, that just sounds like a personal decision I've never even heard of before. My engineering career has steadily advanced from junior to upper management, and this thought never once crossed my mind.
> Low Pay and Bad benefits
We offer normal market rates and solid benefits. Do we compete with Google or Facebook? No, but who can? At least we're fully remote, so the compensation is going to be insanely higher than average for some people, and perhaps average-ish for people living in, say, Manhattan.
Anyhow, all this is to say that I hear your frustrations; they strike very close to home for me. I work tirelessly to uphold high standards in my hiring and interviewing practices. But the reality still stands that _there is a shortage_. Next time you find encounter a company with hiring practices you hate, pause for a moment and consider that maybe they're just completely burned out from an endlessly fruitless search just like you are.
(I wrote all this with "anti-procrastination mode" enabled so won't be able to edit it to correct any potential mistakes for a couple hours.)
Is this style of discourse really what Hacker News is about? I come here specifically because it is one of the few places where vague sentimental ranting is discouraged over directness and constructing thought out arguments for points. It's disappointing to see something make it to the top just for having an aggressive "hot take" and not because the content is well presented.
If it happens too often people don’t like it, but this particular topic hasn’t been seen in a while, and it’s something people feel fairly strongly about, so it makes sense that it keeps coming up once in a while.
Reality check: there has never been a hotter seller's market for software engineering talent. The fact that you have not landed a job does not mean that supply is not short in general. Rather than blowing your stack at some recruiter who you heard on a podcast interview, you might want to reflect on yourself and how you might be coming off in job interviews.
As far as low pay goes, yeah, welcome to the labor market. It's easy to write a blog post about how companies need to pay more, but hard to reconcile the reality that if they don't have FAANG cash flows, "market rate" for developers may not be viable, regardless of management's good intentions or lack thereof.
And with regard to bad interviews, remember interviewers are individuals, with skillsets all over the map. Once you get more senior it gets even more frustrating to be judged by someone who has a fraction of your experience. Trust me when I say there is no value in dwelling on this or getting your undies in a bunch. Suck it up and figure out how to play the game (read CtCI, practice on interviewing.io, ask for feedback) and land the job, then do the best work you can every day. Angry screeds will not change anything about the industry and will not help you.