The comment I'm relying to is pretty grayed out at the time of me making this comment but is this really that off?
I know a number of folks who work either as developers or on an IT team for a publicly traded company. 300k+ is a stretch but a lot of them pull an extra 30-80k / year more than working at a non-publicly traded company simply because of the stock options they get every year as part of their compensation.
Having publicly traded stock is nice because once you've gotten past the vesting period you can hang onto them for >= 1 year and sell them on demand for 15% long term capital gains tax instead of the usual 35%+ you would have to pay on income tax. Getting an extra 25k to 68k extra post-tax income every year on top of an average dev salary is a big deal.
So a handful of well-known Silicon Valley-ish companies and then you have Comcast, which is probably as good an example as any of a well-known technology-oriented but fairly mainstream company outside of Silicon Valley, and they're paying a senior engineer about $150K.
It's hard to get a job because there are a lot of charlatans out there and it's often very hard to get rid of them once hired. Even worse is hiring someone merely mediocre and not actively harmful.
That said of course the modern coding interview is I think only very loosely correlated with quality.
I think the thing is there are a certain core number of critical things a business has to do where if they are continually messed up it’ll go out of business eg payrolls, strategy around capital expenditure etc. The issue might be that even small business involved in e-commerce mean cross over with these areas. For example storing sensitive data is dangerous. PHI/PII is digital toxic waste. Like with real toxic waste do you want trained experienced professionals or inexperienced charlatans.
A team of well managed mediocre members will be less of a headache and ultimately more value to a company than a team of rockstars.
Besides all that, mediocre literally means average. You (collective) should be fine with average and stop overloading terms making general life more difficult than it needs to be.
Exactly this. Mismanaged rockstars going off in different directions is chaos.
I have no clue how the term 'mediocre' has come to mean essentially bottom of the barrel proficiency that is still the minimum hiring level quality. The top dog companies can be elitist, but when the company is "MegaCrudSoftware Inc.", it's just plain narcissism. Many Reddit/HN posters exude this in the individual sense and believe they're god's gift to the keyboard and it's just as narcissistic.
Top tier engineers are essentially lubricant. They ideally bring experience and talent to bear on the current site of friction in a business. Even better if they circulate like lubricant.
It’s a similar thing to incels. Many companies and bosses are kind of like incels. You’re a regular guy that’s probably not that interesting, rich, smart, or attractive, but you believe you deserve a chance with any girl.
Using the term 'incel' has become just as cringeworthy as the word itself is depicted by the person who's explaining or calling someone it. For what it's worth, it should just be dropped completely from one's vocabulary for purposes of maturity alone.
We've had to ask you more than once before to stop posting flamebait and/or unsubstantive comments to HN. If you keep doing it, we're going to have to ban you. Please review https://news.ycombinator.com/newsguidelines.html and stick to the rules when commenting here. That means thoughtful, substantive comments and curious conversation.
Top talent means different things to different businesses and many people forget or don't see that. Most companies don't need and are probably actively hurt by people that would be considered top talent at Facebook or something; they need people who can churn away on boring stuff (maintenance, crud, ...), reliably and in a predictable way from 9-5, 4-5 days / week. And like that kind of job and want to do it for decades and decades on end for you; people who don't reload LinkedIn looking for 'new challenges with the latest framework' 20x a day. I would like to hire almost only 'top talent' like that. I like to have 1-2 top performers that 'could've or did' work for Google etc but the rest, no; it's actually risky to have those people in that position because they get bored too quickly, job hop, like new things too much, want to redo stuff they think is badly done etc. Money is not really a thing that binds them either (maybe if you go crazy town, but who besides the FAANGs can pay that?): I had people walk off that were paid US wages in Spain by us (work from home, before covid) because they 'found a more interesting opportunity for their career'. That's not top talent to me.
Edit: and that similarly goes for how you define mediocre; I think my toptalents are your mediocre. I'll have your mediocre please!
> And like that kind of job and want to do it for decades and decades on end for you; people who don't reload LinkedIn looking for 'new challenges with the latest framework' 20x a day.
Interesting, I associate 'latest framework' more with trying to keep the monotonous job interesting (or perhaps misguided attempt at keeping sharp) than with 'new challenges'...
Part of it, is it seems that once you are in web dev, its hard to leave. So you try to make it interesting as best as you can, with "latest frameworks". I personally find all of of web dev to be monotonous
Once you are a {something} dev, it is hard to leave.
That {something} can be web, embedded, ML, etc... it doesn't matter.
The problem is twofold.
First, your skills in {something} are appreciating more than the other skills. If you're a web dev trying to transition to embedded, the skills as a web dev will let you get a more senior spot than going back to a lower experience embedded.
As a $150k/y web dev, would you rather go to $175k/y sr web dev or $125k/y embedded?
It's not that its hard - just that the skills that you've invested time into don't have value and you're going to need to go back to being "just" a competent programmer who needs to learn the domain for anything you switch to.
Secondly, there's the "why are you switching" problem.
If you are switching from web to embedded, the question will come up "why are you switching to a different domain." When that question gets asked, many candidates exhibit a more whimsical or capricious nature of just wanting to do something different. At which point the interviewer is looking at "competent, but likely to leave in a year or two because they got bored" vs "less experienced, but interested in the domain." The second candidate is probably a better choice.
The way to solve that is the personal project and demonstrate that you're interested in the domain at more than a "I'm bored with what I currently do."
This is a talent strategy at some companies (mine included). Our business model simply doesn’t allow us to compete for the “top” engineers. Our best engineers have been people who are just general technologists dabbling in solo projects within the business side of a corporate or working as the lone IT person at a small business. They have enough of the fundamentals to hit the ground running and learn quickly, but not enough experience to attract the big offers.
Are they mediocre developers? Yeah, absolutely. But under the right guidance they can absolutely be valuable to a company, and our turnover tends to be low because we have a 9-5 culture. It’s less about being a mediocre company versus a company that can’t compete for talent on price, so our talent strategy is to keep it a nice place to work so people want to stay.
> "I get the feeling that mediocre business should be able to run just fine on mediocre people."
The mediocre app/system quality and performance and mediocre security for customer and business data that results creates a (sub-)mediocre customer experience.
> For obvious statistical reasons most companies [...] are mediocre
That's assuming companies exist on a one dimensional spectrum. The more prevailing wisdom is that companies will be mediocre or bad at many things, and good at a couple of particular things, and those couple of things are what make the company viable. This is the essence of a "unique selling point".
But to the point: most companies don't need great developers. Nowdays most medium sized businesses employ some tech staff, but IT is not core to their business.
Because a person's worth is directly tied to how much value they can produce for their company's shareholders.
And if someone mediocre ends up being able to do the job, the company's management may face the fact that they're just a bunch of lame yuppies spending their life in the office to make someone else richer, not changing the world/making the world a better place/any other bullshit eaten from the trashcan of ideology (sniffff).
> Because a person's worth is directly tied to how much value they can produce for their company's shareholders.
Well, perceived value rather than actual value. Which might be pretty much equivalent in a field like Sales where it's easy to track figures, but much harder in fields like software.
And in the end, most people are near the centre of the bell-curve of talent, and still manage to produce plenty of value for themselves and their employer. Not everybody has to be extraordinary to keep the society ticking, and the perception that we should always be excellent isn't just counter-productive, but actively harmful (see what magazines did to people's body image).
Instinctively, they know it. The old cult of management-as-a-profession believes that by skillfully directing the activities of replaceable cogs, a company's managers can achieve outsized results.
But they can't admit it because they're afraid that knowledge would demotivate the replaceable cogs.
Most developers are mediocre, no way around that. And every developer was bad and mediocre before he became better. Companies that don't invest in employees don't really deserve performance anyway. Exception might be start-ups though, developers need to adjust expectations especially around pay.
I have seen enough software projects that certainly didn't fail because the devs lacked ability, there was always another reason and mainly that is leadership not knowing about the problem they try to solve.
A bit of an exception might be more artistic topics like video games. Here marketing and chance play a larger role than management.
Sure, maybe you do cutting edge research, here ability is important again, but that is truly exceptional.
That said, I don't think it is hard to get a job currently.
On top of this, it’s hard to select for qualified people because the vast majority of interviewees are terrible candidates. Truly qualified job applicants get callbacks for (almost) every job they apply for, choose to interview at a few select companies, and get offers from most of the places they interview at. Thus, they’re only briefly in the interview pool. On the other hand, unqualified people are constantly getting rejected at every step of the process, and must continually re-insert themselves into the interview pool, and thus comprise the vast majority of interviewees.
Because of this, the interview process is not designed to efficiently handle a minority of qualified candidates, but rather efficiently weed out a majority of horrible candidates. It is therefore a terrible process for the people actually qualified to pass it.
What's the "modern coding interview" trying to achieve? The other day, a guy showed me a 30-line convoluted, deeply-nested, redundant, and contradictory conditional statement and then rolled his eyes at me when I took longer than 5 minutes to parse it. Maybe I'm slower, but my quality is just fine.
Sounds like the purpose of that interview was to stroke the interviewer's ego. You should have asked him if that was his code, or was that code in production, then rolled your eyes back and left.
I assume the logic is that, at many/most places, the charlatan may actually be let go if they really don't work out whereas the person who is just "OK" will be allowed to cruse along indefinitely. Most companies aren't pro sports teams.
I get that's the logic but I think it's completely stupid. If someone is "mediocre" enough to scrape by that implies they are competent enough to get the job done. If they are not able to get the job done, then they are by definition a charlatan and will be let go.
>it's often very hard to get rid of them once hired
Every state in the US is an "at will" state, meaning a company can fire you with no reason as long as it isn't discriminatory towards a protected demographic.
I wouldn't be surprised if most of those states have laws for unfair dismissal as well. Companies develop an internal process to cover their backs for such eventualities. Running that process to the end is the costly bit.
Those who want someone removed are usually not the people empowered to remove someone.
Even complaining to their manager (which is often a bad move) usually wont result in the removal of that person
Even with at will, the company can get into difficulty with unfair dismissal and other issues.
The few times I've seen someone fired (and fired fired not PIP or layoff) have been for clear and undeniable issues. The "your work isn't up to performance standards" without a PIP falls into the rare bucket (and more likely at the small companies than the larger ones).
It's not hard, you say? Give us some pointers then? I'd appreciate a legacy code janitor job for a few years while still collecting $10k a month. I need the break from stress.
Getting the first few years of experience is going to be the hardest--hardest relative to the rest of your career; it's not that hard by any absolute measure. Apply broadly, and take whatever comes. If a company is looking for a junior or mid-level SE and wants "1-3 years" of experience (which is common), your degree is that experience. If you have a CS degree and are in a low- or medium-cost of living area, you should expect $60-80k to start. If have a CS degree and are in a high-cost area, you should expect $100k.
If you don't have a degree or experience, it's going to be harder. But why should a shortcut be easy? Is there a secret backdoor career path for people who want to become physicians without going to medical school? No. Do the work, and earn the reward. There are plenty of online and nighttime options for earning a CS degree.
If you apply somewhere and don't get a call back, don't sweat it, and don't take it personally. It just doesn't matter. Hiring is a noisy process, and the cost of a bad hire is tremendous. Most companies will try harder to reduce the number of false positives than to reduce the number of false negatives. Again, apply broadly and treat it like a numbers game. There are limits, though. If you've applied for 10 jobs and not gotten a single interview, pay a professional to rewrite your resume for you.
If you're getting interviews and bombing the technical questions, then study. If you're bombing the cultural/behavioral questions, read some self-help books and join Toastmasters. If you think you're acing the interviews and not getting any jobs, then you're probably bombing something but are too clueless to realize it. Hire an interview coach.
If you're at the point where you have a degree or 5ish years of experience (or ideally both), you are ready to be a $100k code janitor. Learn a common stack well enough to do smart things with it. For instance, if you learn .NET, you should be able to manipulate collections in interesting ways with a single expressive LINQ statement. Pick one from each category (but don't combine Java with SQL Server - I don't think you'll see it as much in the wild):
1. Java or .NET
2. Angular or React
3. SQL Server, Oracle, MySQL, or PostgreSQL
I'm going to offend a ton of niche fanboys now: Don't pick Vue, Go, Erlang, Haskell, or Rust. I'm sure each of them is amazing in its own way, but getting a job is your goal, so you don't pick a technology used by only 1% of employers.
Now I'll offend the embedded and systems programmers: Don't pick C or C++. They're just not widely used in business applications. I know both (at only an intermediate level), but I've never seen either used in a business application. You should know both on some level, but you're not going to get a Fortune 1000 code janitor job with either of them.
Congrats, you are now qualified for the majority of SE job postings at non-tech companies.
19.5 years of programming, but mostly web programming for the last ~12. I want to move away from that, I am sick of it already. There's always something more to learn and even though I don't mind at all -- it keeps my mind sharp which is something I want to keep all the way to my death! -- the churn of knowledge in there is exhausting.
> If you have a CS degree...
I am not from USA and have no degree. I am 41 y/o and I'm a self-taught programmer ever since 12 y/o. Not sure how well that flies on interviews; I feel the US companies put a lot of value on degrees?
> If you apply somewhere and don't get a call back, don't sweat it, and don't take it personally. It just doesn't matter. Hiring is a noisy process...
Completely agreed. I've been in a rough mental and physical health patch for ~3 years now and I've changed more employers/customers than I wanted. Tech hiring is completely broken indeed. You're quite right.
> I'm going to offend a ton of niche fanboys now: Don't pick Vue, Go, Erlang, Haskell, or Rust.
I am not a fanboy at all. I've used 8 languages over my career -- Elixir (stepping on Erlang) and Rust included and I've picked them based on their true, proven and testimonialized merits.
I don't take offense with your statement at all. I presume you meant "aim for something huge and somewhat commoditized that has a ton of legacy code to maintain"? If so, I'll agree with you immediately; there was a period during which I've been barraged by offers from German and Swiss companies almost every day, for months -- all for Java and C# huge legacy beasts.
But sadly that's not where my heart is. :(
Furthermore, I am willing to bet my neck most of those are NOT a code janitor job at all. They'll require a ton of time and attention every day. If I'll do that I'll just find an Elixir or Rust job but at least be happy with the tech stack (if not the area -- the webdev -- which I hate with a passion nowadays).
> Now I'll offend the embedded and systems programmers: Don't pick C or C++. They're just not widely used in business applications.
I haven't been an active C/C++ programmer for like 12-13 years now but IMO you're not on the mark here: there are a lot of business apps but they usually belong in huge old mastodons that are too stubborn to move on (I personally know the VPs of engineering in two such companies!).
But overall you are right -- they are niche but not the good kind of niche; you need a metric ton of battle scars to even qualify there.
> Congrats, you are now qualified for the majority of SE job postings at non-tech companies.
I'd agree but I've neglected networking -- both physical and virtual -- for most of my career and now at 41 y/o I started to feel the negative effects of that. :|
> 19.5 years of programming, but mostly web programming for the last ~12. I want to move away from that, I am sick of it already. There's always something more to learn and even though I don't mind at all -- it keeps my mind sharp which is something I want to keep all the way to my death! -- the churn of knowledge in there is exhausting.
The churn of knowledge can be limited by choosing technologies that don't require constant adaptation. (Time to offend the .NET fanboys): If you pick .NET, there isn't that much difference between .NET Framework 4.5 (from 2012) and the latest version of core. The job still gets done, just with a different set of packages. If you don't have a use for async/await or the TPL, you can go as far back as 3.5 (from 2007).
> I am not from USA and have no degree. I am 41 y/o and I'm a self-taught programmer ever since 12 y/o. Not sure how well that flies on interviews; I feel the US companies put a lot of value on degrees?
Some do, but with 19.5 years of experience, this wouldn't be much of an impediment for you in the United States. All of my opinions apply only to the United States. I haven't worked in other countries and can't comment on them.
> They'll require a ton of time and attention every day.
IMO, a "code janitor" doesn't just sit around all day reading HN. When I use those words, I mean the type of job where you're expected to fix bugs and implement features and not much else. Even if there is talk of higher expectations, there are never any consequences for just going with the flow. You'll rarely/never be asked to work overtime or learn on your own time. You'll only pay lip service to clean code, clean architecture, and long-term thinking. You'll still be expected to show up by 9, hang around until 4, and not screw off the whole time. The job is still a job; it just doesn't strain your brain.
> I'd agree but I've neglected networking -- both physical and virtual -- for most of my career and now at 41 y/o I started to feel the negative effects of that. :|
Headhunters are the antidote to this. When a recruiter wants to connect on LinkedIn and have a short phone conversation about an exciting new position, you always say yes. And if they're not sending connection requests to you, then you send the request to them.
> IMO, a "code janitor" doesn't just sit around all day reading HN. When I use those words, I mean the type of job where you're expected to fix bugs and implement features and not much else.
Yes. We are on the same page, just using different words.
I definitely didn't mean "slacking off". I meant exactly what you said: have 3.5 to 4.5 hours of good solid programming work per day (because realistically that's what most programmers cover in terms of actual focused productive time in the standard 8h work day) where you have already ticked the boxes (or nobody cares about them as you said) so you just pull stuff from a backlog and move at a steady pace with not much supervision.
The company I am very soon starting with has people I like very much, plus I love what they do. But if that turns sour then I'd likely be looking for 2-3 "code janitor" jobs in parallel in order to protect my mental health for a while.
> When a recruiter wants to connect on LinkedIn and have a short phone conversation about an exciting new position, you always say yes.
Maybe you are right. To me outright insisting on a phone call is very disruptive and out of place. I've tried it several times and maybe I drew the short end of the stick every time but they all were young and fairly clueless HRs who just wanted to parrot their speech that was supposed to motivate me and then immediately pressure me for an answer. Don't know, didn't find that a good expenditure of my time.
Maybe I am doing something wrong, I am open to that, but I really am not sure that I want to expose myself to such toxic time wasters. Any advice?
> But if that turns sour then I'd likely be looking for 2-3 "code janitor" jobs in parallel in order to protect my mental health for a while.
Oh, I wouldn't try to juggle multiple code janitor jobs. It only takes one good one to pay my bills. And it would defeat the benefits that I perceive in the code janitor job. If someone wants to put that level of effort into his career, he's better off aiming higher.
> Maybe I am doing something wrong, I am open to that, but I really am not sure that I want to expose myself to such toxic time wasters. Any advice?
Ask for the client and salary range immediately. If they don't give you a straight answer, politely end the conversation.
It depends on the type of recruiter. If you're working with an external recruiter (like an agency recruiter), they're not going to do that. They'll just give you the client's expected salary range. I've never had an external recruiter play this game with me.
If it's an internal recruiter, you might get that question. In that case, have a good idea of what you're looking for, and throw out a number at the top end of the range. If you're talking about a senior software engineer job, and you know that, in your area, they generally pay $120-150k, then say $160k. If you want, condition it based on total comp and benefits. Most Fortune 1000 code janitor jobs will offer a nominal bonus, anywhere between 5-20% of salary. Nothing like the huge FAANG bonus structures. But saying "depending on TC and benefits" gives you some leeway to ask for something even higher later on. And it tells them that, if they can pay you $150k plus a 20% bonus, then you could be happy with that. It leaves the conversation open.
If that makes them walk away, then you didn't want to work there. And don't feel bad negotiating like this even if you're going for a code janitor job. Compensation correlates with negotiating skill more than software engineering skill. It's just the way things are.
Hm. Mostly what I expected then. With one exception: I am in the EU so here $120K a year does not exist. Not even $100K is easily achievable although I've commanded the equivalent of ~$90K a year and will soon work for the same figure.
So I started wondering if I can pivot to the US market -- which was never a goal.
I appreciate your advice. Insecurity and the impostor syndrome can hit even super capable people (I've seen it). Your words help me reassert my self-confidence, and that's sometimes shaky. :)
Retirement, healthcare, and taxes eat up a significant portion of a US earner's pay.
The amount of money that actually gets delivered to a worker's bank account could be a little as 2/3 of their stated salary.
And many things cost more here.
It'd be a good idea to work the numbers and figure out what your take-home pay would be and how your expenses would change. There are some expat websites devoted to this.
You have to move there. Even if you put it up front in your resume (they usually only read it 30 mins before they interview you). None of these companies want to hire from another state. As you can not 'start tomorrow'. Even though they will have these positions open for a year or more.
Be up front you about what you are doing. They are going to think 'he is going to jump at any time'.
Be willing to stay there awhile. But be warned some of these places there may be one to two 'big companies' that hire there (and if they do not hire you are SOL). There may be some small startups here and there. So plan on that. There may not be much to choose from there for you. It is why many move away from those areas. So if you are 'lucky' enough to get into one of the companies do not plan on jumping around a lot. You will burn bridges and the community of devs is small there, and they talk.
Be willing to dig into some seriously legacy code. "oh we still use sourcesafe and vb5". The Joel test is a good indicator of how strong they are. "oh we buy the best for our devs" and the computer on existing devs desks is some beige box from the late 2000s with a CRT.
Set your pay expectations much lower than what you are used to. Had one I was looking at, I was one of 3 people who applied. He passed me over because 'I was not in the same state'. I had 5 years 'full stack' exp on the exact type of system he was working on. After a bit of back and forth they wanted to pay nearly half of what I was looking for. Which was not terribly out of line for that area. Another dude thought he could snag me for 1/4th what I wanted. These guys can be cheap. They have a product someone tinkered together years ago. But they do not have enough income to really justify any sort of real work. So they do what they can and usually just farm it out to some consultant group.
> You will burn bridges and the community of devs is small there, and they talk.
You've hit the nail on the head here and this is my main worry. I've been much more selfish lately (last 3-ish years) and I know I definitely did burn some bridges but I can't make myself care very much -- I am 41 y/o and at one point participating in a one-sided "exchange" of trying to appease while mostly humiliating yourself becomes impossible to swallow (but then again, I recognize I've had both shitty luck and self-selected bad employers due to personal drawbacks that I am still actively fighting with).
> Be willing to dig into some seriously legacy code. "oh we still use sourcesafe and vb5".
One of my strongest selling points as a senior dev is that (a) I don't mind dirty and heavy work at all, and (b) I have an excellent eye for detail, very rarely miss something and (c) I try to leave the code with better readability after I finish my current task on it.
That being said, many companies are too impatient. I've hit the brick wall of "we want somebody who can hit the ground running and we won't provide any training" personally at least 5 times in the last 3 years. And I seriously don't know what to do about that; I certainly can't know all tech stacks and domain expertises on the planet!
And it's flabbergasting how much in denial many companies are about the risk management aspect. I mean they know; they absolutely know what's going on but they concluded that training new hires is a huge business risk (due to most people never staying more than 2 years on a job) so people like myself -- even if senior and very experienced -- have literally 1% chance of getting hired in many such places.
They do have a point and they are mostly acting rationally in this situation; but they could still spare some minimal training so they stand to gain a bit more from the employee that's going to move on maximum 24 months after being hired. One or two months of training isn't that expensive for them I'd think.
> These guys can be cheap. They have a product someone tinkered together years ago. But they do not have enough income to really justify any sort of real work. So they do what they can and usually just farm it out to some consultant group.
I am realistic about that aspect and I accept it. If they wanted to pay top dollar they'd just court somebody who is 45-50 or more for several months and then do their very best to promise them retirement in the company and all the good stuff that a long stay can benefit the person.
I know they want to pay less but I'd aim for having 3-4 such customers, independently, and collect a 120% - 200% of my normal payment combined through such venues. Not always sustainable in terms of mental strain and energy but I've pulled it off successfully even as shortly as 9-10 months ago without being hugely taxed in terms of health.
RE: the consultant group trope, I suppose this is where I fail in terms of marketing. Many companies just can't take a single random person seriously even if he's John Carmack in disguise. I suspect I need to make a fancy consulting website with some fake testimonials and pretty graphics, have a photo in a rented suit and then I'll suddenly be taken seriously. People can be very shallow and easy to manipulate, huh?
I am a bit flippant here but I likely should indeed work on marketing. But how does one strong and senior single programmer advertise themselves as a consultant or, generally, a guy you go to to solve a business problem, and who is not a wage lemming? Got any pointers on that?
The consultant thing is usually a matter of budget. Hiring someone is the personal budget that has had an increase of just enough so everyone does not flee and zero real room for a new head. Yet a consulting budget is from a 'different bucket' and can usually scale up and down quickly. Those are taxed at different rates and depending on their accountants how it will work out.
For your last Q I would say a lot of the same points still matter. They are going to want someone 'local'. Someone who can come in on a moments notice when they are in the thick of it. Also keep in mind a business is not programming. I would suspect what you are really asking is 'how do I sell things'. That is a much different topic. But targeted advertising, cold calling, trade shows, emails to former and clients and colleagues. It may be worth looking into hiring an advertisement firm for some small ideas. Do what you want your customer to do and hire an expert. If you do not have the cash for that you are going to have to do it yourself. Your personal network is probably your best bet for starting to grow your business network. My dad a former insurance salesman spent a lot of time in bars selling and meeting people. They had hundreds of hours of training they took to be any good at it. It may even be worth getting a short part time job as a salesman to get the idea of what to do. Think of it as just as there are jr devs you are jr salesman. But keep in mind, there are several types of sales. Those that sell themselves (they were already going to buy it, it is just from who that matters). Those where you need to work the sale. This is the harder type. You have to basically sell yourself to them. This is either showing them they have an existing need that is not being fed, or faking it by 'creating' a need they did not know they had. Another way is to associate yourself to one of the consultant groups out there. They take a cut but can help with lead generation.
I see many, many more developers lamenting the "requirement" of a CS degree to get a software development job than I see lawyers lamenting the "requirement" of a law degree for a law job or doctors lamenting the "requirement" of a medical degree for a doctor job. If it opens doors, and you want that door open... get the degree!
Because developers want it both ways... they want the benefits of a job that makes money while also not wanting the requirements that those jobs usually require.
CS Degrees from local universities can be had for far less cost than a 250k law degree and less time than a 13 year MD.
This year I became a co-owner of the company that worked at for the past three years. It's a small development and consulting company and we're currently struggling to find new developers. At the same time, my girlfriend is trying to get her foot into this field. Since she's interested in a completely different tech stack than what we use, hiring her through good ol' nepotism is not going to happen. This situation gives me a small glimpse into both sides of the whole equation.
Before I continue, I want to point out that no side is at fault here. It's just market forces at play.
So why don't companies want to hire newcomers? It's simple, really. It's never worth it.
Even newcomers want competitive salaries because bootcamps, popular media, etc. paint the picture of a career in software-development as being extremely well-paid and with great benefits. This picture is absolutely true -- for senior developers.
Meanwhile newcomers need to be trained and built-up, often with intensive mentoring from senior staff. In general, there's nothing wrong with that. I had a great mentor and in turn I love mentoring. But once they've gained know-how and experience, they will look for a different company hoping to use their newly acquired commercial experience as leverage to get better compensation. And that's exactly what they should do! Trust no employer that talks about crap like loyalty.
Leaving your first job after max 2 years is something I would recommend every new developer. It is what the legendary Andrew Hunt (author of The Pragmatic Programmer) recommends in this podcast episode. If your first employer gives you a hefty competitive raise to keep you, use it as the new base for negotiations and still try to switch because, as Hunt puts it, at the beginning of your career it's crucial for you to expose yourself to different technologies. Maybe you'll start out as a web developer only to find out after your first job switch that you're much happier in embedded systems. Switch jobs often. Forget loyalty.
But what does that mean for employers? Let me explain it with a few of our cases. In the past, we tried hiring newcomers multiple times. In the most recent case, I was the senior responsible for the new hire. I spent up to 16 hours per week on one-on-one training in the first 6 months to get them up to speed in anticipation of a big project. They left us after 14 months for a different job in the middle of said project. I do not blame them, it's the exact right thing to do. For us, this was our third failed attempt of hiring newcomers and it was frustrating and extremely costly.
Since we're a B2B company creating software for IT departments, I asked around to see how our clients approach this whole situation. And the consensus is, "We refuse to train the future employees of our competitors. Hiring newcomers is a waste of resources. Paying the premium to get senior developers is always better."
Especially small IT and software departments/businesses cannot afford training people who will just ditch the place within 2 years while big players like the FAANG companies can and have their pick from the very best newcomers.
As a result, entering this field is incredibly difficult and one has to essentially hope a company is dumb or desperate enough to take the gamble of hiring someone trying to get into developing.
So how can this be fixed? Well, I don't think there's a fix. Most newcomers will never find a job and quit trying to enter this field, the lack of senior developers is going to hurt small and mid-sized companies in the long run and many of them will eventually disappear from the market as their current developers are reaching retirement and cannot be replenished. Only newcomers who give the impression that they don't need extensive training will ever have a chance to get hired. As such, my recommendation is portfolio is king.
Small, not tech heavy companies like simple webshops, small crowdfunding platforms, etc will need someone, ANYONE, to keep working on their giant stack of legacy PHP/Rails/whatever code. The business does not support hiring very senior people and the founders are not technical at all so they don't recognize the troubles inherent in hiring a full team of juniors.After a few years the business may fold, but at that point the junior devs have gained some experience and move onwards and upwards. The attitude of "We refuse to train the future employees of our competitors.", while not un-true, fails when you can't even hire seniors.
I have done so with several big codebases, so I know that you speak the truth here. Putting junior devs in charge of a tire fire is only going to make such a codebase worse. But most of the owners of such businesses do not recognize it and only call in professional help when the business is already at the verge of collapse.
It's a hard fit for seniors even. Legacy is hard, big codebases are hard. You'd have to be crazy to let juniors take over such a thing. I think a junior might actually do better on a greenfield project if deadlines aren't too strict.
I actually agree with the practice, and generally don’t think you should be employed to learn the basic tools of the trade.
First there’s a code fluency wall you have to get over.
Then there’s a tech debt/spaghetti lesson that needs to be learned (IMO this can only be learned the hard way)
I did this with 6 months working on my own stuff 12 hours/day, then 6 months working for nothing but equity in a never gonna happen startup.
Once someone is over those two walls, they can be useful to a company. Absolutely never writing greenfield stuff, but maintenance, matching style, very clear start and end type stuff for at least a year.
Before you’ve internalized code as a fluent language and developed basic code hygiene, you should not look for a development job. Even if you get one you will be an imposter.
>I actually agree with the practice, and generally don’t think you should be employed to learn the basic tools of the trade.
In what other technical field are you expected, post-school (which probably hasn't taught you a ton of practical skills), to spend a year on your own making yourself employable?
In medicine you spend a decade making yourself employable. The on your own part is a luxury and a curse, in that we don’t need patients to practice on.
The closest comparison I have is professional musician.
you’re supposed to love the language of music. If you don’t, good luck.
The view of some that software has to be this all-consuming thing from a young age if you want to be any good at it has a great deal in common with the arts.
And very little in common with how most people treat other technical professions.
It has a lot in common with other fields (most of which sure, are not “technical professions”, but that's because this is not about broad content) in which there is an oversupply of talent at the low levels, regardless of the conditions at the top of the industry.
The reason is because — between the people with the genuine love of the field plus those drawn in by the lure of the high-end pay — there is such an oversupply.
Sure, because software is both an art and a science and draws a lot of comparisons with music where you have to understand the technical theory, the creative and also be comfortable physically playing an instrument while having some level of understanding the digital domain (MIDI etc).
Software also sits at this technical/creative/implementation intersection where unless you're doing something very specific, you're going to need to push/pull in different directions.
A lot of software doesn't do anything exciting, standard office CRUD, dashboards, back office tools can be banged together by a single developer as long as they can connect to a database, render a UI (web/desktop) and take requirements from the business.
There's a lot of software jobs which aren't at software companies but regular businesses who just need to track something domain specific and can't afford to tender.
I will say that I've hired a couple of newer developers and in some cases they've moved on, but in other cases they've stayed with the company I was at when I hired them, in some cases for 3+ years. So not everyone leaves after 2 years.
I think that companies need to be really explicit about their training and goals and try to make employees happy. Yes, that bootcamp grad is going to be super happy to work for you for the first year, and grateful to have the experience. But, yes, they are going to start looking around. So plan for how to meet their needs as best you can. Some folks will simply be on the hunt for difference and comp, others will be happy to stay at the same company if you can challenge them and continue to let them grow.
> ... at the beginning of your career it's crucial for you to expose yourself to different technologies
This is one reason I feel like a small consulting shop is the best place to start a software development career. You matter (because it is a small shop) and you'll get exposure to many domains and technologies (because it is a consulting shop).
Apprenticeships in a trade tend to be such that with sufficient hard work and determination, anyone can fill the trade requirements. The problem solving skills of software development don't seem to fit that model - there are some people, no matter how much you train them, don't seem to be able to move beyond "follow instructions" to "give tasks" when it comes to developing software.
The second part is that the trade has a bonded period. Depending on how that is written, this becomes more difficult to enforce with at will employment. It can also lead to companies taking significant advantage of their bonded juniors. I mean... if you think this is a good model, revature is out there.
> Apprenticeships in a trade tend to be such that with sufficient hard work and determination, anyone can fill the trade requirements. The problem solving skills of software development don't seem to fit that model - there are some people, no matter how much you train them, don't seem to be able to move beyond "follow instructions" to "give tasks" when it comes to developing software.
The trades face the same challenge. Over the past decade, I've gotten along well enough with my HVAC guy (one-man shop who brings on a rotating cast of apprentices) to talk with him about this. He reports the same experience ("no matter how much you train them, don't seem to be able to move beyond...").
This isn't a case of "can / cannot solve problems", either. For hobbies they delve in, that cohort appears to problem solve extremely well. I suspect the challenge is finding ways to communicate a mental model of the same problem domain that "clicks" with different personalities.
I'll start off with apologizing the "trade" comment - in my mind I was more thinking the landscape / basic construction. I hadn't really thought about the mental model of hvac.
The "skilled trades" with hvac, electrician, plumbing, carpentry and such where the apprenticeship is more appropriate do have that issue again.
There are people, for whatever reason, can't accept a different mental model than what they've got in their head. Software development is about twisting how you think to that of how a computer works.
I've presented this very light model of "levels":
A junior follows instructions
A mid completes tasks
A senior solves problems
There are people who plateau at each level and never go beyond that for whatever reason. In many cases it is a failure of putting the proper problem solving / learning skills in place to be able to think in a way that isn't the easy way.
Which is more a symptom of bad apprenticeship and i believe we don't acknowledge enough that there are too many shops doing a bad job on training the apprentice.
* How do we ensure that a non-predatory apprenticeships are able to keep their staff for a long enough duration that they're not losing out?
There is a part B to the first question on preventing predatory apprenticeships. There was an anecdote told on reddit of a person who was trying to get out of tech support and so signed with Revature for becoming a software developer, went through their bootcamp and then got placed at a company. That company found that he was rather skilled at doing tech support (rather than as a junior dev) and so moved his contract over to do tech support... getting paid less than he was getting paid doing tech support prior to joining Revature. Furthermore, the locked in two year contract meant that he did tech support for two years. At the end of this, he's got two more years of tech support on his resume that paid him less than what he was making before and no additional software development accomplishments.
So yea... Predatory apprenticeships are a problem.
The way that the "stay around long enough" of old was a signing bonus. When I started in '96 with Taos ($54k/y), I got a $5k signing bonus and $1/mile moving bonus (Mapquest was a new thing - HR was amazed at how much easier that was going to make their job in calculating the moving bonus). If I left before a year was up, I'd have to pay it back.
That works reasonably well enough when salaries are about balanced overall. But it works poorly when there are some jobs that can either offer a much larger bonus or the new pay can quickly repay the bonus. If you're making $75k/y and have a $10k bonus to repay and then get a job for $150k that bonus can be repaid within a month or so (by the time accounting sends out the "pay us back" the bonus is ready to be paid back with the increase).
> But once they've gained know-how and experience, they will look for a different company hoping to use their newly acquired commercial experience as leverage to get better compensation. And that's exactly what they should do!
I disagree here, and I think this is the main reason we're having this conversation. If someone has been trained up or learned on the job such that their skills are more valuable, then their employer should treat them as such and give them a raise.
I've seen time and time again that good employees leave just to get compensated fairly. Alternatively people get disgruntled and leave when an experienced outside hire is brought in at a higher pay band to struggle to do the same work that they've spent years learning to do.
>I spent up to 16 hours per week on one-on-one training in the first 6 months
This is crazy. If the junior needs more than 1 hour a day to be net positive (= do more work in the remaining 7 hours that you would do in that lost hour) then I would say they are a lost cause.
This is also so easy to filter at the interview level - give them homework to learn some new skill, junior candidates are generally willing to spend significant time on that and it gives you much better picture of their abilities than whiteboard puzzle.
It feels like there is an attitude here that you should be able to recoup the cost of training a junior hire by paying them below market rate for for their new skills. This just isn't reality, as OP has discovered.
That means that the true cost of a junior candidate vs a senior candidate isn't just their 1st year salary difference on paper, you have to count in the cost of training _and_ retaining the junior hire. That doesn't necessarily mean the math doesn't work - especially if the market for senior developers is much tighter than for junior developers.
Also the idea that you'd be mentoring for 16 hours a week one-on-one seems like it is either inflated or there was a problem. Maybe the candidate was a bad hire even for a junior role, or the mentor is micromanaging, or the work product expected was never appropriate for a junior developer - but something seems off there.
I think this article gets close, but glosses over one of the major issues in software dev hiring: the filtering process is all wrong.
Front line recruiters tend to be non-technical, and can't pattern match for good candidates outside of very narrow criteria. (ex: They won't know that a person with strong C# skills will likely be just fine with Java.)
Just getting your resume in front of actual people doing the hiring is hard. My experience is that if you want to make it easier to hiring talented software engineers you need to make it easier to get the right candidates in front of the actual hiring team.
I think this is part of why getting hired through connections is even more important in this field, and why it's also interesting that so many members of the field look down on that very process.
I agree it's not very meritocratic, but it DOES get people in front of people more qualified to pattern match their qualifications more quickly.
The problem with getting more people in front of the actual hiring team is the "charlatans" other people have mentioned in this thread will effectively waste the (very expensive) time of said team. Using a (less expensive) recruiter as a first stage seems rational until you discover the high rate of false negatives.
I've mulled this problem a lot and I still come up empty on a new, more effective way to solve it.
> getting hired through connections (...) it's also interesting that so many members of the field look down on that very process.
I think the explanation is quite obvious. People who gravitate to this industry are not as social as those who gravitate to other industries, hence the disdain for (or rejection of) the process that leans heavily on something that doesn't easily come to them, that feels like something they shouldn't have to be dealing with.
I'm not sure it's so much a case of social vs. not-social though some of it probably boils down to that. I think it's more of a rationalist viewpoint that the "best" person should be hired rather than a merely "good" person who knows someone who may put their thumb on the scale.
> Front line recruiters tend to be non-technical, and can't pattern match for good candidates outside of very narrow criteria. (ex: They won't know that a person with strong C# skills will likely be just fine with Java.)
Sounds like a problem with the job description, rather than the recruiters.
Sometimes you really do want an expert in a narrow domain, using a specific framework/language. Other times you don't. This needs to be communicated to the recruiters.
Engineers love to lay the blame on the recruiters. In my experience, the recruiters are usually just a mirror for what the hiring managers are asking for. If the hiring managers do a poor job of defining the role, then how do you expect a recruiter to find good candidates for that role?
If Java and/or C# experience works, communicate that to the recruiter. Don't just assume they will know. Even as an engineer, if someone asked me to find a Java candidate, I would find a Java candidate. I would not make assumptions about what other experience would fulfill the requirements.
As far as filtering being the problem, I highly doubt it. Most of the complaints I hear from people are about the interview process. I know a few engineers that can't get hired, and it's not because of a lack of interviews. They just can't pass the interviews.
I’ve just interviewed at 4 places. None had technical recruiters; I was contacted and went through the process with the hiring manager.
Same nonsense though; here’s some random leetcode problem; sure our company hasn’t made anything novel or proven itself in the market but we Googled how to do a tech interview and this is what we found.
Getting a job is hard because people are lazy. They’re just regurgitating what popular companies are doing, whether it’s good for them or not.
Recruiters are non-technical in every business though, why would we need special recruiters for programmers when we don’t need special recruiters for neurosurgeons?
I think a lot of this is because our profession does not have an accepted universal bar everyone can jump over to be considered ‘qualified’. Every technical interview feels like rolling the dice in proving I am a competent developer. Giving me 50 minutes in a high pressure situation in an environment i am unfamiliar with and people I just meet will never product my best results, and then add to the fact that I could be asked any question, and my ability to answer is it being ranked against other candidates. Maybe someone else _just_ did a similar question in another interview and it’s fresh on his mind. Maybe someone spend their entire career focusing on just this type of problem given in the interview, but the question in the interview is only partly related to the actual job.
In many other fields (medicine, law) people study a standardized body of knowledge, take a standard test and then get a license so they can do something others cannot.
However, this doesn't prevent a lot of awful and a lot of great people getting through. You would still need to interview a lot of them. I wonder if it sets a minimal level.
For the top law firms, things are pretty straightforward. You have to pass the bar, there's the school you went to, your class rank at the school, internships and clerkships, and then associates are largely up or out.
I assume it actually works pretty well but there's obviously a huge amount of gatekeeping involved.
That all makes sense, and it bothers me, too, but they do hire somebody eventually, which implies that somebody can produce quality results in 50 minutes in a high pressure situation in an environment they're unfamiliar with and people they just met.
>implies that somebody can produce quality results in 50 minutes…
This is more a random fluke as much as sampling bias. Akin to someone either getting lucky or someone who is coming from a very similar environment. This isn’t a measurement that guarantees someone is competent, rather it’s a guarantee that someone is coming from just as incompetent an environment as you have.
Note: This depends on hiring style. Some companies have a bar and everyone who meets that bar is hired. Other companies are hiring for a position that gets one person...
These results may be "curved".
If you give the same easy test with no pressure and everyone is sufficiently good, then it was a waste of everyone's time.
In such an approach, you do something that is sufficiently hard that you're able to identify the people who are the better performing ones along with a reasonable idea of how well they work under pressure (because that will happen at some point).
Is it testing the right thing? Probably not. However, we still haven't found "the right thing" that is able to scale, respectful of the time of the candidate, not too intensive on the interviewer, and minimizes biases in hiring (same set of questions to all candidates, same grading scale).
> Is it testing the right thing? Probably not. However, we still haven't found "the right thing" that is able to scale, respectful of the time of the candidate, not too intensive on the interviewer, and minimizes biases in hiring (same set of questions to all candidates, same grading scale).
Maybe because the concept of a test is flawed? It seems to me like every company that uses a whiteboard test gives out the same tests anyways.
What are they really trying to test? If someone understands common algorithms and data structures? I dont see why that couldnt be determined by a simple interview with an engineer. A test might be useful for a HR recruiter who doesnt have a computer science background, but those tests are usually conducted by other engineers anyways.
The whiteboard thing just seems to me like an arbitrary hazing ritual.
Or they just hire the guy they knew through their network. A lot of "how to beat the tech interview process" advice is about how to break down the door with a battering ram when you don't have the key.
This is fairly true. The easiest side-door if anyone is wondering is a recruiting firm. At least with those there is already a somewhat simple contract in place that helps get rid of poor people.
I am wondering if the entire interview process should just be pay them for 2 weeks and see if they stick.
> If you're going through the front door, you've already lost.
I've heard that advice in various forms but I must say (anecdote incoming) - in my own 30 year career, the best jobs I've ever had were the random ones that I just applied for and the worst ones were the ones that somebody I knew from before recruited me in from outside.
hmm, I guess I can say a reasonably good one and the worst one ever that almost made me quit programming came about this way. The same guy recruited me in both places.
How many jobs have you had? You talked about the best and the worst. Can you comment on the relationship between (y-axis) quality of job and (x-axis) strength of personal connection before you joined. If you plotted a scatterplot, what relationship would you find?
I've changed jobs ten times since 1992. As it works out, exactly half of them I was recruited into by an internal reference and the other half I found on a job board like Monster or LinkedIn. By far, the two best were relatively large organizations that I applied to cold, and the two absolute worst were actually the ones I was most actively recruited into by former co-workers. I suspect that the problem in both of the latter cases was that they worked so hard to bring me in that they ended up overselling me - I'm good, but I'm also a human who has two kids to look after. On the other hand, if I'm "just" the best candidate from the pile of resumes, expectations seem to be reasonable.
Very few people hired at big tech enter through their network without a technical screen.
Speaking only of ICs:
From principal engineers down, there's a technical screening. Distinguished engineers? Maybe. But then you're speaking about Guido van Rossum, James Gosling types.
I was a hiring manager at Facebook, and even when there was someone we specifically wanted to hire, they still had to do the same coding interviews that a new college grad has to do.
I have done that in the past, and I've failed miserably in the past as well.
Am I on the top of my game right then and not stressed about anything and the questions out of the random million possible questions that could come up are ones that I just happen to have had on my mind recently? Then I ace the interview.
The last time that happened it was in a big international consulting company, they then put me through 5 other interviews afterwards, each one telling me I would hear something back in the next couple days.
The last one I got told couple more days, they didn't call me back for nearly two weeks. Then they call: Hey Bryan, we would complete the offer process now hope you're still interested?
Uhm unfortunately I got an offer last week for a 6 month consulting project, sorry but I had to take it because they said they couldn't wait to see how this turned out.
I did an interview with Reddit - whom I hope sees this comment - and they not only provided zero information about the context of the tech interview in advance, or whether it would be one, but also the interview itself was like playing a random version of tech Jeopardy, but without the category columns, and very few of the questions had anything to do with the job I would be doing.
I have over 20 years of programming experience, am a founder, and have worked for multiple venture backed startups. That includes hiring countless developers, so I get both sides of the situation. And my partner is also a tech recruiter for a top tier HFT / market maker, so I know what a demanding but respectful hiring process looks like.
Reddit’s hiring process converted me from a fan of the site into someone that thought the entire organization was second tier - which obviously it is in terms of monetization - but also in how they treat people compared to the FAANGs. And a year later the role is still open.
I had a similar interview with a different company last year. Three guys and me on a Zoom call with me sharing my screen trying to solve a coding problem that in no way resembled anything I have ever encountered in my 25 year career. When I got stuck they just stared at me. They would not give me any hints whatsoever. They just stared at me.
When the interview was over I thought, "Is this how working with these guys is going to be?" If I ran into a problem and went to them for help, would they just stare at me, waiting for me to figure it out on my own?
They didn't extend an offer to me and, based on my performance in that interview, I can't say I blame them. I'm not sure I would have accepted if they had, however. That experience really left me with a bad taste in my mouth and a low impression of that company.
We as an industry really REALLY need to figure out a better way of conducting interviews.
"Is this how working with these guys is going to be?"
Unfortunately, yes. Young engineers are terrible at communication and working with others. Partly due to workplace incentives and partly because you must realize that entire generations have grown up with computers and not people.
I don't think this deserves the downvotes it is getting simply because there is some truth to the comment.
A good friend of mine worked with a young developer recently who was excited about what he was able to generate with a single npm command. When my friend, who has been writing software longer than this guy has been alive, calmly pointed out that the npm command had just generated 400 files and thousands of lines of code that didn't actually solve their problem, this guy got mad and went to complain to their manager.
In all honesty it's not just younger developers. I have worked in plenty of companies where the idea of "communication" needed to be stressed and would of fixed many problems and saved a lot of money.
In a cut-throat environment, where 10% of people are PIP'ed, it is expected: your senior colleagues are not going to help you, will lead you down a wrong path, etc. That way, the tribal knowledge will be with them, and they can outshine any new employee.
In your interview case, they should have given you hints, even if they want to not hire you later.
I know some MIT labs work that way. Backstabbing people b/c there are only so many upper positions instead of titling and paying people their skill level you would have to wait for someone to retire.
Nothing about tech interviews is a signal for what happens inside the company, aside from you having the dual role of giving tech interviews while you forgot to factor that into your sprint planning
You’re making the same mistake at vetting them that they’re making at vetting you
You are simply determining that you are okay with false negatives
Which is exactly why they do irrelevant interview brainteasers as well
This problem is a two way street in the tech sector, in case anyone wanted to fix it. The candidates alone are making the same mistake and bringing it to the company
It is a determination that something should be rejected, when it really should have been accepted.
Similarly, a false positive is something that was accepted, when it should have been rejected.
If you have a sufficiently high candidate pool. you can (for a while, at least) live with an interview process with a relatively high false negative rate (that is, x% of the time you don't hire people you should have).
If it is typically quick to go from "in through the door" to "is a productive member of the team", it may be that you can live with a high false positive rate (that is, y% of the time you hire people you shouldn't have).
Honestly, these are the reasons I don't look for a new position.I make "good" money, but by no means great. I have the benefit of 20 years tenure and apparent stability in my current role. Trading that for more stress in hiring and gambling more stress in daily work doesn't balance the potential salary increase.
I've never understood the heavy emphasis on in-interview coding or brain teasers. To the extent that I've participated in the hiring process (both as an IC and a manager), 80% of the interview is assessing culture/personality/ethic fit; that is, the basic "do I want to work with this person" question.
The technical competence check is all retrospective, hearing them talk about prior projects and what the design and implementation process was like, how decisions were made, what the challenges were and how they were handled, any regrets/learnings. And most of that is just digging in far enough to confirm that the person was actually a first-class participant in it with a deep understanding, and not a bystander. Any whiteboard stuff would be "show us how the system worked" as a last-ditch check on basic communication skills.
You know, I was nodding my head in agreement as I read this when something occurred to me.
This all requires that the interviewer be willing to interact deeply with the candidate. Our profession has a (well deserved, I think) reputation for having a high percentage of people who really don't like interacting with others on a peer level.
Is it likely that a large part of the problem is that we have people doing interviews who really shouldn't be? I mean, if your typical response to talking to another technical person is immediately to try to one-up them, then you're going to be a really shitty interviewer. And that's exactly the personality type I see being described over and over in these anecdotes.
Not sure about English, but in my language we have a saying "The fish stinks from the head"
I can tell you, with quite substantial sample size from me directly and from people I deeply trust that every time we encountered an interview like this, we later found out that the company culture was really bad.
Those are not the kind of people you want to work with.
For clarity, is the "like this" in your comment referring to brain teaser technical one-upmanship interviews, or the less structured style that is focused on getting to know the person and having them describe in their own words the projects in their past?
> I had a similar interview with a different company last year. Three guys and me on a Zoom call with me sharing my screen trying to solve a coding problem that in no way resembled anything I have ever encountered in my 25 year career. When I got stuck they just stared at me. They would not give me any hints whatsoever. They just stared at me.
> Not sure about English, but in my language we have a saying "The fish stinks from the head"
English has this expression too, except it's "The fish rots from the head". (Which, when you think about it, makes more sense.) What's your first language?
> if your typical response to talking to another technical person is immediately to try to one-up them
The psychological reality behind all this is even worse.
The interviewer is not looking for new colleagues, he is looking to improve his own self-esteem and rank. The reward for rejecting a candidate is a feeling of superiority and an appearance of being irreplaceable.
The interviewer and the candidate have opposing goals, and the interviewer can randomly change the rules at any point.
Ugh, that's horrifying. I don't think I've been the interviewer and not felt the exact opposite, like "I'm desperate to have more people on the team ASAP; do we satisfice here and make it work or hold out?"
But then I've always been interviewing for my own future colleagues/boss/reports. I guess the dynamics could be different if you're in a huge company and just generically interviewing for new cogs that might get slotted anywhere.
I'm in semiconductor design not software but my goal is always "I've got way too much work, is this person good enough that after a few months of training they will be able to do some of my work so I can get more sleep?"
If the person is smarter than me even better! Instead of spending time teaching them maybe I can learn from them and get into their network so that if I ever need a job in the future they can help me out.
this is very well put, indeed both parties are set up to fail:
- the interviewer has an incentive to fail the candidate, whereas the interest of the employer is to actually hire someone eventually..
- the interviewee is rated on something that has little resemblance to the actual job (difficult to succeed when you're not told what the admission criteria are...).
Some years back I wrote a post about interviewing, from the point of view of the _interviewer_. I emphasised that during the interview, the candidate is the most important person in the world.
It only later dawned to me that our industry has a non-trivial fraction of people for whom empathy is a foreign concept. They're not sociopaths, because those folks can at least feign empathy - we're talking about individuals who can't see themselves in another person's situation at all. On top of that, we don't really provide actual interview training to engineers either. Out of all the people I personally know in London, only one (1) has received formal interview training.
Is it any wonder that the interview gauntlet is such an awful experience for pretty much everyone?
That seems like a reasonable approach if you have the right skills for it. My problem with such an approach would be that I'd not feel comfortable to make an overall evaluation of a person based on a short interaction. Having a clear cut process with well defined metrics provides me with more confidence that I'm evaluating candidates fairly. Without it I'd be worried that my rating would be too biased by superficial stuff like how they dress etc. Something that at least in psychology research seem to mbe a lot more common than many people think. In general, looking too much at cultural fit would feel I'd risk "hiring my friends" rather than based on what value they could contribute.
That is a risk, definitely. And I think that kind of thing is probably in part why Google and others who followed them ended up where they did— wanting a system that was completely impersonal, quantifiable, and which could be said to be 100% meritocratic.
Which is noble, I suppose. But clearly lots of people still felt that it was unfair and alienating; closer in spirit to a hazing than a good-faith evaluation.
I guess, but I would hope that kind of thing could/would be smoked out in the course of a discussion following these kinds of prompts:
- Tell us about the approach you took with the take-home coding challenge. Why did you break up the functionality in the way that you did (modules/classes/functions)? What kinds of constraints or requirements would cause you to make a different call here?
- Tell us a debugging war story. What was the bug, how did you discover it and come to eventually understand the root cause? Any challenges with reproduction? What steps were taken to prevent it from happening again?
- Pick a feature of XXX programming language and explain how it contrasts with approaches taken in other languages. What do you like about it? It is more productive, efficient, safer, more explicit? What are the tradeoffs and how do you balance these? What kinds of projects would have you prioritizing using a language/ecosystem with this capability?
Someone incapable of writing a fizzbuzz program is not going to be able to bluff their way through an interview like this. Obviously you need to be committed to listening and exploring the space with the other person as opposed to flexing and looking for the "right" answer, but that's just part of the discipline of being a good interviewer and not a jackass.
I have found that a 30-minute discussion on a random variety of technical topics (including questions such as those posted above) is sufficient to determine whether someone has required technical expertise.
Coding exercises entirely miss the point, because writing code is the easy part. The hard part about good software engineering is being able to rapidly acquire problem domain expertise and knowing which engineering design choices enable rapid, scalable, and maintainable development to solve the problem. That's why companies using code exercises to screen candidates are generally not worth the interviewee's time to work for - it indicates that the interviewers don't understand the problem domain, either, and (by extension) that company is mired in mediocrity.
I've had code exercise interviews. I'm quite happy that I have never had to work for one of the companies that used them. I have never given a code exercise interview, and I've been quite pleased with the candidates that have responded and worked with me.
"How would you pull in data from an arbitrarily long -- maybe never-ending -- source of data in Python?"
me : "What kind of data? What is it used for? How should it be represented afterwards?"
Silence on the other end , followed by "Well that's up to you."
I then fumble out a few ways to do it (verbally), to a recruiter that doesn't seem to understand anything that i'm saying -- he's probably reading a question from a script and pattern-matching what I say to the supposedly correct answer given to him in the same script.
Finally it ends with "Oh, that's interesting. ...We'll get back to you." , and the interviews that go this direction -- they never get back to you; you've already lost.
I'm not spouting gibberish, i've been at this for a long time; i'm just not spouting out whatever tech-jargon that their company supports and is needed to conform to his script, and quite honestly the person on the other end of the phone call seems to be universally under-equipped to judge anything remotely CS related.
It's a really weird/ephemeral/surreal experience. Imagine a surgeon being appointed to a position at a hospital because the secretary quizzed him on some flash cards (flash cards provided by Acme Sharp Scalpels), and the surgeon -- by chance -- prefers Acme Sharp Scalpels, and so mentions that brand. Instant hire according to the flash cards.
That's a lot like what it's like when a technically-accurate developer gets passed over for one that blithely mentions popular software packages (pandas/tensorflow/whatever is popular this week) without any real technical knowledge on how to achieve the goals wanted by the hiring party.
> "How would you pull in data from an arbitrarily long -- maybe never-ending -- source of data in Python?"
The answer to this question is to use a generator. If you don't know this, then both people are going to wish that they had that half hour of their life back.
Is this a good question? If you want somebody with a lot of Python expertise, then knowing about generators is a good thing.
If I was interviewing a candidate, and they didn't know this, then I would just find a pleasant way to move on after a minute or two. If this is the only interviewing question, then that makes me happy, because this company has a flawed process, and is leaving some great talent for me to hire.
It's not a big deal if you didn't know this at the time. You might not have known what a generator was, and the person interviewing probably wasn't very good at interviewing people.
I think that's only applicable if you are reading from a socket. Although I don't know too much about asyncio streams.py, so I'm not going to get a job at this company.
> > "How would you pull in data from an arbitrarily long -- maybe never-ending - source of data in Python?"
> The answer to this question is to use a generator. If you don't know this, then both people are going to wish that they had that half hour of their life back.
That's funny...I've implemented more than my share of such things in a long career, and my first intuition for an answer to the question, as phrased, was to implement stream sampling. It never even occurred to me that the answer might be a syntactical feature of the language (and yes, I know what generators are).
According to you, I'd be so wrong that I'm a waste of time.
Do you see the problem yet? It isn't theoretical. I've hit this kind of situation with so many interviewers that I'm actually more nervous when I'm sitting across from someone who is clearly on their first or second job out of school. They're asking (unclear) questions in the "python syntax" category, and I'm thinking about the engineering consequences of consuming an endless stream of data...
> According to you, I'd be so wrong that I'm a waste of time.
I don't think so, because you actually know about generators. If you were hiring for people who had a lot of Python experience, but didn't know about generators, that would be a bad sign. You would probably want to ask a some other questions, so you would have a more complete picture of what the candidate knows.
My main point is that the company's interview process is flawed.
> I don't think so, because you actually know about generators.
Sure, but will the OP give me a chance to demonstrate, or simply flip the idiot bit as soon as I don't give the expected response? In the context of a phone interview, I probably wouldn't get anywhere near discussion of python generators in an answer to this question. I'd probably say something like:
"For an infinite stream, my main concern is system resources, which are never infinite...I'd want to use something like stream sampling to calculate the desired metrics, but it's hard to know the right solution without more information about the problem."
Far too many interviewers hear that as weasel-wording, and simply disengage. It's even worse when the interviewer thinks they're asking a clear question about python syntax. It takes a high level of self-awareness to know that you might be the problem when you're the interviewer.
An experienced interviewer might engage with that, but many folks don't have the patience to listen to an unexpected response, nor the respect for the candidate to give them the benefit of the doubt. As I said, this pattern isn't theoretical. I've been on the interviewer end of this kind of pattern many times before.
> My main point is that the company's interview process is flawed.
This is a sign that the interview questions aren't there to actually assess technical ability, but are geared towards excluding anyone who hasn't travelled in the right circles. The employer isn't looking for someone skilled, they are looking for someone who is pre-filtered to think a certain way and know certain things.
Maybe. I tend to think that's a cynical take. Never assume malice when incompetence will suffice.
This is a...youthful...industry, and a lot of junior people (with "senior" titles!) are out there doing interviews. It takes experience to become a good interviewer, and if you've never had that experience, you don't know what you don't know.
How does "use a generator" answer this question? A generator can yield an endless amount of data, but if they ask "our customers buy things 24/7 on our website, how would you pull the endless orders into Python?" and you said "a generator", I'd think you were trying to guess the teacher's password ( https://www.lesswrong.com/posts/NMoLJuDJEms7Ku9XS/guessing-t... )
It surely matters if the data source is push or poll or something else, matters if it's a lot of data or a trickle, matters if you need all of it or if you can miss some (and how much), if the source buffers it or doesn't. I'd expect discussions about message busses, queueing, buffering (maybe ring buffers), data stores (maybe SQL or No-SQL), as well as concurrency or parallelism expecting the question could move to "and what if there was 1000x more data?". "Process stock market data" needs more than "read a temperature every minute".
Or at least for a candidate to ask about some of them and be told "this isn't so complicated", not "it's up to you". If it's only asking whether you can loop over a generator instead of trying to read all the data up front, the question could surely be more focused?
The question is garbage as phrased to be sure, but I think the auxiliary context matters a lot in this type of questions. Mentioning "python", when databases are language agnostic, heavily implies the answer is a language feature. Furthermore the way the question is asked (reading from a script) also implies there is a specific non-open-ended answer.
I still answered the question in my head on a whim, half-expecting it to be false, it's a really vague formulation. Sounds like the interviewer was randomly browsing language features and cutting and pasting random descriptions from whatever tutorial. Or maybe the company was using python generators in a really specific "data pulling" niche that the answer seemed extremely obvious to the technical team writing the questions and they forgot that outsiders are not wired to think of the same patterns.
> trying to solve a coding problem that in no way resembled anything I have ever encountered in my 25 year career.
that describes 2/3rds of the 'codility' tests I've been given in a few scenarios (toptal used it to weed me out). The couple of jobs I've been in where I was explicitly barred from ever asking any clarifying questions, or talking to business/SME folks about the problem at hand... I left those pretty quickly. I guess it serves to weed out people who have some hard-wired dependency on talking to people to clarify requirements.
Never understood this way of interviewing. I get shit now and then for helping people too much in coding exercises, but if someone has reached the point where they are obviously not going to progress why not nudge them along and see how they respond?
I've found that the ability to receive and act on guidance with a certain degree of humility is a much better signal of someone's potential than how many algorithms they've memorised.
It takes a lot of practice to know what level of assistance to provide at what time. A coworker once showed me a technique of keeping a google doc with the problems, as well as a step-by-step of the solution and the times at which they should be at that step. It always seemed to work out well for the candidates, as even a poor candidate would finish the problem at like 55 minutes into a 60 min interview.
Even with that, getting a person to see what they should be doing next, without telling them explicitly, is definitely a skill you develop with practice. I think you're right in erring on the side of too much assistance. You get to see much more of how the candidate works if you can skip over the part where they are getting stuck on something.
Yes some people just need a nudge in the right direction to carry the task through to completion. And some need to be pushed along the entire way. In either case they don't leave the interview feeling humiliated having floundered in the face of smug silence.
It is one of those common tropes, "interviewing is hard", that seems to justify the inevitability of poor attitude, wasting time of interviewees (remember the interviewers are paid for those hours) and a painful process for basically anyone.
I often interview for my company/group and yes, it is challenging in one hour to find out "life, death, and miracles" of some guy who is being interviewed, but it is especially challenging when the interviewer is in a bad mood, does not want to be there, or sees interviewing as a nuisance, and he is looking for a reason to make someone fail.
I worked at a FAANG and I got offers from FAANGs-adjacent companies, so I am not one of those you-cannot-win-at-this-game-so-you-complain people.
I saw: someone stopping the interview for unexplained reasons after the first 45 minutes, an interviewer at a blue company looking at my private parts for a good part of 45 minutes, multiple people interviewing while doing something else in person or virtually, recruiters (those were the fronts, the hiring managers were responsible) dragging the process forever and then say no with zero explanation.
Is it really "hard" doing better than that?
Actually being able to take a hint and work with the interviewer is a strong signal that a candidate, while maybe not the best for the job, has growth potential.
Right, one can note in the feedback that they got questions X,Y and Z but needed more than average / normal / acceptable level of hints. Better than sitting there staring down the interviewee in silence for 30min like a psycho. Then again.. it says a lot about tech management, doesn't it?
Reading all of these accounts of horrors in HackerNews I feel my idea of creating a "TOEFL for Developers" would be perfect.
(I am hesitant to describe my idea, but WTH, I'm currently not in a position to act on it, and they say ideas are dime a dozen so...):
For those of you for whom English is not your first language, you surely know what TOEFL is: Test of English as a Foreign Language. The private company provides a test where they evaluate a person for proficiency on different sets of English skills: Reading, Writing, Speaking, general comprehension. At the end of the test they give you a score for each of those and then a general score.
Now, the nice thing about the TOEFL score is its reputation: When you are going to study into a University (from Oxford to Liverpool, from Harvard to Queensland), if you are not a native English speaker, the university asks you to take a TOEFL (or equivalent) and get a score higher than X. As long as you provide that score, the university won't ask any questions. They don't doubt your English proficiency skills.
I want this becase I've been dealing with recruiting, interviewing and also being interviewed for most of my career. And in my experience setting up a "recruiting wheel" in a company or startup is very painful. Most developers don't know how to perform interviews. Or don't care (who has time for that?). As an Engineer manager, having to comb through 400 resumes a week is time consuming and unproductive.
So I imagine a scenario where, there is this proverbial "Full Stack Developer" certification authority which is independent, very reputable and unbiased: They won't tell me if X or Y developer will make it into my team. They will tell me how does the person score in "Algorithms/Data Structures" or "Micro Services development" or "Frontend development" and then I will choose whether I want to hire them or not (according to my current requirements). That way, I only have to do a culture-fit interview and that's it.
In the past I have dealt with "Sourcing Agencies" that try to do something like that: They do the 1st technical interview, and they say that there will be alignment to what I want. But that was not the case: They send me 2 candidates and get very surprised when I reject one and not the other. And I feel our objectives are not aligned, so everybody is frustrated. Moreover, I don't want to have to deal with hiring agencies. And paying 1 to 3 salary months is too fucking expensive.
Now, as a candidate/developer: I would love to have a "TOEFL" like certificate that I can show, with my proficiency. That way, I can "look for a job" passively. I don't have to be making countless of code interviews showing one time after another what I know. I only do it ONCE for an authoritative company, and everybody else can check my qualifications there.
Companies like Microsoft or TripleByte have tried to do something like that, but the problem is again that they do other things: Their interests clash. Why would I trust LinkedIn? That's why TOEFL monetization make sense: The candidate has to pay for it.
I am aware there are some certifications: Oracle whatever, Microsoft whatever, AWS whatever. But those are either too specific/nic...
certification authority which is independent, very reputable and unbiased
That is a big ask. There have been many attempts at CS-adjacent certifications, some of them government sponsored, but none of them find widespread use. The ones I've personally encountered were grossly out of date (e.g. a C++ assessment that didn't mention templates at all, in 2012), and weren't even mentioned during interviews by the company that demanded them.
It's not just a matter of trust, either. Our industry is incredibly conceptually diverse, despite the common current of abstract patterns that underlies everything. There is no specific or generic skill test that won't be out of date in a year, and forcing the required degree of standardization on our industry to make that possible would effectively destroy it.
In the mean time, the only organizations incentivized to keep their assessments up to date are the vendors themselves, who as you note, have conflicting interests. And at root, if you want to be even slightly more generic than a vendor certification, you are basically trying to test for intelligence and adaptability.
Now, the nice thing about the TOEFL score is its reputation: When you are going to study into a University (from Oxford to Liverpool, from Harvard to Queensland), if you are not a native English speaker, the university asks you to take a TOEFL (or equivalent) and get a score higher than X. As long as you provide that score, the university won't ask any questions. They don't doubt your English proficiency skills.
They should. My university had a minimum TOEFL score requirement. The number of grad students who passed that requirement, but then couldn't write a coherent English sentence to save their lives was still incredibly high.
I am compelled to write all the list of things why it will not work :) unfortunately I don't have that much time in my life. Don't take it as putting you down, I would love to see such thing working and live in real world, so look at it as problems that would need to be solved while aiming for grand solution.
First, there are wrong incentives at play, good guys currently don't need that as they mostly are employed and look for jobs passively. Good guys don't care about certificates and you want to certify good guys so your certificates mean something and can build trust. Weak guys will be spending money to cheat their way around just to get passing grade, which will cost money to prevent.
Then you have hiring managers that will not use this exam as good enough just to hire a person unless there is big company that would do the same. So you have chicken and egg problem, because no one will trust your certification and to get the trust someone would have to use it.
My idea is that you cannot effectively hire at scale. I could hand pick maybe 5 devs/year for my company, getting to real numbers in my small company I can see that we can hire maybe 2 developers per year. When We hire someone it worked for me with simple questions and attitude check. I don't see a way to hire 100 good developers in 1 year, that is not possible. Maybe at a scale you can hire 10-20 good developers a year but you have to have 3-5 people involved full time - and ideally those 3-5 people should be nice and technical - where in the end you don't want to use them only for hiring because those are probably your best developers with soft skills.
For that competency matrix - that is something you can do when you have developers inside of the company and you can observe them for at least 6 months. Good luck getting that in practical testing setup for 2 or less hours. I also find those kind of matrices terrible and not useful for evaluating people or projects. I work on a project where we were not fitting in anything of what was in the matrix .. yet we were delivering good quality for business all the time, while teams that were stuck on their "competency matrix" trying to improve meaningless points ended up disbanded and not working anymore in the organization.
> Now, as a candidate/developer: I would love to have a "TOEFL" like certificate that I can show, with my proficiency. That way, I can "look for a job" passively. I don't have to be making countless of code interviews showing one time after another what I know. I only do it ONCE for an authoritative company, and everybody else can check my qualifications there.
One interesting thing about TOEFL is that it is, arguably, correct and complete. I.e when using the English language you use 100% of the skills the test measures, and the test measures all skills necessary to thrive in English. That's why you only need do it only once (every X years).
Engineering skills as defined by those matrices are so much more open ended that you'd need specific matrices tailored for different positions. E.g. a front end developer doesn't need to know what a linked list is. Then you end up moving away from the idea of ONE authoritative test.
Also worth noting that wherever I've seen it used, TOEFL is usually a mere checkbox to tick, and there are other, more thorough measures of skill involved.
My honest opinion, at this stage in my career I don't have any patience at all for explaining technical concepts. Its almost never a one off, once you have to hold someones hand, you always do. And if you don't, they are creating technical debt.
It's all the potential criteria around the request that makes just that one piece more complex than it seems.
For example; "Make me a site that does x, you have 2 hours" Do I need to build the app in front of you? Problematic because how often does one build an entire web site in a couple of hours, while someone is standing over their shoulders scrutinizing every keystroke?
Do I take it home and do it? If so, how do I prove to you that I did the work?
Do you care what framework I use? Do you care if I use Open Source code?
What design should I use? Where do I get the site assets from?
If I'm building this site for you, are you paying me for that time?
Then there's the non-technical parts missing from an interview like that:
How does such an exercise tell you that I'm the kind of person you want to work with?
How does such an interview provide me an opportunity to ask you question? It tells me nothing about you or your company which is every bit as important as you finding out about me.
Had a colleague have a similar interview with Reddit for an infosec/appsec role. They said it was a shit show, no feedback, never heard back. Sourced through an external recruiter, so Reddit is burning some recruiter's time churning through candidates. Picked up by someone in finance at similar comp a few days later.
It's a good signal for me when I'm presented with silly brain teasers like this in interviews, especially when the technology of the company isn't that great.
I'm interviewing you too, so give me something that reflects the problems you solve as a team, otherwise my assumption is your office is full of white boards containing puzzles of the day and your tech is all 3rd party libs.
I wouldn't actually class this as a brain-teaser. It is a non-trivial[1] problem that doesn't require an "aha!" moment to get right. It is amenable to multiple ways of reaching a correct solution. It has interesting follow-up questions. It also stands a minimal chance to actually discover (some) of the way a candidate thinks. It is also implementing the VM for a Turing-complete computational model.
It may also be that anything work-related is actually too long to fit into a limited interview time.
Now, a trivial, brain-teaser, question would be "you have an NxM matrix, and you can either go left or up. How many paths are there from the lower left, to the upper-right corner?"
I consider it a brain-teaser because if you write code that contains any matrix manipulation or searching, you have basically failed. There is a closed-form expression for the number, so...
[1] By "non-trivial", I basically mean that there are multiple correct solutions.
That's actually a nifty problem in itself, I don't see anything wrong. Of course I have learned that the actual "proposition" of whatever problem is not what is right/wrong in an interview.
The way I would apply that problem interviewing someone is: We have 1 hour. Here is this problem (to which of course I know the solution to already).
How would you solve it? Let's solve it together so that I can see your decisions, your code, do you use exceptions? do you use specific type of exception for different errors? do you split functionality in a lot of functions? do you know nifty language tricks (maybe a bit of code golfing or functional constructs if JavaScript or Ruby).
The problem comes when the "interview problem" is passed from the creator to the "mid-level" Engineer who now has to do the interview. For them it becomes: "Ok, you gotta implement this in one hour", and they don't know the nuances or reasons for the problem.
I've seen this first hand with an equivalent problem. I had all this nice interview process that I applied, and the first time I shadowed one developer so that he could do the interview, he was just looking at the poor interviewee fail due to nerves, with the aim to evaluate him only on the merits of how far a set of working code did he had.
I interviewed for a director of engineering role there — met the CTO, very informal ahead of the actual interview loop. Recruiter said they would follow up. Crickets. I followed up. Silence.
As someone passively looking, thank you for this. I'll remove Reddit from my list. That is unacceptable. I do 5 interviews a week on average for my company, and if we did that to candidates, heads would roll.
As an interviewer your two objectives are:
1. Ensure the candidate has an excellent experience
2. Collect data points
In that order. Sometimes we run into candidates who make the second item difficult. They fail to complete the specific technical problem. They can't speak about their experiences in detail. We need to drag data out of them screaming. It doesn't matter, your priority is to ensure they feel respected, and leave thinking they WANT to work there.
The last technical interview I did was for Facebook, and say what you will about them, it was a great experience. Before the interview they actually gave me a couple paragraphs about what I was going to be tested on. Needless to say, I nailed it. :D
The implication is that they aren't new and they've had ample opportunity to be humbled and grow. That their perspective is the result of experience. Thats all.
I also interviewed with Reddit, although it was a few years back at this point.
I thought I nailed their code challenge and expected to continue through the process, but after that session that was pretty much the last I heard from them. It was pretty disappointing.
One of my buddies gave me this useful insight once: the impression you give your candidates, even the ones you don't end up hiring, will likely be the last impression you'll get to make on that candidate and the tech world is very small. Negative experiences will impact how candidates perceive your company and word of that experience will spread. Always be respectful to the candidates. If nothing else, they took the time out of the day to meet with you and go through various obstacles, etc.
It's too bad your experience was so negative. That's going to be a datapoint in my mental dataset of companies to consider when the time comes.
> Reddit’s hiring process converted me from a fan of the site into someone that thought the entire organization was second tier - which obviously it is in terms of monetization - but also in how they treat people compared to the FAANGs.
And from a completely non-technical persons perspective Reddit is incredibly disorganized at the executive management and corporate level. The amount of turnover, controversy, business model revamps, etc. for a 16 year old company with the hype they have is unique and unprecedented. It's not surprising whatsoever that their hiring practices are similarly disjointed.
I interviewed for a front-end dev position (it was my first ever interview in the industry, I vomited before I got there so it was a pretty crazy day).
I come in. The front-end guy starts asking me questions to try and solve something he is working on. No-one else is there yet. He is asking me about why a JS compiler is removing his comments, I say I don't know, I have never had that issue before...I make an off-hand comment that I use React and most of my JS code doesn't have comments because I am just working on projects by myself, and I don't do a lot of library code...the manager comes in at this point, and proceeds to berate me about why commenting is essential. I say: I use comments where they are needed. Off he goes, again.
Interview starts. Manager proceeds to go through a series of questions designed to expose my ignorance. None of which are related to the job. One classic was him explaining to me that database normalization made no difference to the size of the database because "the data is all the same on the disk" (which is, ofc, not accurate...I tried to explain, he just kept repeating that over and over...he actually said as I was leaving "make sure you understand databases for your next interview" with a massive shit-eating grin). For some reason, there was also a back-end guy there who, upon hearing that I built something in Java, proceeded to launch into a series of questions on internals of Java (for example, he asked me what the difference was between certain versions of Java and the size of the heap...perhaps unsurprisingly, he also got some of this stuff wrong but began laughing when I said I thought X was Y).
The only two questions that I had about front-end dev were: the front-end guy trying to ask me to help solve an issue he was having (before the interview, when no-one was there), and a question about the value of this in arrow functions (which I got wrong, but is also an excruciating thing to try and explain, so I don't think the guy knew whether I got it wrong...it is a terrible question). That was it.
>He is asking me about why a JS compiler is removing his comments
Huh ? language parsers remove comments because they're comments, that's literally by definition. Are you (or your past interviewer) using "comments" in a different sense ?
(Also, not trying to be a pedant on you I swear, but technically JS is traditionally interpreted. Most mature runtimes have compilers but it's not part of the API. It's just a juvenile pet peeve of mine when language implementations are generically referred to as compilers.)
>he actually said as I was leaving "make sure you understand databases for your next interview" with a massive shit-eating grin
I sincerely hope from my heart of hearts that company or department is in it's well deserved position in the depths of the toilet now, or at any rate that specific person.
I actually can't remember the details. I believe we were talking about Babel...so, technically, a transpiler. Or it actually could have been one of those code bundlers (I seem to remember they were using browserify...this was a while ago but I believe most people were already using webpack then...JS...what a mess).
Actually can't find him at the company anymore. But the company isn't doing too well (although they seem to have moved into a nicer office). Revenue down 50% last year (from a small number to an even smaller number), costs up 60%, losing substantially more money than they have revenue, the operations guy who did my interview isn't there anymore either...true "tech company things". I didn't the impression that the company was that bad, they were more "much steam, no fire".
> it was my first ever interview in the industry, I vomited before I got there so it was a pretty crazy day
I'm really sorry to hear this, that sounds incredibly stressful. The worst part about stress in technical interviews is that even under good interviewing conditions (which you clearly didn't have) it can really hobble a candidate to be stressed.
I hope this experience (or this HN post) doesn't scare you away from programming or interviewing at software companies in general. Those guys sound like jerks. There are good companies and decent coding interview routines out there.
My favorite interview surprise was when I was asked to craft a presentation on an interesting project and be prepared to discuss it. When I got on site, it turns out they wanted me to present it cold to the entire dev team of 50+ people.
Reminds me of how too long ago they ended up hiring someone with a very controversial background, and quickly backpedaled on the decision. Seems like they need to take a long look at their hiring practices
I have a not dissimilar background and what you describe is exactly what caused me to throw up my hands and leave the tech world. It's just not worth the BS.
What do you do now? I'm looking to stay in tech (for now), but I'd really like to get out of web development at the very least. Though, I'm not entirely sure where to even begin my long journey.
My educational background was CS and business, I spent 23 years in a wide range of technical, managerial, and consulting roles, and now I sell real estate in two states (our market spans a state line). Would be happy to chat anytime about career ideas.
That's very kind of you, I think I will take you up on that offer. I've only been in the field for like 5 years as of next month. Do you have a preferred form of contact?
Yeah the amount of trivia folks like to throw out, and the assumptions made based on them is absolutely absurd.
I've ran into "OMG he didn't know that!" responses when one dev disapproves of a candidate. Inevitably I ask "Really how often do you need to know that? and if you needed to wouldn't you just google it and be done?" but we assume it means so much more and there you go.
Then someone else gets hired and they knew the trivia, but can't apply it or worse only really knew the answer and not the ramifications... or they just can't wrap their mind around / don't care to think of second order effects or whatever.
I’d be happy if some organizations started accepting a credential in lue of a coding interview, and just did a design/architecture and cultural interview.
People here are suggesting credentialing as if it will remove interview requirements rather than simply add a new hoop to jump through. I do not believe required credentialing solves the interviewing problem at all. You see it today with the certifications that already exist in the market. They aren't worth the paper they're printed on. Anyone can trivially study and pass the certification tests and still never have implemented a system, nor even have basic programming ability.
Adding a new hoop is the desired effect, and it does solve at least one problem. If you're at a tech company or some other org that interviews well, you might not have seen it yet.
Many devs are not good at their jobs. They mean well, but they can't solve basic problems without looking at stack overflow. And by "basic", I don't mean leetcode, I mean iterating over a collection.
> Anyone can trivially study and pass
Yes! At that point, I would know that the guy sitting next to me did at least some amount of studying of the fundamentals.
A real credential with teeth would likely eliminate plenty of the "Does this person know anything at all" element of current tech interviews. I've interviewed people who didn't even know what a for loop was or the difference between the stack and the heap. If there was a piece of paper which said that the candidate knows at least the bare minimum about software development, you could at least start the interview at a more advanced (or domain-specific) level.
I doubt hospitals interviewing senior doctors need to ask them basic anatomy questions, or law firms needing to ask candidates the difference between tort and criminal law. Tech could benefit from this minimal minimal bar.
Just turn the Leetcode-style data structures/algorithms segment into the basis of this credential, so it at least doesn't have to be repeated ad nauseam each time an applicant interviews with a different company, despite having the least relevance.
Triplebyte was trying to do this a while ago, weren't they? My last observations from a year and change ago suggested they were running into what might have been signaling equilibrium issues / risk aversion, but I'd be curious if there's other perspectives around.
That's what Triplebyte is attempting to do, yep. But it does seem like a considerable challenge and they're still figuring out their product. Also feels like for an industry-scale problem like this, it would require a consortium of the major employers (not just FAANG but large companies from Microsoft to Intel to Oracle and beyond) to hash out some sort of standard, not to mention a body representing the engineers (if not a SWE union, at least something like the IEEE/ACM) and the academic institutions that provide the education.
One wonders what the history of how the credentials in medicine or law were forged.
I can't speak for architects, but there is a very high bar for licensing for them. For lawyers, I had a friend at a top tier firm that interviewed with another and had to do a full doc review- essentially doing several hours of actual work. They were moving to a small boutique firm outside of "big law" so this may have been somewhat outside the norm.
> I’d be happy if some organizations started accepting a credential in lue of a coding interview
Sure, but what credential exists that both is reliable enough to support that use and would remain reliable enough once it became used that way, even in a specific narrow subfield of development?
Yep. It existed for a while. It was canceled (as noted in the article) because not enough people were taking it.
I looked at it briefly but realized that I would need to study a significant amount of engineering aspects (how much water can flow through this pipe type engineering) to be able to pass the first exam.
For people who are developers, while the ethics, principals, rigor and similar type aspects of the PE exam process are useful, that it is still focused on being a PE first and a PE with an Software specialization second means that most people who are software developers would not be able to pass it or find use in the additional engineering principals that it provides (you wouldn't want me to sign off of a building design... well, maybe if I studied enough to pass the FE exam first...)
>our profession does not have an accepted universal bar everyone can jump over to be considered ‘qualified’.
They even do this crap to people with CS degrees. If a 4 year CS degree isn't enough, then people who do this have no idea what they are doing.
I started in this field in 1997. The interviews were more old fashioned, a few tech questions, see if you were an oddball, then they'd get back to you. If you didn't work out, they would just fire you. Pretty simple.
If it's not enough for an employer, it's because that employer devalues what's taught in most CS programs. Granted, there's a significant mismatch between CS degree work and real world work, but that's true in lots of engineering. Ask any engineer in whatever subfield how much time they spend solving differential equations. I mean, great that I learned how to balance a binary tree and write a heapsort in my DS&A class, but have I ever needed to do that at work? Other than to pass some stupid coding interview?
> If a 4 year CS degree isn't enough, then people who do this have no idea what they are doing.
I’ve interviewed many people with 4 year CS degrees who can’t really code. I’m not sure how this happens, but it definitely does. I disagree that having a CS degree should excuse candidates from coding interviews.
My current company works predominantly with 2 major programming languages: Python and JavaScript. This is made very clear when advertising our open software engineering positions. Despite this fact, we once had a CS graduate (from a top-tier US university) who applied and was unable to write a for loop in either language. Yes, that's right: a for loop.
I think it's because software varies vastly in complexity and spans many domains. Every software engineering role may use a generalized skillset to a degree, but I feel like there can never be one all-encompassing bar that can effectively cover the requirements of every role.
The same would apply for law and medicine, but those fields have chosen to make a requirement where specialists do have to be generalists first and have to learn and be examined on the whole field.
Becoming a specialized divorce lawyer still requires you to pass certification on things like criminal law and constitutional law (among many other things), you won't be permitted to practice law if you know just your specialty, no matter how well you know it.
Becoming a heart surgeon still requires you to pass certification on pharmacology and gynecology (among many other things), you won't be permitted to practice medicine if you just know your specialty, no matter how well you know it.
But for software workers we do accept that you can ignore many related (and even relevant) fields and just learn only one niche of technology - we could make an all-encompassing bar, but it would be a major change and I'm not sure if we would want that.
It really would be nice to have some kind of license at this point. For interviewees, it sucks because you basically have to take your license exam for each company you apply to. Interviewers have to administer this exam, and they may not be that good at doing that either. They’re more interested in getting to know candidates and hearing about their experience.
The first time I interviewed at Google I didn’t make it past the phone screen. I bombed a question about an appropriate length of a Bloom filter because I hadn’t recently been thinking about Bloom filters, and I was summarily rejected for onsites. The second time I interviewed I was asked a number of questions that I was perfectly “primed” to answer. Because those were in my brain’s cache, I was able to get through the full interview loop with a “hire” recommendation.
My focus is security, and so the second time around I got Travis Ormandy as an interviewer. I was able to impress him well enough with my IPSec foo to make it onsite. Then I got asked a question I had already been asked in another interview with another company, and I was able to knock that out of the ballpark (I mentioned I already knew that question, but the interviewer wanted me to answer it anyway). Then I got asked a question that used recursion, and because I took a graduate course on induction and recursion within the past year, that was effortless for me. Then I got asked a question that involved a kernel feature, and because I happened to recall the Linux kernel list macros and semantics (something I couldn’t repeat now over 10 years later), I really impressed that interviewer.
I ended up having a really successful part of my career at Google, even though I ended up not really writing much code when all was said and done. However what code I did write was highly impactful.
Looking back, things could have gone very differently if I had gotten a different set of interviewers and/or questions. The questions I got just happened to coincide with what was “paged in” to my “working memory,” so to speak.
this needs to be one of the highest rated comments squarely due to how much luck (or gruelling prep) is involved in effectively memorizing answers, i.e. the issue with technical interviews to begin with.
> I bombed a question about an appropriate length of a Bloom filter because I hadn’t recently been thinking about Bloom filters, and I was summarily rejected for onsites.
I've never even heard of a Bloom filter, so I know how I would have done.
Bloom filters are really cool for space-efficient "have I never seen this before?" lookups. If that is a question that code you write frequently have to answer, Bloom filters may be a good choice. The Wikipedia page actually seems as if it's not too horrible,
I had an technical interview with a company early last week, we did a shared session using VS Code. The interviewer wrote the function signature, and I filled out the implementation. I did great, according to the interviewer, and moved to the next set of interviews.
The next interviewer, which turned out was also technical, ended up opening up a shared Google Docs to write code it. I asked if I could just share my screen in my own editor, but they couldn’t give me permissions to do that. I was given an extremely vague question. When I asked questions, he told me to stop because he was holding out for next iterations of my implementation (again, in a Google Docs). Given no structure and an absurd environment, I completely bombed it. And to top it off, instead of getting an email saying they were not interested in me, they just ghosted me all together. A complete waste of time. I wish them luck in their endeavor to find the best engineer to write code in Google Docs, since that is apparently what they are interviewing for.
reminds of of the systems design interview I had with Google, the interviewer had his webcam off, barely spoke English and had me trying to make diagrams of system architecture in google docs with no reference of what he was actually looking for
it was like sitting in a confusing nightmare for an hour
This is when you open a can of BS and just spray it everywhere. Go for the most esoteric and ridiculous design that you can. Elaborate on the minutia of your design at the finest level. Puff your feathers and flaunt your genius. Both bore and impress your interviewer at the same time.
I had an interview with Gitlab like that years ago. Here, write some chef with only the vaguest spec - even after quizzing the interviewer to ascertain requirements.
Had a similar Google interview ~10y ago, shared GDoc. Phone connection was poor, interviewer refused let me try another line. I'd ask clarifying questions and he'd just keep acting annoyed and saying "Are you done yet?"
Frankly the most annoying interviewer I ever encountered. Served as a low water mark and inspiration for me to be as helpful, thoughtful, and kind as I could be in the next 100 phone screens/interviews I conducted for my employees.
FWIW, I've been to many a Google campus and know many employees there, so I think this was an outlier.
I'd almost rather physically writing on a whiteboard than using something like Google Docs to pseudo code in. I don't know how someone even remotely technical would think that was OK.
This really is the problem. And I think it leads to a lot of the dysfunctional interview behavior that we've all seen. Interviewers are having to make up their own evaluation methods but really haven't thought through what the acceptance/rejection criteria should be.
The best interviews I've had, either as the interviewer or the candidate, have been when there was a discussion and a free flow of information in both directions. Unfortunately, it seems that in a lot of places, this degrades quickly into a hazing ritual.
It doesn't help that so many concepts on CompSci show up in different places under different names and labels.
I haven't participated in technical interviews in a long time, but when I was asked to do it, I made it a point to throw as many lifelines as I could until I got a satisfying answer. For instance, if want to know if the person understands generics and they can't answer the question outright then I'll ask them about C++ templates. Similarly, if someone can't describe the term "idempotence" I'll ask them "can you tell me what makes a function pure".
Mind you those terms aren't interchangeable but if you catch one it should be trivial to understand the latter.
Even if someone's never heard of idempotence, it's enlightening if you can get them to discover it for themselves by asking questions like, "What happens if this request gets sent twice due to a network issue?"
I had an interview with a company a few years ago -- on paper it looked like a perfect match. During the interview things seemed to go well, but things took a turn for the worse with the technical lead's interrogation.
He asked five or six questions related to C and C++ undefined behaviour, a very open-ended one about a technology I'd never used. I answered as best I can, but always opened with "I'd be referring back to the C standard and opening a JIRA task to fix the code". We got on to how I'd fix the code -- remove the UB, but only if there's a unit test covering it. What if there are no unit tests? What if there's no JIRA? Lots of what-if-maybes.
A few days later I was on a 3-way call with the recruiter and one of the guys that interviewed me. They spent the whole thing telling me how "any decent developer" should have known what the UB would result in, shouldn't have to refer to standards or books... and on and on. But as a courtesy, they'd be happy to make an offer.
Half the minimum posted salary, no benefits. It was right in the middle of the minimum wage and the "living wage" lines.
I declined politely, and the recruiter hung on the call...
"Wow. I don't know what to say. That's never happened before... do you mind if I share the recording of that call with my manager?"
They were still advertising to fill several positions when I last stumbled across them on Glassdoor a few months ago...
I thought the actual thing with C (and probably C++) UB is that, well, pretty much ANYTHING is allowed to happen (by the standard)? Including, but not limited to, nasal daemons.
this is advice i give to a lot of people trying to get into the business or switch jobs. no matter how prepared or qualified you are, every interview is a roll of the dice. maybe the interviewer is in a bad mood. maybe you're in a bad mood. maybe there's a communications barrier. maybe there's some organizational issue (too many candidates in pipeline, re-org, etc.) that causes the bar to temporarily be set extremely high. It's ultimately a numbers game and it doesn't make sense to get too invested in one company or read too much into one result
> I think a lot of this is because our profession does not have an accepted universal bar everyone can jump over to be considered ‘qualified’
Someday soon we may accept that what gets classified as software engineering is actually an amalgamation of skills from an entirely different set of titles/careers, most of which treat software creation and management as a tool and means to an end.
I don't generally consider a blacksmith and a welder to be the same occupations. You can lump them under metalworker, but would you really expect the interview process for these roles to be at all similar?
If they were applying in the tech industry you would. Might as well lump in metallurgist, chemist, materials scientist, and sheet metal workers because we do this in the tech industry. Everyones a generalized set of specialists rolled into one.
It's because there isn't one. So much professional advice seems to be based around a SV/FAANG mode of operations, but that just doesn't apply to a good 90% of the industry. Most tech work is done on line of business software, not megascale internet companies. Building high-design marketing websites is completely different from enterprise SaaS is completely different from infrastructure is completely different from video games is completely different from desktop software. Not just requiring different tech skills, but different personalities and working styles.
True. Furthermore, many of these FAANG sites work terribly and are ridiculous to navigate. Where is the logout button? Oh, they purposely hid it several levels deep under a strange tiny icon menu where users won’t find it … so users stay logged in and they can be tracked by the advertising markers.
Or, why did the screen just scroll down and lose my place in the paragraph? Oh, they loaded an ad in the middle of the document and the page re-rendered itself causing jerks and fits on the screen. Nice job FAANG site!
Or try performing a sort of items by price or whatever other criteria … doesn’t work because the website wants the user to see the “suggested” items no matter what search criteria was desired y the user.
recently interviewed with Robinhood. Their phone screen started with a system design interview, but man I felt so uncomfortable using the tool that they had shared. The interviewer created a text box in the tool and copy pasted a multi paragraph question. The font sizes were little too big, I had to constantly scroll up and down to read the question. After brief introductions, giving previous work/project summary, understanding the question, stating and clarifying my assumptions, writing down product requirements, identifying tech stack, I was already 25 minutes in for 50 minutes interview and from there on I was told to speed up and within the next 20 minutes, I was asked to make it scale, fault tolerant and all this even before I could properly illustrate and communicate my design. It was very confusing to be constantly switching between different design paradigms before being able to explain one. As expected I didn't clear it but at the very least the recruiter later did follow up and I communicated my feedback on the interview. Hopefully they take these feedback and make the interview process better.
>I think a lot of this is because our profession does not have an accepted universal bar everyone can jump over to be considered ‘qualified’.
Keeping aside the universal bar, even a firm/interviewer who interviews you will refuse to define a bar( and it's not too difficult to define one) or define a bar that is vague. Defining a bar will means that now they will have to come up with a really good reason to turn down a candidate. IMO they might as well as be honest and do the "culture" fit interview first and as an icing on the cake ask some simple technical questions, once they have settled for a candidate.
It's profession is filled will low status, low self esteem, insecure males, who bolster their ego by making the interview experience for the potential candidate as tough as possible. Not surprisingly the 'victims' (candidates) are also often the "victimizes" (interviewers).
Very few firms want to hire juniors, while nearly all firms desire senior-level talent.
This manifests inflated job vacancies because so many firms have an evergreen job posting for "Senior Full Stack". Because talent is scarce these roles rarely get filled (hiring managers expect million-dollar candidates to accept $100-200k compensation).
Also, because lots of software requires specific expertise, there are vacancies that can't be filled because of a knowledge gap (novel industries / projects, etc). For example, how could SpaceX possibly fill all their engineering roles? Surely money is not a limiting factor, but rather the limited supply of qualified expert rocket engineers?
To go in line with firms not wanting to hire juniors, I think generally firms do not want to invest heavily in employee training or education. I would, for example, happily make a shift from CRUD webdev and distributed networking to hardware and embedded and more lower level type work, but I doubt a firm would hire me near my current level and train me up.
I think you hit it on the nose. Companies don't want to invest in training their new hires. They just want someone to hit the ground running with as little hand holding as possible.
It doesn't help that, for a certain slice of the software industry, staying in a position for 18-24 months has almost been normed. If it's unlikely that your hire is going to be there for more than a couple of years, why on earth would you "invest" in them. It's not like you'll get a return on that investment.
And why would software engineers stay if you did invest in their training but in the meantime you're going to reduce or eliminate bonuses, make your health plan worse (or just plain switch to high-deductible with no PPO options), stop 401k matching, other key employees have left and you don't hire new people and instead dump that responsibility on someone else without promotion or raises, etc.
I've seen all of those things happen at a single company before (and relatively quickly, over two years), and several of those things happen at several companies.
This is often the case. Another factor is that in many of the areas with a persistent shortage of talent is that it would require 18-24 months of training to really become productive. That's a big investment and people tend to have short tenures at companies these days.
that is true for firms that never hire juniors. For me, I have a small team, we can only absorb a small number of juniors at any given time, because I have to have people free enough to train them up. And now, having lost most my seniors in my team to attrition, I'm hiring more mid-level developers (and hoping to find seniors)
The problem is likely that most people are willing to learn on the job, but then take that learning and go get a better job. A large portion of this problem is companies not being willing to increase pay to match the value you add by learning that skill, but it does lead to the doubt about bothering to train.
Why would any company spend 2 years to train a junior, only for that junior to jump ship?
Oh and it's not that easy to even find a "trainable" junior. Even if you have a fairly strict hiring process, at least 1/3rds of the people coming out of the edication system will be draft busts if using sports terms
To answer your rhetorical question, because the alternative is spending five times as long trying to hire a senior engineer without the sort of budget that FAANGs have.
And because it doesn't take a full two years before that junior is a valuable contributing member of the team; because they'll likely refer other qualified and/or educable applicants; because they might not jump ship, but be happy to get promoted if you actually reward them comparatively to what another company would pay them.
But sure, if you're not willing to invest either time or money in your employees, then no, you shouldn't hire juniors.
Spending five times as long to hire a senior who doesn't leave in a year or two is then a much better situation.
A junior dev hire involves sifting through many resumes, and then interviews, onboarding, and then three to six months of lower productivity for the mentor.
All of that represents losses against the current status quo. The current status quo is predictable.
This completely discounts the "accept and renege" that also is common with juniors looking for a job which can reset the job search back to square one even when you do find a good candidate.
Taking six months or a year to hire a senior has fewer resumes to sort and fewer interviews to conduct. When the person is hired, they've got a much shorter onboarding and has the necessary skills to be able to become familiar with the codebase without causing a hit to the productivity of the rest of the team (or other seniors).
In this situation, hiring a senior is likely a much better outcome with fewer seen and unforeseen negatives and an eventual positive.
Senior devs tend to be a bit more stable in terms of "looking for a place to settle down" rather than switching jobs frequently as they've got a better idea of what they want to do and how to judge if an origination is one they want to be in.
Additionally, even if it is the case that they leave in a year or two, the org has likely spent less time on going through resumes (fewer resumes applying) and overall interviewing (individual interview may be longer, but again - fewer overall being done) and less time on onboarding.
You're likely able to have productive contributions from a senior in 3 months rather than 6-12 months for a junior.
So even if the senior does leave in a year or two - the org is still better off trying to hire a senior than a junior.
---
It really boils down to "if you can't compete with big tech salaries, there likely isn't a way to hire a junior dev that will be a net positive to the organization.
If you hire a junior at $X/year, and two years later, the "junior" jumps ship because the two years experience qualifies them for $X * 1.5/year, then the problem isn't disloyalty on the part of the junior, it's with the company that hasn't kept up their salary.
Junior salaries are low because they're a huge gamble. If after two years you know they're a decent engineer that has learned a lot, then you need to pay them like it.
It's something I see a lot of. Your "junior" that has been there for 2 years should be getting the salary you'd be paying a new hire that has 2 years experience. If they've been there for 3 years, and you've only been giving them 3-7% raises every year, you deserve to lose that engineer for someone that will pay them 50+% more.
The problem is that nobody wants to pay you intermediate/senior salary for junior ability until you learn their field. More than that, even if you volunteer to take the pay cut, they may be afraid you'll jump ship quickly, or that it's just not worth the risk of doing something unconventional.
Most software positions at SpaceX, even those working on critical flight code, do not require aerospace knowledge. And SpaceX is not a great example as they hire a lot of interns and junior people willing to grind.
This is pretty standard in all industries. Most people who work at a bank aren't financial experts. Most people who work at a hospital aren't medical experts.
Thats because most roles aren't the core of the business. Most are supporting the core. You don't need to be a flight engineer to build the system that tracks parts during manufacturing. You don't need to know how swaps work to build an order management system for traders. You don't need to know how to do surgery to build a scheduling system for the surgeons.
What do you work on, and how much prior domain experience did you have? (And if you did have some, was it necessary?)
I currently work for an agtech company, the domain-specific stuff is just context for the generic numbers and equations, or a reason to choose one over the other, to the extent that I need it it suffices to have a colleague who's a domain (but not software) expert.
You might say that's the other extreme, aerospace is different, but I don't really see that it is. I don't think anybody's claiming SpaceX doesn't have or need aerospace engineers, but once they've, idk, specified a formula for a parabola representing a flight path say (yes, I don't know what I'm talking about!) then the domain doesn't (needn't) matter to the software engineer implementing it.
Flight paths and what not are crafted by GNC engineers who hand them over to software engineers to implement. Really the only domain expertise needed in software is for space-grade fault tolerance, which is a couple people per vehicle.
Iv'e worked with aerospace sims, grid-level protection products, financial products for banks and safety-certified industrial control software (even nuclear in some cases) that will result in great property damage and even death upon failure.
Basically nobody in any of those places had any domain knowledge outside that which was learnt during the act of developing and, in some rare cases, some "familiarization" courses during a day or so.
Overworking, but probably not underpaying. I remember hearing about how much a SpaceX intern was payed and being shocked (it was several X my scientist pay)... Then she told me how many hours she was working, and it made some more sense (but it still seemed high -- scientists often also work 80+ hours)
Getting paid what seems like a lot is not the same as getting paid what the work you're doing is worth.
i.e., did it seem like a lot "for an intern"? Did it seem like a lot when you take into account what was expected of them? I mean, if interns get hired to jobs that seniors (for the sake of argument) should be doing, and the interns are getting sub-senior pay, then they are underpaid.
I work in the same industry as SpaceX. They are in fact well known for pay that would be average-at-best in a sane work environment coupled with an absolutely insane work environment. When I was in college, my only goal was to get a job at SpaceX. After getting a few internships and talking to some people in the industry, my only goal now is to never be so desperate for work that I accept a job at SpaceX.
Their intern pay was also in line with this. I got paid a little bit less as an intern at NASA, but much more as an intern at a non-aerospace (also non-FAANG) tech company.
When I worked at SpaceX I had one of the saddest comp packages I've ever had in a long career. I left for a competitor and got 35% more just walking in the door, plus I don't have to deal with an inhumane company culture. I honestly don't know what Elon is going to do when he runs out of people to chew up and spit out.
how are senior engineers supposed to be created if very few companies are willing to train junior engineers? Why aren't these companies offering paid apprenticeships if they are so desperate for workers?
In part because you have to jave enough sr people able to mentor. There's not a great industry framework.
As a plumber, you pay your apprentice usually 60% sr/journyman salary with a 5% increase every 6 months to match the value of the skill up.
There are also industry standard, industry funded classroom settings, that teach things like building codes and industry standards and some adjacent trade craft.
Instead you just throw a Jr to an overworked mid/Sr and they can help with some design and questions and code review but that takes 10-20 hours per week so you have to pretty much have one or more per Jr. Position. Then, after 18 months when the Jr hasn't received a 15% pay raise to reflect the enormous amount of time an knowledge you've sucked out of a Sr position, they go elsewhere for a 20% raise and it looks like you've waisted your time.
In truth, it wastes the talent you've built to not be aggressively increasing their comp to match the skill increase you're providing.
one difference though is that varying levels of skill can be staggeringly different for SWE compared to a plumber. There are people that have been coding in basic since 12 and hacking their entire childhoods, and you have some people that coded for the first time in a cs program which they completed in an average fashion.
Not everyone is equally good of course but I would be very cautious about making hacking since 12 a requirement for a developer job. It certainly doesn't have its equivalent in any other branch of engineering or indeed just about anywhere else other than the arts.
And yet every other technical field which has no expectation that this has been a passion since childhood and applicants should have personal projects in the field manages somehow to hire people.
That's what I'm saying. We could train a base of knowledge so that skills transfer and we don't have to find super specialized operators for every role. When you get a union plumber to the shop, you know that they passed their certification. You may not like working with them or they may do sloppy work or something but as a whole, you're going to get a competent operator once the apprenticeship is finished.
That will work once the world has decided upon a single web stack with standardized API design and security and every company uses that web stack. When that happened hiring web stack developers will be a standardized process similar to plumbers today as you say. But be are very far from that level of standardization.
I'm not sure about other industries, but for me personally, my competency is in large part based on my ability to quickly pick up domain knowledge and apply it successfully.
I'm not really sure how you test for a base level of that, besides proven demonstration on your resume and doing semi-correlated coding quizzes.
True, I started sorting parts in a plumbing shop when I was 12, you still have to get certified and to get certified you take the same classes as everyone else. That's the same for doctors, and lawyers and all that shit.
This is why we don't have a base of expected knowledge in the field and why we do strange coding tests to try to guess if someone is competent.
> In truth, it wastes the talent you've built to not be aggressively increasing their comp to match the skill increase you're providing.
The issue is that we don't quantify what hiring someone actually costs. We're willing to spend $20k on finding a candidate for 160k yet the people in the same position are sitting at 120k and getting a 3-4% raise.
The new person needs time so expect at least a month of training, yet no one quantifies that as well.
yes, the JR to SR path should be a methodical planned progress with expectations of big raises as they skill up.
I'm fine with an annual cost of living adjustment once I get to a SR level because I'm not increasing skill at a rapid pace, I'm exercising my skill in the expected way. For a Jr path, that doesn't make sense. getting a cost of living adjustment and being twice as good as you were last year means you're a flight risk and that will cost the company more than just paying people what they are worth.
All of them, you pay some for the classes, If I remember I paid 300/semester for classes which is nothing really. usually your firm will pay your share.
But industry standard groups, unions, people who have a vested interest in having a supply of quality labor so they can do business. Some of the classes are sponsored (especially in smaller places where there's not enough support) and in return, they get to train you on a specific product or just hang a banner and give you a 10% tools coupon.
A sufficiently fast growing startup hires a lot of juniors and then due to turnover, general chaos, etc. leaves them with outsized responsibilities and little supervision. Those who “swim” in that environment are the next generation of senior engineers. It is not like you’ve been supervised for N years, you’re senior now. You get thrown into independence first and if you can hack it, the title and comp follow.
Worse, many firms are put off by juniors for entirely preventable reasons. In their minds, juniors are undesirable because the moment they are trained up, they tend to jump ship for senior positions elsewhere. Why train your competition, right?
The reason they jump ship is because the firm refuses to re-evaluate them for what they are worth, and keeps them on work meant to free up the company's existing senior staff (i.e., dead-end grunt-work that results in burnout). If you, as a junior developer, want to be re-valued, you need to jump ship.
This creates a feedback loop. Companies view juniors as a cheaper developer you _might_ get 2 years of low-cost work out of (after training) before they'll leave, creating a self fulfilling prophecy.
I've watched (and experienced) this loop multiple times. It's utterly baffling how firms would rather go through the cost and drain of finding and replacing talent rather than re-evaluate and pay their existing, proven talent what they are worth on the open market.
Workers would rather not move around. Workers would rather have a stable position in a job they like, in a community where they can purchase a home and build lives and/or families. Once you get past 35, playing the required musical-chairs needed to advance your career is a real drag. It does not need to be this way.
I really disagree. These junior engineers you're talking about are mostly in their early 20's (even if they're older and switching from a different career track, they're by definition new to the industry and still have a lot to learn). In my experience, they definitely do want to move around. And even if there is a great track for internal promotions and the compensation is going to be the same whether they stay or leave, it honestly is usually in their best interest to move around every couple of years anyway early in their career. They'll meet more new people to grow their professional network faster, work on new problems, see different ways of how teams operate and what works better/worse, and gain more experience faster.
I do think that for the very top performers, most companies should probably be much more aggressive than they are. If someone is really crushing it, like in say the top 1-5% of performers, be ridiculously proactive and promote them from junior engineer to Staff Engineer within 18 months or something. I've seen a couple of people over my career that actually were performing at that level, and no external company is going to give them that big of a boost, so it's a good chance to use your inside information to be more competitive. Otherwise, for the majority of folks that are learning/advancing at a more normal pace, I don't think there's really much a company can do to keep them longer. (Not that you shouldn't even try, it's still a continuum and if you do a really bad job at career growth internally you'll lose even more people faster. But you shouldn't expect to be able to keep most people beyond 2-3 years).
Hiring Juniors is a positive externality that the company does not see a penny of. They only see a penny of that externality if they don't give a raise, and that Junior chooses to stick around anyway. You get to exploit that he made friends or is stuck in your part of the city due to a lease or otherwise makes a poor financial decision.
It's interesting that the worse the interview process, the less the Junior will want to go through it, the more the company benefits. You make your process painful so your competitors make their process painful so both of you hold onto your Juniors for more time.
If you can fix the externality problem this goes away, but that's not easy.
Honestly, I think having engineers come and go is a net win for companies. I've worked at places where the "old guard" has been around forever and they are inevitably stubborn, obstinate, and convinced there is no other way to solve the problem. By changing jobs and environments, you get to see in practice that there are many different ways to implement a solution. Only seeing one set of systems (unless they are a FAANG, which is large enough to have the breadth to counteract it), would ultimately cause those architectures to stagnate, injecting new blood is also injecting new ideas.
I do however, agree with your sentiment, those junior folks that are getting all the work done only get rewarded with more work to do.
I work at a fairly small company that hires juniors. We pay them well, and give them more responsibility in pay as we see them improving.
Most of them still want to move on, usually to change technologies or gain more responsibility even faster.
Sometimes they want to move cities for almost random reasons, and they're willing to just find a new job and do it.
So while I somewhat agree that devs don't want to move jobs, juniors devs often do, and I think they're a lot more likely to move jobs than senior devs.
It's not that they don't want to hire juniors, it's that you need a solid ratio of mentors to mentees.
I've worked at a LOT of companies, and for the more well known one, the ratio of junior resumes to seniors was easily 1000:1.
We hired entire cohorts of juniors, often interviewing HUNDREDS of them in a couple of weeks, hiring dozens. That still meant that from all the resumes we got, only a few % made it through.
What choice did we have though? We can only train mentors so fast, and hiring them is hard and expensive. You can't ask someone with 5 years of experience to train 30 people at the same time.
People often underestimate just how many people are entering the field right now, vs how many were 10-20 years ago. Add in people who EXIT the field, as well as people who are poor fits to be mentors, and it gets really dicey.
Had this happen to me at my first official dev job. Had 'junior developer' in bold at the top in my resume, application, and in several emails to the hiring manager. Got hired, and quit within 2 months. Manager would become upset at times over knowledge gaps I had as a result of being a junior, and the solution they came up with was for me to dedicate my weekends to unpaid, self-directed training.
At some point I actually reminded the manager that I was a junior, which resulted in them acting shocked and saying something to the effect of "well, let's hope that's not the case", and was basically flat out told they have no time for a junior. This was the manager who interviewed me, read my resume, and recommended me for the position.
I was replaced by a university undergrad student on summer break when I quit. I don't think people realize how the problem here often isn't you. Organizations with deep dysfunction are more common that you'd like.
Happy ending though. Got a new position the week I quit, and all turned out well.
Juniors write a lot of code. Often significant amounts for a company's products and services. They're the ones who are implementing all the decisions that seniors spend their time making in all their meetings.
Most senior engineers I've seen have most of their days filled with meetings with very little actual coding time.
The seniors are valuable, making decisions, coming up with solutions, building frameworks etc, but it's the juniors who then take that and run with it and build everything on top of it.
So while some will still code, it's far less than what the junior engineers are creating.
Yes they require some more training, and clear direction, but they are the ones actually creating and executing the vision of the company informed by the seniors.
What companies really want, like others have said, are senior engineers who are willing to accept a junior salary.
While of course companies would love senior engineers willing to accept a junior salary I'd say
> Most senior engineers I've seen have most of their days filled with meetings with very little actual coding time.
Is actually a symptom of the shortage of senior engineers. Big companies that can afford to hire as much talent as they want actually will let seniors write code all day (my company does) because they have the economies of scale that lets them afford doing so; no one else can.
> This manifests inflated job vacancies because so many firms have an evergreen job posting for "Senior Full Stack". Because talent is scarce these roles rarely get filled (hiring managers expect million-dollar candidates to accept $100-200k compensation).
At a lot of non-tech companies, the trick is to get hired as a consultant.
I'm European so I'm unsure as to how the situation is in the states but here the situation is as follows: it's plenty of "developers" that taught themselves coding trough udemy or similar courses and can effectively code basic stuff in one or two languages. While I'm not trying in any way to devalue their knowledge or expertise in my experience a self taught developer will, on average, produce worse code and will ask for a lower pay. For employers though this doesn't matter because they mostly watch at the finished product and we all know "that guy" that can ship a feature in a week when testing/engineering alone would require two. It follows that there's a market saturation for entry level positions for low-end companies because they don't see the need to hire engineers or people with a degree that ask more while delivering "the same product". In my experience this changes when a company is more professional and there really is a lack of professional software engineers.
"Young" companies generally don't care about quality, testing, processes. They just want to build a product. I put that in quotes because being a consultant I'm sometimes amazed at companies that make millions/billions and have never bothered to think about these things, until the reach the inevitable point where every change becomes a pain in the ass.
Any advice for someone trying to get back into web based software engineering? I’ve spent the past 5 years implementing off the shelf solutions that enterprises use. Lots of API work, light web dev with some AngularJS but mostly scripting using JavaScript. I wouldn’t be able to pass a whiteboard interview.
My salary is above $100k and I could probably find a job doing what I’m doing for $150k or higher. My next choice is do IT consulting or try to find a management position but I don’t want to be tied to a vendors platform. Plenty of people have made entire careers on the backs of vendors like Oracle and others but I don’t want to be a crusty old dev keeping things alive until I retire.
>I wouldn’t be able to pass a whiteboard interview.
What the people who insist on giving these interviews don't realize is they are extremely hackable most of the time. The people who give them often aren't bothered to make up their own tests, so they go to the google and type "whiteboard interview questions for bla bla." I suggest you do the same and study up.
When I was trying to get my first internship it took me 160 applications to get 1 interview, before that I applied every year for ~20 internships at the big names and never got 1 interview. Similarly for my senior year I applied to full time and internship positions it took me ~145 applications to get 2 interviews for internships (I would be interning after I graduate). I did the resume prep, went to the career fairs to talk to recruiters and get feedback, went to hackathons to add to my resume, I don't feel that it really did anything. I even tried cover letters as some people on HN suggested to me.
The process seems completely random and based more on pedigree than on anything else. If you have a signal like an Ivy League school, an older friend in the industry who can refer you, or a FANG on your resume those seem to be the only ways to be picked from the sea of resumes.
If you can build a specialized skill set you can make things much easier. When I got out of school with no experience, no internships and a degree from a second tier state school, I still had good luck on the job hunt.
What worked for me was that I had been studying Kubernetes and was probably the cheapest guy on the market with that skillset :)
I actually disagree with this (if you’re aiming to work at a company between Unicorn and FANG size), I think there’s 2 parts to getting hired as a new grad or getting an internship as a student.
The first part is the University Hiring recruiters determining whether out of the 1000+ resumes they have read you are likely to have the basic skills required to learn to be a FANG engineer. In this part they don’t actually care much about what you did at your internships or what technologies you’re interested in all they care about is whether you know how to code in a language, know how to manage time and be managed by a superior, and know how to learn to do your job independently. If you pass this, great now you’re off to the races that was the hardest part due to the volume.
Then there’s a second part in every FANG university pipeline where University Recruiting and different hiring managers bounce around your application to find an intern for their team. In this part your demonstrated interests, prior work, and skills are important you’re way more likely to get a deep learning internship if you have deep learning on your resume at this part.
I posit that most university hiring advice focuses on the second part whereas the first part is the most difficult to pass. Think about it is the person with 4 hackathon awards and 3 deep learning side projects more likely to grow into a FANG software engineer than someone who has 2 internships?
Do your side projects involve reporting your progress to your team? Writing design docs and getting feedback from your team? Thinking about maintaining the code base and providing documentation to your coworkers? Those software engineering skills are learned not taught and you learn them on the job even though to other software engineers we would value the candidate with hackathons and side projects more than the one with 2 internships in terms of ability to grow.
I’m probably going to write a blog post or something about this cause I feel quite strongly about this after my experience following everyone’s advice.
I'm just explaining what worked for me- I'm in Raleigh NC, so there were no FANGs here a year and half ago when I was in the market. But I did secure offers at the two biggest tech companies in the area, IBM and Cisco.
I had no open source contributions, no hack-a-thons, and no side projects with users. No experience or internships whatsoever, I had work experience in the service industry that I didn't put on my resume. GPA barely above a 3
All I had were side projects on github, listed prominently on my resume, that showcased skills. My side projects were all toy projects- things like a tiny Go API with a dockerfile and Kubernetes YAMLs, an arduino project that creates a CSV based on inputs from a GPS sensor, etc.
When my interviews went well, it was because I had demonstrable expertise in Kubernetes
IMO the only advice I can give college students trying to break into tech is to always have a tech related internship every summer no matter what. Even if you have to apply to nonprofits looking for an IT admin intern, just have a track record of work experience + having coworkers who could move on to other tech companies and give you a good referral is key. Also make sure to have a linkedin and proactively connect with your coworkers so you can later ask for referrals if you need one, don’t lose contact.
Also since I’m writing advice, don’t ever stop applying to places. You might feel demoralized after everyone gets offers and you don’t have a single one in May, or in my case getting 149 oddly similar rejection emails from different companies, but I applied to a place in June and got an interview and offer a week later its never too late and in fact you might find a company/team who also thought it was too late to get an intern for the summer.
because expectations are not clear. Most of the companies do not know what they expect from the employee in the advertisement or in the interviews. it's just confusion on both sides.
Only entry level software jobs(because of the weird x years requirements) and FAANG jobs (because of the required DS&A prep) are hard to get. Standard run of the mill Fortune 500 SWE jobs paying 100-200k are relatively easy to get once you have any experience at all.
The top comment seemed to capture the problem best:
"What is in extremely high demand is programmers with 20 years of experience in a technology that has been around for 5, no older than 19 and working for 20k a year.
And that demand will be high, forever.
Pay more and you get more. Pay this and what you get is code monkeys that couldn't find a better employer"
I saw a posting for a full stack engineer last year with a rate of $20/hour. It was temping to apply just find out what they expected. I can only think since this was a startup they were trying to "fill a seat" to look better for investors because having a higher headcount would seem impressive?
This is often done to hire H1b applicants. You run the local applicants through an interview that ends up with them even if they are qualified not taking the job then go and hire the H1b that you really wanted because the H1b is then dependent upon you for staying the United States. You can now hold that over the person and anything you want they have to do like working 100 hours a week.
Is there evidence that's it's hard for devs to get a job in general? E.g. The average hiring times for software devs (on popular platforms) in London was on the order of a couple of weeks.
I know from personal experience that junior devs from bootcamps were getting snapped up quickly - source, I worked for 3 years in the recruitment industry and also hired many devs in that time.
And certainly one must ask: in comparison to what?
Is it far more difficult for a median skill software developer to find a job than the equivalent person seeking employment as an accountant, electrician, or plumber? I doubt it.
The persistently very low unemployment rate for software developers rather speaks volumes about how not difficult it is to find a job. The interview processes are obnoxious in the field? Sure, that's a reasonable claim and seems to widely be the case.
The demand for programmers is largely becoming a myth in my experiences. I work in public sector digitalisation in Denmark and as such come into contact with a lot of private sector companies from whom we buy development, I also work as an external examiner for CS students to keep up with the field and spot potential candidates.
A decade ago my region of the country would produce maybe 50 fresh CS candidates a year, now it’s closer to 500 spread across multiple different educations. This may not sound like a lot, but in a region of 1 million people it’s actually quite a lot, and those are the technical CS/SE types not the myriad of soft IT/design/communication educations which produce a further couple of thousand each year. It’s like this because we (as in the employers) have been telling everyone we needed more and still need more for that same decade. But this is a half truth. We don’t actually need more people to become CS candidates, we need more trained plumbers who are proficient in X technology that we can use for 5-10 years until they leave us or we replace them with someone cheaper. And how do you get cheap labour? Well, one way is to make sure enough people are educated in what you need them to be, and while it may have been the case that the world needed more CS candidates a decade ago that is no longer the case, but it’ll take a while for young people to realise this.
Well that’s one part of it, the other part is how the educational organisations educate our young people by giving them the wrong kind of skills. I’m not exactly sure why they’ve abandoned teaching people actual computer science, but the part that the most students fail on and the part that shrinks year by year is now computers work. I can see how the fundamentals aren’t as necessary as they were in the 90ies when I got my degree, and I also remember how much some of us hated that stuff even back then. But it’s what’s required to fill the best paying jobs, like running the cobol systems for a bank. Cobol itself isn’t hard, a cobol system is hard because it came with nothing and was build in a time where everyone invented the wheel their own way. So what you need to become a good hire for such a system is all the basic CS knowledge that nobody no longer teaches so that you may understand and reverse engineer whatever all those cobol programmers did in the 50 years before you arrived.
It’ll be sort of interesting to see where it lands us though, but I’d frankly get into actual plumbing if I was young today because that’s bound to be a better career for most people who aren’t aces in either the technical or the financial/management side of CS.
> decade ago my region of the country would produce maybe 50 fresh CS candidates a year, now it’s closer to 500 spread across multiple different educations.
A degree is not the same as “talent”. The degree doesn’t even mean you really “learned” the fundamentals, so much as you were able to regurgitate information and pass exams.
I’m a Principal at Amazon. One issue I see among CS graduates is a lack of understanding in very basic CS fundamentals. On paper, these candidates have CS bachelors degrees. On the other hand, they struggle to pick the right algorithmic approach when something is clearly a graph or tree traversal problem.
I don’t disagree with you but in Danish culture you get a degree or you work as unskilled labour in 99% of the cases.
Even if you don’t “need” a degree you still get one because it would be a serious handicap if you didn’t and our educational system doesn’t cost the individual money. In fact we pay you $1300 a month for 6-7 years while you work on your higher education. I’m sure we could debate the system, but the result is that almost everyone in CS/SE get a degree of at least academy level once they finish the mandatory 10 years of school + 3 years of gymnasium granting them access to the higher educations, and as such the number of educated is a very strong indicator of how many new programmers are entering the field.
> the result is that almost everyone in CS/SE get a degree of at least academy level
But this doesn’t mean these graduates are skilled? From your explanation, it sounds like there’s an incentive to get a degree - both cash payments from the government and an opportunity to avoid labor work.
> as such the number of educated is a very strong indicator of how many new programmers are entering the field.
But “educated” in this context means they passed. It doesn’t mean all or even half of these graduates understand the discipline sufficiently to be productive employees or even work at a FANG tier company.
I guess my point is - the market might be saturated with these graduates, at least on paper. But that’s not the same as the market being saturated with talented programmers, engineers, admins, or whatever the job title is.
Businesses refuse to invest in workers education thus refuse to hire juniors. Then they refuse to hire older developers because "not culturally fit". Tech businesses are full of sh...
Its like this for all jobs: the reason is that a bad employee typically subtracts more value than a good employee adds. So companies put a lot of effort in lowering the odds of hiring bad employees even if it means positions remain unfilled.
This would go along with some type of unionizing or organization.. but in the traditional trades (Electrician, Plumber, etc) there are education programs and apprenticeships before becoming "licensed".
Maybe that's what we need here, something to gap the "I'm brand spanking new" and "I'm a senior" time period.
There’s a tonne of variance between software engineers. Even at the same level (junior, intermediate, senior, etc.), it’s not uncommon for a strong hire to be ~5x better than a weak hire. By this I mean more productive, better at helping others, writes fewer bugs, creates more maintainable abstractions, makes better architecture decisions, can tackle more difficult problems, etc. And at the same level, the strong and weak hires get paid roughly the same, so companies REALLY want the strong hires. This is not a McDonalds type situation, where anyone lightly competent will do, you’re trying to hire someone outstanding at their job every single time.
Firing sucks, but it’s hard to truly tease out quality during interviews. So most companies go for false negatives over false positives. Generally this means that of the 3-to-6 interviewers, all have to have strong positive opinions of the candidate for the hire to happen.
Because of this, as a candidate, it’s a bit of a number’s game. You can be a great candidate, but still not get hired on any individual interview, because companies heavily bias towards allowing lots of false negatives to avoid the odd false positive.
> hard to truly tease out quality during interviews
I'm not sure I agree here. I doubt most interviewers have actually given much thought to what they are actually trying to look for in a potential candidate. The widespread practice of over-focusing on algorithmic whiteboard questions is a symptom.
There's got to be better processes in assessing candidates' qualities beyond solving algorithmic puzzles (which perhaps is 5% of a software engineer's job at best).
I dunno, I’ve conducted about 100 dev interviews over the years. Have tried various combinations of whiteboarding, architecture/design questions, take home problems, talking about past projects/experience, and sitting down together with the interviewee and pair coding on bugs or small features. I don’t know that any approach was clearly more effective than another, and for all of them I think the ability of myself and other interviewers to predict performance at the company was decent, but far from excellent. The clearest signal is probably a super enthusiastic referral (from a highly trustworthy source), but it’s rare to be able to get that.
It’s just really tough to figure out in 2-3 hours how someone is going to perform in a given role over the next few years. Interviewing is an inexact art, not an exact science, and it’s very much my experience that companies compensate for this by favouring false negatives (not hiring possibly strong candidates) over false positives (hiring weak candidates).
The 5x engineer at my last job created 5x the features and 5x the bugs, and consequently caused 5x the number of job postings because we needed so many people to put out fires all day. I have to thank him because he is the reason I was hired.
Yeah, I don’t mean just 5x the LOC or features. More a combination of all of more productive, helps others more effectively, creates fewer bugs, can tackle a wider range of problems, makes better architectural decisions, writes more materials abstractions, etc. Basically I think it’s pretty common for a strong engineering hire to produce 5x the long term value of a weak hire, taking all of the above into account.
I reviewed around 5000 candidates last year for TypeScript frontend and backend positions. Global, remote only. I received ~600 applications for an Angular position in one week.
The hiring percent was below 0.5%. There are a lot of candidates, but most of them could not fulfill our core requirements a new team member must be able to accomplish. In our case it was TypeScript itself, unit tests, integration tests, working in a Linux environment. Salary requirements for the same position varied $1000 - $20000/mo. Because there is a lot of supply side (read: developers available), one can be picky.
Interestingly, the exercise is so boring (add authentication to a website with tests and documentation, for an outdated framework like Angular) that it probably selects out people who want to have a somewhat interesting job in addition to those who are incompetent.
"Some candidates asked for an interview without completing the exercise. Unfortunately, this was not an option, as this would not be fair for the candidates who worked hard to get to the interview."
This is just how I look at it, but if I reply to a company about a position, I'd like to know about the position before you make me jump through hoops. The exercise itself is okay, and a brief test like this is much, much better than making a candidate fill out an assessment, but why would I invest that kind of time if I don't even know whether or not I want the job. Think about it from the candidate's perspective, some people in this thread note having done 10s/100s of interviews. Imagine how much time they would spend doing menial coding exercises before even getting to know about the actual position other than the JD.
Again, its probably just me, but last year I literally thanked companies for their time because I didn't know anything about the job and their company and they were already asking me to do take home assignments. Sorry but I have a life, and critically to anyone who's hiring; plenty of people reaching out to me not trying to make me jump through hoops. Maybe if you invited more than 24 people for the exercise or just spoke to some people first, you would've gotten a better pool of (potential) candidates.
The position was described upfront on the application page, so you know what to expect. Also, some candidates took the initiative and asked questions. In fact it was even encouraged.
I wrote another post for another position later which has more juicy details like country breakdown
Somewhat related, In the interview, the first question I asked if the candidates had tried to sign up on the website and what they thought about it. It is not encouraging if a candidate had not tried to figure out the company product himself/herself at all.
I agree 100% with the general ideas that "we ask stupid trivia questions when hiring people" and "nobody wants to hire Jrs". I'll toss out one other thing.
The people hiring people SUCK at finding people and waste everyone's time in the process.
The amount of Java / JavaScript confusion that persists among the people who are involved in just finding people reeks of incompetence / and maybe worse.
Head hunting corps, even random company recruiters / HR seem more interested in bringing in mass volumes of names / resumes / warm bodies regardless of how qualified they are. Then they filter and I guess justify their work?
I think of it as the Hiring People Industrial Complex where it feels like the end goal is not actually having even the slightest chance of getting a job, rather the goal is to have a process, go through it, and that's it.
I get so much spam for jobs that aren't right for me, not even in the slightest. I'll even do calls with them and explain that it doesn't really fit, and they still want to move forward to some other inane level of the process, but I know I've got zero chance.
I dunno why this was downvoted. Most recruiters have no idea how to program and thus really aren't qualified to be more than a contracted HR person / keyword matcher. Their main qualification is they have a special account on monster and dice to post qualifications that the hiring company gave them.
There are exceptions, but they are rare, and they don't work for the big recruiting firms. They are just body pushers.
I have had a couple of friends get rejected because HR pulled some engineer that was having a particular bad day (which is completely understandable) i wonder how many good programmers have been filtered because of these interview processes.
> Waited hoping one day someone will hire me without requiring me to white-boarding. Yep it is worse than water-boarding.
Never tried waterboarding, but my issue with white boarding is that it’s deeply subjective. With working code you at least can judge the correctness straight away with a real piece of runnable code. You can also observe how the candidate reasons around the problem and how they formulate and test hypotheses. With a white board you can observe the candi^Wvictim making a table test, a term I first heard in the 70s and last heard in the early 80s. It is just cruel.
Getting any software engineering is probably as easy as 1-2-3. It's getting a promising job, in which you can grow, what's hard.
And yes the recruitment process can be very tedious, illogical and sometimes even unfair.
On the other hand, there are leagues of junior engineers (or just self-taught people after bootcamps) applying for all these jobs, so the process is hard for both sides.
you ignore the methodical, persistent, pre-meditated and enthusiastic efforts of business development people to marginalize, reduce wages and commoditize human workers !
Another aspect might be that companies list job openings when they don't actually need them. It's probably just to gain visibility in the market, justify HR salaries or keep a door open for the next 10x developer who might land on their site. The only ones who lose here are the people taking the interviews and getting rejected for no apparent reason.
585 comments
[ 3.9 ms ] story [ 502 ms ] threadthe price floor for really talented engineers is also high so high in the sense most startups can't afford those 300-400k salaries.
I know a number of folks who work either as developers or on an IT team for a publicly traded company. 300k+ is a stretch but a lot of them pull an extra 30-80k / year more than working at a non-publicly traded company simply because of the stock options they get every year as part of their compensation.
Having publicly traded stock is nice because once you've gotten past the vesting period you can hang onto them for >= 1 year and sell them on demand for 15% long term capital gains tax instead of the usual 35%+ you would have to pay on income tax. Getting an extra 25k to 68k extra post-tax income every year on top of an average dev salary is a big deal.
That said of course the modern coding interview is I think only very loosely correlated with quality.
Of course, every business likes to pretend they're the top and can only hire top talent.
Besides all that, mediocre literally means average. You (collective) should be fine with average and stop overloading terms making general life more difficult than it needs to be.
I have no clue how the term 'mediocre' has come to mean essentially bottom of the barrel proficiency that is still the minimum hiring level quality. The top dog companies can be elitist, but when the company is "MegaCrudSoftware Inc.", it's just plain narcissism. Many Reddit/HN posters exude this in the individual sense and believe they're god's gift to the keyboard and it's just as narcissistic.
Get over yourselves.
Edit: and that similarly goes for how you define mediocre; I think my toptalents are your mediocre. I'll have your mediocre please!
Interesting, I associate 'latest framework' more with trying to keep the monotonous job interesting (or perhaps misguided attempt at keeping sharp) than with 'new challenges'...
That {something} can be web, embedded, ML, etc... it doesn't matter.
The problem is twofold.
First, your skills in {something} are appreciating more than the other skills. If you're a web dev trying to transition to embedded, the skills as a web dev will let you get a more senior spot than going back to a lower experience embedded.
As a $150k/y web dev, would you rather go to $175k/y sr web dev or $125k/y embedded?
It's not that its hard - just that the skills that you've invested time into don't have value and you're going to need to go back to being "just" a competent programmer who needs to learn the domain for anything you switch to.
Secondly, there's the "why are you switching" problem.
If you are switching from web to embedded, the question will come up "why are you switching to a different domain." When that question gets asked, many candidates exhibit a more whimsical or capricious nature of just wanting to do something different. At which point the interviewer is looking at "competent, but likely to leave in a year or two because they got bored" vs "less experienced, but interested in the domain." The second candidate is probably a better choice.
The way to solve that is the personal project and demonstrate that you're interested in the domain at more than a "I'm bored with what I currently do."
Are they mediocre developers? Yeah, absolutely. But under the right guidance they can absolutely be valuable to a company, and our turnover tends to be low because we have a 9-5 culture. It’s less about being a mediocre company versus a company that can’t compete for talent on price, so our talent strategy is to keep it a nice place to work so people want to stay.
The mediocre app/system quality and performance and mediocre security for customer and business data that results creates a (sub-)mediocre customer experience.
What's so bad about... mediocrity? For obvious statistical reasons, most companies, most jobs, and most people are mediocre (or worse).
That's assuming companies exist on a one dimensional spectrum. The more prevailing wisdom is that companies will be mediocre or bad at many things, and good at a couple of particular things, and those couple of things are what make the company viable. This is the essence of a "unique selling point".
But to the point: most companies don't need great developers. Nowdays most medium sized businesses employ some tech staff, but IT is not core to their business.
And if someone mediocre ends up being able to do the job, the company's management may face the fact that they're just a bunch of lame yuppies spending their life in the office to make someone else richer, not changing the world/making the world a better place/any other bullshit eaten from the trashcan of ideology (sniffff).
Well, perceived value rather than actual value. Which might be pretty much equivalent in a field like Sales where it's easy to track figures, but much harder in fields like software.
And in the end, most people are near the centre of the bell-curve of talent, and still manage to produce plenty of value for themselves and their employer. Not everybody has to be extraordinary to keep the society ticking, and the perception that we should always be excellent isn't just counter-productive, but actively harmful (see what magazines did to people's body image).
Nothing, if company managers would admit it.
Instinctively, they know it. The old cult of management-as-a-profession believes that by skillfully directing the activities of replaceable cogs, a company's managers can achieve outsized results.
But they can't admit it because they're afraid that knowledge would demotivate the replaceable cogs.
Nothing, but engineers are expensive, so if you can spend a couple thousand dollars to get better value for the money, you might as well.
Of course, some companies spend far more than that, which is probably not economical.
I have seen enough software projects that certainly didn't fail because the devs lacked ability, there was always another reason and mainly that is leadership not knowing about the problem they try to solve.
A bit of an exception might be more artistic topics like video games. Here marketing and chance play a larger role than management.
Sure, maybe you do cutting edge research, here ability is important again, but that is truly exceptional.
That said, I don't think it is hard to get a job currently.
Because of this, the interview process is not designed to efficiently handle a minority of qualified candidates, but rather efficiently weed out a majority of horrible candidates. It is therefore a terrible process for the people actually qualified to pass it.
Earlier this year I read all these doom and gloom interviewing anecdotes on HN
Spammed resumes to local places for one week. My resume is swiss cheese and I'd been unemployed by choice for quite a while
Totally casual at interviews. Not sober at all
Offers offers offers... places thought nothing of going way over the supposed pay ceiling
Apparently I was the best person they saw in ages? And not fly-by-night firms either
High quality engineering is in demand. There is a talent and knowledge deficit
Hard to not shake your head at top comments crying about nothing but rejections. Go study and stop expecting free money
How is hiring a mediocre developer worse than hiring a charlatan?
Every state in the US is an "at will" state, meaning a company can fire you with no reason as long as it isn't discriminatory towards a protected demographic.
https://worldpopulationreview.com/state-rankings/at-will-emp...
Even with at will, the company can get into difficulty with unfair dismissal and other issues.
The few times I've seen someone fired (and fired fired not PIP or layoff) have been for clear and undeniable issues. The "your work isn't up to performance standards" without a PIP falls into the rare bucket (and more likely at the small companies than the larger ones).
It might be hard to get a FAANG job, but it's not hard to find a $100k legacy code janitor job at any old Fortune 1000 in a flyover state.
Getting the first few years of experience is going to be the hardest--hardest relative to the rest of your career; it's not that hard by any absolute measure. Apply broadly, and take whatever comes. If a company is looking for a junior or mid-level SE and wants "1-3 years" of experience (which is common), your degree is that experience. If you have a CS degree and are in a low- or medium-cost of living area, you should expect $60-80k to start. If have a CS degree and are in a high-cost area, you should expect $100k.
If you don't have a degree or experience, it's going to be harder. But why should a shortcut be easy? Is there a secret backdoor career path for people who want to become physicians without going to medical school? No. Do the work, and earn the reward. There are plenty of online and nighttime options for earning a CS degree.
If you apply somewhere and don't get a call back, don't sweat it, and don't take it personally. It just doesn't matter. Hiring is a noisy process, and the cost of a bad hire is tremendous. Most companies will try harder to reduce the number of false positives than to reduce the number of false negatives. Again, apply broadly and treat it like a numbers game. There are limits, though. If you've applied for 10 jobs and not gotten a single interview, pay a professional to rewrite your resume for you.
If you're getting interviews and bombing the technical questions, then study. If you're bombing the cultural/behavioral questions, read some self-help books and join Toastmasters. If you think you're acing the interviews and not getting any jobs, then you're probably bombing something but are too clueless to realize it. Hire an interview coach.
If you're at the point where you have a degree or 5ish years of experience (or ideally both), you are ready to be a $100k code janitor. Learn a common stack well enough to do smart things with it. For instance, if you learn .NET, you should be able to manipulate collections in interesting ways with a single expressive LINQ statement. Pick one from each category (but don't combine Java with SQL Server - I don't think you'll see it as much in the wild):
1. Java or .NET
2. Angular or React
3. SQL Server, Oracle, MySQL, or PostgreSQL
I'm going to offend a ton of niche fanboys now: Don't pick Vue, Go, Erlang, Haskell, or Rust. I'm sure each of them is amazing in its own way, but getting a job is your goal, so you don't pick a technology used by only 1% of employers.
Now I'll offend the embedded and systems programmers: Don't pick C or C++. They're just not widely used in business applications. I know both (at only an intermediate level), but I've never seen either used in a business application. You should know both on some level, but you're not going to get a Fortune 1000 code janitor job with either of them.
Congrats, you are now qualified for the majority of SE job postings at non-tech companies.
19.5 years of programming, but mostly web programming for the last ~12. I want to move away from that, I am sick of it already. There's always something more to learn and even though I don't mind at all -- it keeps my mind sharp which is something I want to keep all the way to my death! -- the churn of knowledge in there is exhausting.
> If you have a CS degree...
I am not from USA and have no degree. I am 41 y/o and I'm a self-taught programmer ever since 12 y/o. Not sure how well that flies on interviews; I feel the US companies put a lot of value on degrees?
> If you apply somewhere and don't get a call back, don't sweat it, and don't take it personally. It just doesn't matter. Hiring is a noisy process...
Completely agreed. I've been in a rough mental and physical health patch for ~3 years now and I've changed more employers/customers than I wanted. Tech hiring is completely broken indeed. You're quite right.
> I'm going to offend a ton of niche fanboys now: Don't pick Vue, Go, Erlang, Haskell, or Rust.
I am not a fanboy at all. I've used 8 languages over my career -- Elixir (stepping on Erlang) and Rust included and I've picked them based on their true, proven and testimonialized merits.
I don't take offense with your statement at all. I presume you meant "aim for something huge and somewhat commoditized that has a ton of legacy code to maintain"? If so, I'll agree with you immediately; there was a period during which I've been barraged by offers from German and Swiss companies almost every day, for months -- all for Java and C# huge legacy beasts.
But sadly that's not where my heart is. :(
Furthermore, I am willing to bet my neck most of those are NOT a code janitor job at all. They'll require a ton of time and attention every day. If I'll do that I'll just find an Elixir or Rust job but at least be happy with the tech stack (if not the area -- the webdev -- which I hate with a passion nowadays).
> Now I'll offend the embedded and systems programmers: Don't pick C or C++. They're just not widely used in business applications.
I haven't been an active C/C++ programmer for like 12-13 years now but IMO you're not on the mark here: there are a lot of business apps but they usually belong in huge old mastodons that are too stubborn to move on (I personally know the VPs of engineering in two such companies!).
But overall you are right -- they are niche but not the good kind of niche; you need a metric ton of battle scars to even qualify there.
> Congrats, you are now qualified for the majority of SE job postings at non-tech companies.
I'd agree but I've neglected networking -- both physical and virtual -- for most of my career and now at 41 y/o I started to feel the negative effects of that. :|
The churn of knowledge can be limited by choosing technologies that don't require constant adaptation. (Time to offend the .NET fanboys): If you pick .NET, there isn't that much difference between .NET Framework 4.5 (from 2012) and the latest version of core. The job still gets done, just with a different set of packages. If you don't have a use for async/await or the TPL, you can go as far back as 3.5 (from 2007).
> I am not from USA and have no degree. I am 41 y/o and I'm a self-taught programmer ever since 12 y/o. Not sure how well that flies on interviews; I feel the US companies put a lot of value on degrees?
Some do, but with 19.5 years of experience, this wouldn't be much of an impediment for you in the United States. All of my opinions apply only to the United States. I haven't worked in other countries and can't comment on them.
> They'll require a ton of time and attention every day.
IMO, a "code janitor" doesn't just sit around all day reading HN. When I use those words, I mean the type of job where you're expected to fix bugs and implement features and not much else. Even if there is talk of higher expectations, there are never any consequences for just going with the flow. You'll rarely/never be asked to work overtime or learn on your own time. You'll only pay lip service to clean code, clean architecture, and long-term thinking. You'll still be expected to show up by 9, hang around until 4, and not screw off the whole time. The job is still a job; it just doesn't strain your brain.
> I'd agree but I've neglected networking -- both physical and virtual -- for most of my career and now at 41 y/o I started to feel the negative effects of that. :|
Headhunters are the antidote to this. When a recruiter wants to connect on LinkedIn and have a short phone conversation about an exciting new position, you always say yes. And if they're not sending connection requests to you, then you send the request to them.
Yes. We are on the same page, just using different words.
I definitely didn't mean "slacking off". I meant exactly what you said: have 3.5 to 4.5 hours of good solid programming work per day (because realistically that's what most programmers cover in terms of actual focused productive time in the standard 8h work day) where you have already ticked the boxes (or nobody cares about them as you said) so you just pull stuff from a backlog and move at a steady pace with not much supervision.
The company I am very soon starting with has people I like very much, plus I love what they do. But if that turns sour then I'd likely be looking for 2-3 "code janitor" jobs in parallel in order to protect my mental health for a while.
> When a recruiter wants to connect on LinkedIn and have a short phone conversation about an exciting new position, you always say yes.
Maybe you are right. To me outright insisting on a phone call is very disruptive and out of place. I've tried it several times and maybe I drew the short end of the stick every time but they all were young and fairly clueless HRs who just wanted to parrot their speech that was supposed to motivate me and then immediately pressure me for an answer. Don't know, didn't find that a good expenditure of my time.
Maybe I am doing something wrong, I am open to that, but I really am not sure that I want to expose myself to such toxic time wasters. Any advice?
Oh, I wouldn't try to juggle multiple code janitor jobs. It only takes one good one to pay my bills. And it would defeat the benefits that I perceive in the code janitor job. If someone wants to put that level of effort into his career, he's better off aiming higher.
> Maybe I am doing something wrong, I am open to that, but I really am not sure that I want to expose myself to such toxic time wasters. Any advice?
Ask for the client and salary range immediately. If they don't give you a straight answer, politely end the conversation.
That's... actually a very good advice!
But what if they counter it with "we'd like to hear your expectations first"?
> If someone wants to put that level of effort into his career, he's better off aiming higher.
You are right but I have zero clue how to aim higher, exactly. Hence my idea.
If it's an internal recruiter, you might get that question. In that case, have a good idea of what you're looking for, and throw out a number at the top end of the range. If you're talking about a senior software engineer job, and you know that, in your area, they generally pay $120-150k, then say $160k. If you want, condition it based on total comp and benefits. Most Fortune 1000 code janitor jobs will offer a nominal bonus, anywhere between 5-20% of salary. Nothing like the huge FAANG bonus structures. But saying "depending on TC and benefits" gives you some leeway to ask for something even higher later on. And it tells them that, if they can pay you $150k plus a 20% bonus, then you could be happy with that. It leaves the conversation open.
If that makes them walk away, then you didn't want to work there. And don't feel bad negotiating like this even if you're going for a code janitor job. Compensation correlates with negotiating skill more than software engineering skill. It's just the way things are.
So I started wondering if I can pivot to the US market -- which was never a goal.
I appreciate your advice. Insecurity and the impostor syndrome can hit even super capable people (I've seen it). Your words help me reassert my self-confidence, and that's sometimes shaky. :)
The amount of money that actually gets delivered to a worker's bank account could be a little as 2/3 of their stated salary.
And many things cost more here.
It'd be a good idea to work the numbers and figure out what your take-home pay would be and how your expenses would change. There are some expat websites devoted to this.
Be up front you about what you are doing. They are going to think 'he is going to jump at any time'.
Be willing to stay there awhile. But be warned some of these places there may be one to two 'big companies' that hire there (and if they do not hire you are SOL). There may be some small startups here and there. So plan on that. There may not be much to choose from there for you. It is why many move away from those areas. So if you are 'lucky' enough to get into one of the companies do not plan on jumping around a lot. You will burn bridges and the community of devs is small there, and they talk.
Be willing to dig into some seriously legacy code. "oh we still use sourcesafe and vb5". The Joel test is a good indicator of how strong they are. "oh we buy the best for our devs" and the computer on existing devs desks is some beige box from the late 2000s with a CRT.
Set your pay expectations much lower than what you are used to. Had one I was looking at, I was one of 3 people who applied. He passed me over because 'I was not in the same state'. I had 5 years 'full stack' exp on the exact type of system he was working on. After a bit of back and forth they wanted to pay nearly half of what I was looking for. Which was not terribly out of line for that area. Another dude thought he could snag me for 1/4th what I wanted. These guys can be cheap. They have a product someone tinkered together years ago. But they do not have enough income to really justify any sort of real work. So they do what they can and usually just farm it out to some consultant group.
You've hit the nail on the head here and this is my main worry. I've been much more selfish lately (last 3-ish years) and I know I definitely did burn some bridges but I can't make myself care very much -- I am 41 y/o and at one point participating in a one-sided "exchange" of trying to appease while mostly humiliating yourself becomes impossible to swallow (but then again, I recognize I've had both shitty luck and self-selected bad employers due to personal drawbacks that I am still actively fighting with).
> Be willing to dig into some seriously legacy code. "oh we still use sourcesafe and vb5".
One of my strongest selling points as a senior dev is that (a) I don't mind dirty and heavy work at all, and (b) I have an excellent eye for detail, very rarely miss something and (c) I try to leave the code with better readability after I finish my current task on it.
That being said, many companies are too impatient. I've hit the brick wall of "we want somebody who can hit the ground running and we won't provide any training" personally at least 5 times in the last 3 years. And I seriously don't know what to do about that; I certainly can't know all tech stacks and domain expertises on the planet!
And it's flabbergasting how much in denial many companies are about the risk management aspect. I mean they know; they absolutely know what's going on but they concluded that training new hires is a huge business risk (due to most people never staying more than 2 years on a job) so people like myself -- even if senior and very experienced -- have literally 1% chance of getting hired in many such places.
They do have a point and they are mostly acting rationally in this situation; but they could still spare some minimal training so they stand to gain a bit more from the employee that's going to move on maximum 24 months after being hired. One or two months of training isn't that expensive for them I'd think.
> These guys can be cheap. They have a product someone tinkered together years ago. But they do not have enough income to really justify any sort of real work. So they do what they can and usually just farm it out to some consultant group.
I am realistic about that aspect and I accept it. If they wanted to pay top dollar they'd just court somebody who is 45-50 or more for several months and then do their very best to promise them retirement in the company and all the good stuff that a long stay can benefit the person.
I know they want to pay less but I'd aim for having 3-4 such customers, independently, and collect a 120% - 200% of my normal payment combined through such venues. Not always sustainable in terms of mental strain and energy but I've pulled it off successfully even as shortly as 9-10 months ago without being hugely taxed in terms of health.
RE: the consultant group trope, I suppose this is where I fail in terms of marketing. Many companies just can't take a single random person seriously even if he's John Carmack in disguise. I suspect I need to make a fancy consulting website with some fake testimonials and pretty graphics, have a photo in a rented suit and then I'll suddenly be taken seriously. People can be very shallow and easy to manipulate, huh?
I am a bit flippant here but I likely should indeed work on marketing. But how does one strong and senior single programmer advertise themselves as a consultant or, generally, a guy you go to to solve a business problem, and who is not a wage lemming? Got any pointers on that?
For your last Q I would say a lot of the same points still matter. They are going to want someone 'local'. Someone who can come in on a moments notice when they are in the thick of it. Also keep in mind a business is not programming. I would suspect what you are really asking is 'how do I sell things'. That is a much different topic. But targeted advertising, cold calling, trade shows, emails to former and clients and colleagues. It may be worth looking into hiring an advertisement firm for some small ideas. Do what you want your customer to do and hire an expert. If you do not have the cash for that you are going to have to do it yourself. Your personal network is probably your best bet for starting to grow your business network. My dad a former insurance salesman spent a lot of time in bars selling and meeting people. They had hundreds of hours of training they took to be any good at it. It may even be worth getting a short part time job as a salesman to get the idea of what to do. Think of it as just as there are jr devs you are jr salesman. But keep in mind, there are several types of sales. Those that sell themselves (they were already going to buy it, it is just from who that matters). Those where you need to work the sale. This is the harder type. You have to basically sell yourself to them. This is either showing them they have an existing need that is not being fed, or faking it by 'creating' a need they did not know they had. Another way is to associate yourself to one of the consultant groups out there. They take a cut but can help with lead generation.
I see many, many more developers lamenting the "requirement" of a CS degree to get a software development job than I see lawyers lamenting the "requirement" of a law degree for a law job or doctors lamenting the "requirement" of a medical degree for a doctor job. If it opens doors, and you want that door open... get the degree!
CS Degrees from local universities can be had for far less cost than a 250k law degree and less time than a 13 year MD.
This year I became a co-owner of the company that worked at for the past three years. It's a small development and consulting company and we're currently struggling to find new developers. At the same time, my girlfriend is trying to get her foot into this field. Since she's interested in a completely different tech stack than what we use, hiring her through good ol' nepotism is not going to happen. This situation gives me a small glimpse into both sides of the whole equation.
Before I continue, I want to point out that no side is at fault here. It's just market forces at play.
So why don't companies want to hire newcomers? It's simple, really. It's never worth it.
Even newcomers want competitive salaries because bootcamps, popular media, etc. paint the picture of a career in software-development as being extremely well-paid and with great benefits. This picture is absolutely true -- for senior developers. Meanwhile newcomers need to be trained and built-up, often with intensive mentoring from senior staff. In general, there's nothing wrong with that. I had a great mentor and in turn I love mentoring. But once they've gained know-how and experience, they will look for a different company hoping to use their newly acquired commercial experience as leverage to get better compensation. And that's exactly what they should do! Trust no employer that talks about crap like loyalty. Leaving your first job after max 2 years is something I would recommend every new developer. It is what the legendary Andrew Hunt (author of The Pragmatic Programmer) recommends in this podcast episode. If your first employer gives you a hefty competitive raise to keep you, use it as the new base for negotiations and still try to switch because, as Hunt puts it, at the beginning of your career it's crucial for you to expose yourself to different technologies. Maybe you'll start out as a web developer only to find out after your first job switch that you're much happier in embedded systems. Switch jobs often. Forget loyalty.
But what does that mean for employers? Let me explain it with a few of our cases. In the past, we tried hiring newcomers multiple times. In the most recent case, I was the senior responsible for the new hire. I spent up to 16 hours per week on one-on-one training in the first 6 months to get them up to speed in anticipation of a big project. They left us after 14 months for a different job in the middle of said project. I do not blame them, it's the exact right thing to do. For us, this was our third failed attempt of hiring newcomers and it was frustrating and extremely costly.
Since we're a B2B company creating software for IT departments, I asked around to see how our clients approach this whole situation. And the consensus is, "We refuse to train the future employees of our competitors. Hiring newcomers is a waste of resources. Paying the premium to get senior developers is always better." Especially small IT and software departments/businesses cannot afford training people who will just ditch the place within 2 years while big players like the FAANG companies can and have their pick from the very best newcomers.
As a result, entering this field is incredibly difficult and one has to essentially hope a company is dumb or desperate enough to take the gamble of hiring someone trying to get into developing.
So how can this be fixed? Well, I don't think there's a fix. Most newcomers will never find a job and quit trying to enter this field, the lack of senior developers is going to hurt small and mid-sized companies in the long run and many of them will eventually disappear from the market as their current developers are reaching retirement and cannot be replenished. Only newcomers who give the impression that they don't need extensive training will ever have a chance to get hired. As such, my recommendation is portfolio is king.
Small, not tech heavy companies like simple webshops, small crowdfunding platforms, etc will need someone, ANYONE, to keep working on their giant stack of legacy PHP/Rails/whatever code. The business does not support hiring very senior people and the founders are not technical at all so they don't recognize the troubles inherent in hiring a full team of juniors.After a few years the business may fold, but at that point the junior devs have gained some experience and move onwards and upwards. The attitude of "We refuse to train the future employees of our competitors.", while not un-true, fails when you can't even hire seniors.
First there’s a code fluency wall you have to get over.
Then there’s a tech debt/spaghetti lesson that needs to be learned (IMO this can only be learned the hard way)
I did this with 6 months working on my own stuff 12 hours/day, then 6 months working for nothing but equity in a never gonna happen startup.
Once someone is over those two walls, they can be useful to a company. Absolutely never writing greenfield stuff, but maintenance, matching style, very clear start and end type stuff for at least a year.
Before you’ve internalized code as a fluent language and developed basic code hygiene, you should not look for a development job. Even if you get one you will be an imposter.
In what other technical field are you expected, post-school (which probably hasn't taught you a ton of practical skills), to spend a year on your own making yourself employable?
The closest comparison I have is professional musician.
you’re supposed to love the language of music. If you don’t, good luck.
And very little in common with how most people treat other technical professions.
The reason is because — between the people with the genuine love of the field plus those drawn in by the lure of the high-end pay — there is such an oversupply.
Software also sits at this technical/creative/implementation intersection where unless you're doing something very specific, you're going to need to push/pull in different directions.
A lot of software doesn't do anything exciting, standard office CRUD, dashboards, back office tools can be banged together by a single developer as long as they can connect to a database, render a UI (web/desktop) and take requirements from the business.
There's a lot of software jobs which aren't at software companies but regular businesses who just need to track something domain specific and can't afford to tender.
I will say that I've hired a couple of newer developers and in some cases they've moved on, but in other cases they've stayed with the company I was at when I hired them, in some cases for 3+ years. So not everyone leaves after 2 years.
I think that companies need to be really explicit about their training and goals and try to make employees happy. Yes, that bootcamp grad is going to be super happy to work for you for the first year, and grateful to have the experience. But, yes, they are going to start looking around. So plan for how to meet their needs as best you can. Some folks will simply be on the hunt for difference and comp, others will be happy to stay at the same company if you can challenge them and continue to let them grow.
> ... at the beginning of your career it's crucial for you to expose yourself to different technologies
This is one reason I feel like a small consulting shop is the best place to start a software development career. You matter (because it is a small shop) and you'll get exposure to many domains and technologies (because it is a consulting shop).
The second part is that the trade has a bonded period. Depending on how that is written, this becomes more difficult to enforce with at will employment. It can also lead to companies taking significant advantage of their bonded juniors. I mean... if you think this is a good model, revature is out there.
The trades face the same challenge. Over the past decade, I've gotten along well enough with my HVAC guy (one-man shop who brings on a rotating cast of apprentices) to talk with him about this. He reports the same experience ("no matter how much you train them, don't seem to be able to move beyond...").
This isn't a case of "can / cannot solve problems", either. For hobbies they delve in, that cohort appears to problem solve extremely well. I suspect the challenge is finding ways to communicate a mental model of the same problem domain that "clicks" with different personalities.
The "skilled trades" with hvac, electrician, plumbing, carpentry and such where the apprenticeship is more appropriate do have that issue again.
While it is often argued and parts of it have been refuted - The Camel Has Two Humps ( http://www.eis.mdx.ac.uk/research/PhDArea/saeed/paper1.pdf ) is applicable here.
There are people, for whatever reason, can't accept a different mental model than what they've got in their head. Software development is about twisting how you think to that of how a computer works.
I've presented this very light model of "levels":
A junior follows instructions
A mid completes tasks
A senior solves problems
There are people who plateau at each level and never go beyond that for whatever reason. In many cases it is a failure of putting the proper problem solving / learning skills in place to be able to think in a way that isn't the easy way.
* How do we prevent a predatory apprenticeship?
* How do we ensure that a non-predatory apprenticeships are able to keep their staff for a long enough duration that they're not losing out?
There is a part B to the first question on preventing predatory apprenticeships. There was an anecdote told on reddit of a person who was trying to get out of tech support and so signed with Revature for becoming a software developer, went through their bootcamp and then got placed at a company. That company found that he was rather skilled at doing tech support (rather than as a junior dev) and so moved his contract over to do tech support... getting paid less than he was getting paid doing tech support prior to joining Revature. Furthermore, the locked in two year contract meant that he did tech support for two years. At the end of this, he's got two more years of tech support on his resume that paid him less than what he was making before and no additional software development accomplishments.
So yea... Predatory apprenticeships are a problem.
The way that the "stay around long enough" of old was a signing bonus. When I started in '96 with Taos ($54k/y), I got a $5k signing bonus and $1/mile moving bonus (Mapquest was a new thing - HR was amazed at how much easier that was going to make their job in calculating the moving bonus). If I left before a year was up, I'd have to pay it back.
That works reasonably well enough when salaries are about balanced overall. But it works poorly when there are some jobs that can either offer a much larger bonus or the new pay can quickly repay the bonus. If you're making $75k/y and have a $10k bonus to repay and then get a job for $150k that bonus can be repaid within a month or so (by the time accounting sends out the "pay us back" the bonus is ready to be paid back with the increase).
I disagree here, and I think this is the main reason we're having this conversation. If someone has been trained up or learned on the job such that their skills are more valuable, then their employer should treat them as such and give them a raise. I've seen time and time again that good employees leave just to get compensated fairly. Alternatively people get disgruntled and leave when an experienced outside hire is brought in at a higher pay band to struggle to do the same work that they've spent years learning to do.
This is crazy. If the junior needs more than 1 hour a day to be net positive (= do more work in the remaining 7 hours that you would do in that lost hour) then I would say they are a lost cause.
This is also so easy to filter at the interview level - give them homework to learn some new skill, junior candidates are generally willing to spend significant time on that and it gives you much better picture of their abilities than whiteboard puzzle.
That's what my experience says, including the conclusion.
That means that the true cost of a junior candidate vs a senior candidate isn't just their 1st year salary difference on paper, you have to count in the cost of training _and_ retaining the junior hire. That doesn't necessarily mean the math doesn't work - especially if the market for senior developers is much tighter than for junior developers.
Also the idea that you'd be mentoring for 16 hours a week one-on-one seems like it is either inflated or there was a problem. Maybe the candidate was a bad hire even for a junior role, or the mentor is micromanaging, or the work product expected was never appropriate for a junior developer - but something seems off there.
Front line recruiters tend to be non-technical, and can't pattern match for good candidates outside of very narrow criteria. (ex: They won't know that a person with strong C# skills will likely be just fine with Java.)
Just getting your resume in front of actual people doing the hiring is hard. My experience is that if you want to make it easier to hiring talented software engineers you need to make it easier to get the right candidates in front of the actual hiring team.
I agree it's not very meritocratic, but it DOES get people in front of people more qualified to pattern match their qualifications more quickly.
The problem with getting more people in front of the actual hiring team is the "charlatans" other people have mentioned in this thread will effectively waste the (very expensive) time of said team. Using a (less expensive) recruiter as a first stage seems rational until you discover the high rate of false negatives.
I've mulled this problem a lot and I still come up empty on a new, more effective way to solve it.
I think the explanation is quite obvious. People who gravitate to this industry are not as social as those who gravitate to other industries, hence the disdain for (or rejection of) the process that leans heavily on something that doesn't easily come to them, that feels like something they shouldn't have to be dealing with.
Sounds like a problem with the job description, rather than the recruiters.
Sometimes you really do want an expert in a narrow domain, using a specific framework/language. Other times you don't. This needs to be communicated to the recruiters.
Engineers love to lay the blame on the recruiters. In my experience, the recruiters are usually just a mirror for what the hiring managers are asking for. If the hiring managers do a poor job of defining the role, then how do you expect a recruiter to find good candidates for that role?
If Java and/or C# experience works, communicate that to the recruiter. Don't just assume they will know. Even as an engineer, if someone asked me to find a Java candidate, I would find a Java candidate. I would not make assumptions about what other experience would fulfill the requirements.
As far as filtering being the problem, I highly doubt it. Most of the complaints I hear from people are about the interview process. I know a few engineers that can't get hired, and it's not because of a lack of interviews. They just can't pass the interviews.
Same nonsense though; here’s some random leetcode problem; sure our company hasn’t made anything novel or proven itself in the market but we Googled how to do a tech interview and this is what we found.
Getting a job is hard because people are lazy. They’re just regurgitating what popular companies are doing, whether it’s good for them or not.
In many other fields (medicine, law) people study a standardized body of knowledge, take a standard test and then get a license so they can do something others cannot.
However, this doesn't prevent a lot of awful and a lot of great people getting through. You would still need to interview a lot of them. I wonder if it sets a minimal level.
I assume it actually works pretty well but there's obviously a huge amount of gatekeeping involved.
This is more a random fluke as much as sampling bias. Akin to someone either getting lucky or someone who is coming from a very similar environment. This isn’t a measurement that guarantees someone is competent, rather it’s a guarantee that someone is coming from just as incompetent an environment as you have.
These results may be "curved".
If you give the same easy test with no pressure and everyone is sufficiently good, then it was a waste of everyone's time.
In such an approach, you do something that is sufficiently hard that you're able to identify the people who are the better performing ones along with a reasonable idea of how well they work under pressure (because that will happen at some point).
Is it testing the right thing? Probably not. However, we still haven't found "the right thing" that is able to scale, respectful of the time of the candidate, not too intensive on the interviewer, and minimizes biases in hiring (same set of questions to all candidates, same grading scale).
Maybe because the concept of a test is flawed? It seems to me like every company that uses a whiteboard test gives out the same tests anyways.
What are they really trying to test? If someone understands common algorithms and data structures? I dont see why that couldnt be determined by a simple interview with an engineer. A test might be useful for a HR recruiter who doesnt have a computer science background, but those tests are usually conducted by other engineers anyways.
The whiteboard thing just seems to me like an arbitrary hazing ritual.
My experience has been that this applies to recruiting, hiring, BD, sales, fundraising, etc. Anywhere that there's a systemic principal-agent problem.
I am wondering if the entire interview process should just be pay them for 2 weeks and see if they stick.
I've heard that advice in various forms but I must say (anecdote incoming) - in my own 30 year career, the best jobs I've ever had were the random ones that I just applied for and the worst ones were the ones that somebody I knew from before recruited me in from outside.
Speaking only of ICs:
From principal engineers down, there's a technical screening. Distinguished engineers? Maybe. But then you're speaking about Guido van Rossum, James Gosling types.
Am I on the top of my game right then and not stressed about anything and the questions out of the random million possible questions that could come up are ones that I just happen to have had on my mind recently? Then I ace the interview.
The last time that happened it was in a big international consulting company, they then put me through 5 other interviews afterwards, each one telling me I would hear something back in the next couple days.
The last one I got told couple more days, they didn't call me back for nearly two weeks. Then they call: Hey Bryan, we would complete the offer process now hope you're still interested?
Uhm unfortunately I got an offer last week for a 6 month consulting project, sorry but I had to take it because they said they couldn't wait to see how this turned out.
on edit: clarification.
I have over 20 years of programming experience, am a founder, and have worked for multiple venture backed startups. That includes hiring countless developers, so I get both sides of the situation. And my partner is also a tech recruiter for a top tier HFT / market maker, so I know what a demanding but respectful hiring process looks like.
Reddit’s hiring process converted me from a fan of the site into someone that thought the entire organization was second tier - which obviously it is in terms of monetization - but also in how they treat people compared to the FAANGs. And a year later the role is still open.
When the interview was over I thought, "Is this how working with these guys is going to be?" If I ran into a problem and went to them for help, would they just stare at me, waiting for me to figure it out on my own?
They didn't extend an offer to me and, based on my performance in that interview, I can't say I blame them. I'm not sure I would have accepted if they had, however. That experience really left me with a bad taste in my mouth and a low impression of that company.
We as an industry really REALLY need to figure out a better way of conducting interviews.
Unfortunately, yes. Young engineers are terrible at communication and working with others. Partly due to workplace incentives and partly because you must realize that entire generations have grown up with computers and not people.
A good friend of mine worked with a young developer recently who was excited about what he was able to generate with a single npm command. When my friend, who has been writing software longer than this guy has been alive, calmly pointed out that the npm command had just generated 400 files and thousands of lines of code that didn't actually solve their problem, this guy got mad and went to complain to their manager.
"Wow! I can do so much with so little!"
"Everything you just generated is wasteful and meaningless."
The right way is to encourage that enthusiasm and guide them toward doing more useful work with the same power they just discovered.
In your interview case, they should have given you hints, even if they want to not hire you later.
Looking back there's no way I would have fit in there, but damn did that interview screw me up for a while.
You’re making the same mistake at vetting them that they’re making at vetting you
Which is exactly why they do irrelevant interview brainteasers as well
This problem is a two way street in the tech sector, in case anyone wanted to fix it. The candidates alone are making the same mistake and bringing it to the company
Similarly, a false positive is something that was accepted, when it should have been rejected.
If you have a sufficiently high candidate pool. you can (for a while, at least) live with an interview process with a relatively high false negative rate (that is, x% of the time you don't hire people you should have).
If it is typically quick to go from "in through the door" to "is a productive member of the team", it may be that you can live with a high false positive rate (that is, y% of the time you hire people you shouldn't have).
The technical competence check is all retrospective, hearing them talk about prior projects and what the design and implementation process was like, how decisions were made, what the challenges were and how they were handled, any regrets/learnings. And most of that is just digging in far enough to confirm that the person was actually a first-class participant in it with a deep understanding, and not a bystander. Any whiteboard stuff would be "show us how the system worked" as a last-ditch check on basic communication skills.
This all requires that the interviewer be willing to interact deeply with the candidate. Our profession has a (well deserved, I think) reputation for having a high percentage of people who really don't like interacting with others on a peer level.
Is it likely that a large part of the problem is that we have people doing interviews who really shouldn't be? I mean, if your typical response to talking to another technical person is immediately to try to one-up them, then you're going to be a really shitty interviewer. And that's exactly the personality type I see being described over and over in these anecdotes.
I can tell you, with quite substantial sample size from me directly and from people I deeply trust that every time we encountered an interview like this, we later found out that the company culture was really bad.
Those are not the kind of people you want to work with.
> I had a similar interview with a different company last year. Three guys and me on a Zoom call with me sharing my screen trying to solve a coding problem that in no way resembled anything I have ever encountered in my 25 year career. When I got stuck they just stared at me. They would not give me any hints whatsoever. They just stared at me.
English has this expression too, except it's "The fish rots from the head". (Which, when you think about it, makes more sense.) What's your first language?
The psychological reality behind all this is even worse.
The interviewer is not looking for new colleagues, he is looking to improve his own self-esteem and rank. The reward for rejecting a candidate is a feeling of superiority and an appearance of being irreplaceable.
The interviewer and the candidate have opposing goals, and the interviewer can randomly change the rules at any point.
But then I've always been interviewing for my own future colleagues/boss/reports. I guess the dynamics could be different if you're in a huge company and just generically interviewing for new cogs that might get slotted anywhere.
If the person is smarter than me even better! Instead of spending time teaching them maybe I can learn from them and get into their network so that if I ever need a job in the future they can help me out.
It only later dawned to me that our industry has a non-trivial fraction of people for whom empathy is a foreign concept. They're not sociopaths, because those folks can at least feign empathy - we're talking about individuals who can't see themselves in another person's situation at all. On top of that, we don't really provide actual interview training to engineers either. Out of all the people I personally know in London, only one (1) has received formal interview training.
Is it any wonder that the interview gauntlet is such an awful experience for pretty much everyone?
Which is noble, I suppose. But clearly lots of people still felt that it was unfair and alienating; closer in spirit to a hazing than a good-faith evaluation.
Here's why https://blog.codinghorror.com/why-cant-programmers-program/
- Tell us about the approach you took with the take-home coding challenge. Why did you break up the functionality in the way that you did (modules/classes/functions)? What kinds of constraints or requirements would cause you to make a different call here?
- Tell us a debugging war story. What was the bug, how did you discover it and come to eventually understand the root cause? Any challenges with reproduction? What steps were taken to prevent it from happening again?
- Pick a feature of XXX programming language and explain how it contrasts with approaches taken in other languages. What do you like about it? It is more productive, efficient, safer, more explicit? What are the tradeoffs and how do you balance these? What kinds of projects would have you prioritizing using a language/ecosystem with this capability?
Someone incapable of writing a fizzbuzz program is not going to be able to bluff their way through an interview like this. Obviously you need to be committed to listening and exploring the space with the other person as opposed to flexing and looking for the "right" answer, but that's just part of the discipline of being a good interviewer and not a jackass.
Coding exercises entirely miss the point, because writing code is the easy part. The hard part about good software engineering is being able to rapidly acquire problem domain expertise and knowing which engineering design choices enable rapid, scalable, and maintainable development to solve the problem. That's why companies using code exercises to screen candidates are generally not worth the interviewee's time to work for - it indicates that the interviewers don't understand the problem domain, either, and (by extension) that company is mired in mediocrity.
I've had code exercise interviews. I'm quite happy that I have never had to work for one of the companies that used them. I have never given a code exercise interview, and I've been quite pleased with the candidates that have responded and worked with me.
"How would you pull in data from an arbitrarily long -- maybe never-ending -- source of data in Python?"
me : "What kind of data? What is it used for? How should it be represented afterwards?"
Silence on the other end , followed by "Well that's up to you."
I then fumble out a few ways to do it (verbally), to a recruiter that doesn't seem to understand anything that i'm saying -- he's probably reading a question from a script and pattern-matching what I say to the supposedly correct answer given to him in the same script.
Finally it ends with "Oh, that's interesting. ...We'll get back to you." , and the interviews that go this direction -- they never get back to you; you've already lost.
I'm not spouting gibberish, i've been at this for a long time; i'm just not spouting out whatever tech-jargon that their company supports and is needed to conform to his script, and quite honestly the person on the other end of the phone call seems to be universally under-equipped to judge anything remotely CS related.
It's a really weird/ephemeral/surreal experience. Imagine a surgeon being appointed to a position at a hospital because the secretary quizzed him on some flash cards (flash cards provided by Acme Sharp Scalpels), and the surgeon -- by chance -- prefers Acme Sharp Scalpels, and so mentions that brand. Instant hire according to the flash cards.
That's a lot like what it's like when a technically-accurate developer gets passed over for one that blithely mentions popular software packages (pandas/tensorflow/whatever is popular this week) without any real technical knowledge on how to achieve the goals wanted by the hiring party.
The answer to this question is to use a generator. If you don't know this, then both people are going to wish that they had that half hour of their life back.
Is this a good question? If you want somebody with a lot of Python expertise, then knowing about generators is a good thing.
If I was interviewing a candidate, and they didn't know this, then I would just find a pleasant way to move on after a minute or two. If this is the only interviewing question, then that makes me happy, because this company has a flawed process, and is leaving some great talent for me to hire.
It's not a big deal if you didn't know this at the time. You might not have known what a generator was, and the person interviewing probably wasn't very good at interviewing people.
I think that's only applicable if you are reading from a socket. Although I don't know too much about asyncio streams.py, so I'm not going to get a job at this company.
> The answer to this question is to use a generator. If you don't know this, then both people are going to wish that they had that half hour of their life back.
That's funny...I've implemented more than my share of such things in a long career, and my first intuition for an answer to the question, as phrased, was to implement stream sampling. It never even occurred to me that the answer might be a syntactical feature of the language (and yes, I know what generators are).
According to you, I'd be so wrong that I'm a waste of time.
Do you see the problem yet? It isn't theoretical. I've hit this kind of situation with so many interviewers that I'm actually more nervous when I'm sitting across from someone who is clearly on their first or second job out of school. They're asking (unclear) questions in the "python syntax" category, and I'm thinking about the engineering consequences of consuming an endless stream of data...
I don't think so, because you actually know about generators. If you were hiring for people who had a lot of Python experience, but didn't know about generators, that would be a bad sign. You would probably want to ask a some other questions, so you would have a more complete picture of what the candidate knows.
My main point is that the company's interview process is flawed.
Sure, but will the OP give me a chance to demonstrate, or simply flip the idiot bit as soon as I don't give the expected response? In the context of a phone interview, I probably wouldn't get anywhere near discussion of python generators in an answer to this question. I'd probably say something like:
"For an infinite stream, my main concern is system resources, which are never infinite...I'd want to use something like stream sampling to calculate the desired metrics, but it's hard to know the right solution without more information about the problem."
Far too many interviewers hear that as weasel-wording, and simply disengage. It's even worse when the interviewer thinks they're asking a clear question about python syntax. It takes a high level of self-awareness to know that you might be the problem when you're the interviewer.
An experienced interviewer might engage with that, but many folks don't have the patience to listen to an unexpected response, nor the respect for the candidate to give them the benefit of the doubt. As I said, this pattern isn't theoretical. I've been on the interviewer end of this kind of pattern many times before.
> My main point is that the company's interview process is flawed.
Agreed on this.
This is a...youthful...industry, and a lot of junior people (with "senior" titles!) are out there doing interviews. It takes experience to become a good interviewer, and if you've never had that experience, you don't know what you don't know.
It surely matters if the data source is push or poll or something else, matters if it's a lot of data or a trickle, matters if you need all of it or if you can miss some (and how much), if the source buffers it or doesn't. I'd expect discussions about message busses, queueing, buffering (maybe ring buffers), data stores (maybe SQL or No-SQL), as well as concurrency or parallelism expecting the question could move to "and what if there was 1000x more data?". "Process stock market data" needs more than "read a temperature every minute".
Or at least for a candidate to ask about some of them and be told "this isn't so complicated", not "it's up to you". If it's only asking whether you can loop over a generator instead of trying to read all the data up front, the question could surely be more focused?
I still answered the question in my head on a whim, half-expecting it to be false, it's a really vague formulation. Sounds like the interviewer was randomly browsing language features and cutting and pasting random descriptions from whatever tutorial. Or maybe the company was using python generators in a really specific "data pulling" niche that the answer seemed extremely obvious to the technical team writing the questions and they forgot that outsiders are not wired to think of the same patterns.
Wrong answer.
The heap data structure would be a right way to go about representing such data.
>>If you don't know this, then both people are going to wish that they had that half hour of their life back.
Same in your case now.
that describes 2/3rds of the 'codility' tests I've been given in a few scenarios (toptal used it to weed me out). The couple of jobs I've been in where I was explicitly barred from ever asking any clarifying questions, or talking to business/SME folks about the problem at hand... I left those pretty quickly. I guess it serves to weed out people who have some hard-wired dependency on talking to people to clarify requirements.
I've found that the ability to receive and act on guidance with a certain degree of humility is a much better signal of someone's potential than how many algorithms they've memorised.
It takes a lot of practice to know what level of assistance to provide at what time. A coworker once showed me a technique of keeping a google doc with the problems, as well as a step-by-step of the solution and the times at which they should be at that step. It always seemed to work out well for the candidates, as even a poor candidate would finish the problem at like 55 minutes into a 60 min interview.
Even with that, getting a person to see what they should be doing next, without telling them explicitly, is definitely a skill you develop with practice. I think you're right in erring on the side of too much assistance. You get to see much more of how the candidate works if you can skip over the part where they are getting stuck on something.
Actually being able to take a hint and work with the interviewer is a strong signal that a candidate, while maybe not the best for the job, has growth potential.
(I am hesitant to describe my idea, but WTH, I'm currently not in a position to act on it, and they say ideas are dime a dozen so...):
For those of you for whom English is not your first language, you surely know what TOEFL is: Test of English as a Foreign Language. The private company provides a test where they evaluate a person for proficiency on different sets of English skills: Reading, Writing, Speaking, general comprehension. At the end of the test they give you a score for each of those and then a general score.
Now, the nice thing about the TOEFL score is its reputation: When you are going to study into a University (from Oxford to Liverpool, from Harvard to Queensland), if you are not a native English speaker, the university asks you to take a TOEFL (or equivalent) and get a score higher than X. As long as you provide that score, the university won't ask any questions. They don't doubt your English proficiency skills.
I want to do something like that but for development: Sure, University thought you CS101, CS201, etc. But what companies are looking for are specific skills (similar to say, https://sijinjoseph.netlify.app/programmer-competency-matrix... or https://docs.google.com/spreadsheets/d/131XZCEb8LoXqy79WWrhC... ). These very concrete skills that can be concretely measured.
I want this becase I've been dealing with recruiting, interviewing and also being interviewed for most of my career. And in my experience setting up a "recruiting wheel" in a company or startup is very painful. Most developers don't know how to perform interviews. Or don't care (who has time for that?). As an Engineer manager, having to comb through 400 resumes a week is time consuming and unproductive.
So I imagine a scenario where, there is this proverbial "Full Stack Developer" certification authority which is independent, very reputable and unbiased: They won't tell me if X or Y developer will make it into my team. They will tell me how does the person score in "Algorithms/Data Structures" or "Micro Services development" or "Frontend development" and then I will choose whether I want to hire them or not (according to my current requirements). That way, I only have to do a culture-fit interview and that's it.
In the past I have dealt with "Sourcing Agencies" that try to do something like that: They do the 1st technical interview, and they say that there will be alignment to what I want. But that was not the case: They send me 2 candidates and get very surprised when I reject one and not the other. And I feel our objectives are not aligned, so everybody is frustrated. Moreover, I don't want to have to deal with hiring agencies. And paying 1 to 3 salary months is too fucking expensive.
Now, as a candidate/developer: I would love to have a "TOEFL" like certificate that I can show, with my proficiency. That way, I can "look for a job" passively. I don't have to be making countless of code interviews showing one time after another what I know. I only do it ONCE for an authoritative company, and everybody else can check my qualifications there.
Companies like Microsoft or TripleByte have tried to do something like that, but the problem is again that they do other things: Their interests clash. Why would I trust LinkedIn? That's why TOEFL monetization make sense: The candidate has to pay for it.
I am aware there are some certifications: Oracle whatever, Microsoft whatever, AWS whatever. But those are either too specific/nic...
That is a big ask. There have been many attempts at CS-adjacent certifications, some of them government sponsored, but none of them find widespread use. The ones I've personally encountered were grossly out of date (e.g. a C++ assessment that didn't mention templates at all, in 2012), and weren't even mentioned during interviews by the company that demanded them.
It's not just a matter of trust, either. Our industry is incredibly conceptually diverse, despite the common current of abstract patterns that underlies everything. There is no specific or generic skill test that won't be out of date in a year, and forcing the required degree of standardization on our industry to make that possible would effectively destroy it.
In the mean time, the only organizations incentivized to keep their assessments up to date are the vendors themselves, who as you note, have conflicting interests. And at root, if you want to be even slightly more generic than a vendor certification, you are basically trying to test for intelligence and adaptability.
They should. My university had a minimum TOEFL score requirement. The number of grad students who passed that requirement, but then couldn't write a coherent English sentence to save their lives was still incredibly high.
Already exists. https://news.ycombinator.com/item?id=27662804 Don't you have apprenticeships in your country?
First, there are wrong incentives at play, good guys currently don't need that as they mostly are employed and look for jobs passively. Good guys don't care about certificates and you want to certify good guys so your certificates mean something and can build trust. Weak guys will be spending money to cheat their way around just to get passing grade, which will cost money to prevent.
Then you have hiring managers that will not use this exam as good enough just to hire a person unless there is big company that would do the same. So you have chicken and egg problem, because no one will trust your certification and to get the trust someone would have to use it.
My idea is that you cannot effectively hire at scale. I could hand pick maybe 5 devs/year for my company, getting to real numbers in my small company I can see that we can hire maybe 2 developers per year. When We hire someone it worked for me with simple questions and attitude check. I don't see a way to hire 100 good developers in 1 year, that is not possible. Maybe at a scale you can hire 10-20 good developers a year but you have to have 3-5 people involved full time - and ideally those 3-5 people should be nice and technical - where in the end you don't want to use them only for hiring because those are probably your best developers with soft skills.
For that competency matrix - that is something you can do when you have developers inside of the company and you can observe them for at least 6 months. Good luck getting that in practical testing setup for 2 or less hours. I also find those kind of matrices terrible and not useful for evaluating people or projects. I work on a project where we were not fitting in anything of what was in the matrix .. yet we were delivering good quality for business all the time, while teams that were stuck on their "competency matrix" trying to improve meaningless points ended up disbanded and not working anymore in the organization.
One interesting thing about TOEFL is that it is, arguably, correct and complete. I.e when using the English language you use 100% of the skills the test measures, and the test measures all skills necessary to thrive in English. That's why you only need do it only once (every X years).
Engineering skills as defined by those matrices are so much more open ended that you'd need specific matrices tailored for different positions. E.g. a front end developer doesn't need to know what a linked list is. Then you end up moving away from the idea of ONE authoritative test.
Also worth noting that wherever I've seen it used, TOEFL is usually a mere checkbox to tick, and there are other, more thorough measures of skill involved.
if your an app dev: make me an app that does x, you have 60 min
if your a rails dev: make me a site that does y, you have 2hrs
if your a pdm: make me a spec and tickets for a system that does z
maybe i'm missing something but it shouldn't be too hard should it?
For example; "Make me a site that does x, you have 2 hours" Do I need to build the app in front of you? Problematic because how often does one build an entire web site in a couple of hours, while someone is standing over their shoulders scrutinizing every keystroke?
Do I take it home and do it? If so, how do I prove to you that I did the work?
Do you care what framework I use? Do you care if I use Open Source code?
What design should I use? Where do I get the site assets from?
If I'm building this site for you, are you paying me for that time?
Then there's the non-technical parts missing from an interview like that:
How does such an exercise tell you that I'm the kind of person you want to work with?
How does such an interview provide me an opportunity to ask you question? It tells me nothing about you or your company which is every bit as important as you finding out about me.
Won't happen, because most don't want to figure out a better way. We just have to come to terms with it.
https://alexgolec.dev/reddit-interview-problems-the-game-of-...
I'm interviewing you too, so give me something that reflects the problems you solve as a team, otherwise my assumption is your office is full of white boards containing puzzles of the day and your tech is all 3rd party libs.
It may also be that anything work-related is actually too long to fit into a limited interview time.
Now, a trivial, brain-teaser, question would be "you have an NxM matrix, and you can either go left or up. How many paths are there from the lower left, to the upper-right corner?"
I consider it a brain-teaser because if you write code that contains any matrix manipulation or searching, you have basically failed. There is a closed-form expression for the number, so...
[1] By "non-trivial", I basically mean that there are multiple correct solutions.
The way I would apply that problem interviewing someone is: We have 1 hour. Here is this problem (to which of course I know the solution to already).
How would you solve it? Let's solve it together so that I can see your decisions, your code, do you use exceptions? do you use specific type of exception for different errors? do you split functionality in a lot of functions? do you know nifty language tricks (maybe a bit of code golfing or functional constructs if JavaScript or Ruby).
The problem comes when the "interview problem" is passed from the creator to the "mid-level" Engineer who now has to do the interview. For them it becomes: "Ok, you gotta implement this in one hour", and they don't know the nuances or reasons for the problem.
I've seen this first hand with an equivalent problem. I had all this nice interview process that I applied, and the first time I shadowed one developer so that he could do the interview, he was just looking at the poor interviewee fail due to nerves, with the aim to evaluate him only on the merits of how far a set of working code did he had.
It was quite weird.
As an interviewer your two objectives are:
1. Ensure the candidate has an excellent experience
2. Collect data points
In that order. Sometimes we run into candidates who make the second item difficult. They fail to complete the specific technical problem. They can't speak about their experiences in detail. We need to drag data out of them screaming. It doesn't matter, your priority is to ensure they feel respected, and leave thinking they WANT to work there.
Do you want a pat on the back or something?
I thought I nailed their code challenge and expected to continue through the process, but after that session that was pretty much the last I heard from them. It was pretty disappointing.
It's too bad your experience was so negative. That's going to be a datapoint in my mental dataset of companies to consider when the time comes.
And from a completely non-technical persons perspective Reddit is incredibly disorganized at the executive management and corporate level. The amount of turnover, controversy, business model revamps, etc. for a 16 year old company with the hype they have is unique and unprecedented. It's not surprising whatsoever that their hiring practices are similarly disjointed.
I come in. The front-end guy starts asking me questions to try and solve something he is working on. No-one else is there yet. He is asking me about why a JS compiler is removing his comments, I say I don't know, I have never had that issue before...I make an off-hand comment that I use React and most of my JS code doesn't have comments because I am just working on projects by myself, and I don't do a lot of library code...the manager comes in at this point, and proceeds to berate me about why commenting is essential. I say: I use comments where they are needed. Off he goes, again.
Interview starts. Manager proceeds to go through a series of questions designed to expose my ignorance. None of which are related to the job. One classic was him explaining to me that database normalization made no difference to the size of the database because "the data is all the same on the disk" (which is, ofc, not accurate...I tried to explain, he just kept repeating that over and over...he actually said as I was leaving "make sure you understand databases for your next interview" with a massive shit-eating grin). For some reason, there was also a back-end guy there who, upon hearing that I built something in Java, proceeded to launch into a series of questions on internals of Java (for example, he asked me what the difference was between certain versions of Java and the size of the heap...perhaps unsurprisingly, he also got some of this stuff wrong but began laughing when I said I thought X was Y).
The only two questions that I had about front-end dev were: the front-end guy trying to ask me to help solve an issue he was having (before the interview, when no-one was there), and a question about the value of this in arrow functions (which I got wrong, but is also an excruciating thing to try and explain, so I don't think the guy knew whether I got it wrong...it is a terrible question). That was it.
Huh ? language parsers remove comments because they're comments, that's literally by definition. Are you (or your past interviewer) using "comments" in a different sense ?
(Also, not trying to be a pedant on you I swear, but technically JS is traditionally interpreted. Most mature runtimes have compilers but it's not part of the API. It's just a juvenile pet peeve of mine when language implementations are generically referred to as compilers.)
>he actually said as I was leaving "make sure you understand databases for your next interview" with a massive shit-eating grin
I sincerely hope from my heart of hearts that company or department is in it's well deserved position in the depths of the toilet now, or at any rate that specific person.
Actually can't find him at the company anymore. But the company isn't doing too well (although they seem to have moved into a nicer office). Revenue down 50% last year (from a small number to an even smaller number), costs up 60%, losing substantially more money than they have revenue, the operations guy who did my interview isn't there anymore either...true "tech company things". I didn't the impression that the company was that bad, they were more "much steam, no fire".
I'm really sorry to hear this, that sounds incredibly stressful. The worst part about stress in technical interviews is that even under good interviewing conditions (which you clearly didn't have) it can really hobble a candidate to be stressed.
I hope this experience (or this HN post) doesn't scare you away from programming or interviewing at software companies in general. Those guys sound like jerks. There are good companies and decent coding interview routines out there.
I've ran into "OMG he didn't know that!" responses when one dev disapproves of a candidate. Inevitably I ask "Really how often do you need to know that? and if you needed to wouldn't you just google it and be done?" but we assume it means so much more and there you go.
Then someone else gets hired and they knew the trivia, but can't apply it or worse only really knew the answer and not the ramifications... or they just can't wrap their mind around / don't care to think of second order effects or whatever.
Credentialing organizations already exist[1], but none have lobbied the US government to prevent the uncredentialed from practicing.
Perhaps it's time. If none of the existing orgs are good enough, start a new one.
1. https://www.computer.org/product/education/professional-soft...
Many devs are not good at their jobs. They mean well, but they can't solve basic problems without looking at stack overflow. And by "basic", I don't mean leetcode, I mean iterating over a collection.
> Anyone can trivially study and pass
Yes! At that point, I would know that the guy sitting next to me did at least some amount of studying of the fundamentals.
I doubt hospitals interviewing senior doctors need to ask them basic anatomy questions, or law firms needing to ask candidates the difference between tort and criminal law. Tech could benefit from this minimal minimal bar.
One wonders what the history of how the credentials in medicine or law were forged.
Sure, but what credential exists that both is reliable enough to support that use and would remain reliable enough once it became used that way, even in a specific narrow subfield of development?
https://www.nspe.org/resources/pe-magazine/may-2018/ncees-en...
I looked at it briefly but realized that I would need to study a significant amount of engineering aspects (how much water can flow through this pipe type engineering) to be able to pass the first exam.
For people who are developers, while the ethics, principals, rigor and similar type aspects of the PE exam process are useful, that it is still focused on being a PE first and a PE with an Software specialization second means that most people who are software developers would not be able to pass it or find use in the additional engineering principals that it provides (you wouldn't want me to sign off of a building design... well, maybe if I studied enough to pass the FE exam first...)
So, first I'd have to take the FE Electrical and computer exam... https://ncees.org/wp-content/uploads/FE-Electrical-and-Compu... or go with the other disciplines exam - https://ncees.org/wp-content/uploads/FE-Other-Disciplines-CB...
Either way, there's a lot of material there that I don't know and I don't imagine most CS new grads would have a clue on.
And that's just the FE exam. After four years of under a PE, then the PE exam - https://ncees.org/wp-content/uploads/2015/07/SWE-Apr-2013.pd...
It's just not worth it.
They even do this crap to people with CS degrees. If a 4 year CS degree isn't enough, then people who do this have no idea what they are doing.
I started in this field in 1997. The interviews were more old fashioned, a few tech questions, see if you were an oddball, then they'd get back to you. If you didn't work out, they would just fire you. Pretty simple.
If it's not enough for an employer, it's because that employer devalues what's taught in most CS programs. Granted, there's a significant mismatch between CS degree work and real world work, but that's true in lots of engineering. Ask any engineer in whatever subfield how much time they spend solving differential equations. I mean, great that I learned how to balance a binary tree and write a heapsort in my DS&A class, but have I ever needed to do that at work? Other than to pass some stupid coding interview?
Not all CS degrees are created equal I'm afraid.
I’ve interviewed many people with 4 year CS degrees who can’t really code. I’m not sure how this happens, but it definitely does. I disagree that having a CS degree should excuse candidates from coding interviews.
Becoming a specialized divorce lawyer still requires you to pass certification on things like criminal law and constitutional law (among many other things), you won't be permitted to practice law if you know just your specialty, no matter how well you know it.
Becoming a heart surgeon still requires you to pass certification on pharmacology and gynecology (among many other things), you won't be permitted to practice medicine if you just know your specialty, no matter how well you know it.
But for software workers we do accept that you can ignore many related (and even relevant) fields and just learn only one niche of technology - we could make an all-encompassing bar, but it would be a major change and I'm not sure if we would want that.
My focus is security, and so the second time around I got Travis Ormandy as an interviewer. I was able to impress him well enough with my IPSec foo to make it onsite. Then I got asked a question I had already been asked in another interview with another company, and I was able to knock that out of the ballpark (I mentioned I already knew that question, but the interviewer wanted me to answer it anyway). Then I got asked a question that used recursion, and because I took a graduate course on induction and recursion within the past year, that was effortless for me. Then I got asked a question that involved a kernel feature, and because I happened to recall the Linux kernel list macros and semantics (something I couldn’t repeat now over 10 years later), I really impressed that interviewer.
I ended up having a really successful part of my career at Google, even though I ended up not really writing much code when all was said and done. However what code I did write was highly impactful.
Looking back, things could have gone very differently if I had gotten a different set of interviewers and/or questions. The questions I got just happened to coincide with what was “paged in” to my “working memory,” so to speak.
I've never even heard of a Bloom filter, so I know how I would have done.
I had an technical interview with a company early last week, we did a shared session using VS Code. The interviewer wrote the function signature, and I filled out the implementation. I did great, according to the interviewer, and moved to the next set of interviews.
The next interviewer, which turned out was also technical, ended up opening up a shared Google Docs to write code it. I asked if I could just share my screen in my own editor, but they couldn’t give me permissions to do that. I was given an extremely vague question. When I asked questions, he told me to stop because he was holding out for next iterations of my implementation (again, in a Google Docs). Given no structure and an absurd environment, I completely bombed it. And to top it off, instead of getting an email saying they were not interested in me, they just ghosted me all together. A complete waste of time. I wish them luck in their endeavor to find the best engineer to write code in Google Docs, since that is apparently what they are interviewing for.
it was like sitting in a confusing nightmare for an hour
either way I ended up getting a cooler job somewhere else so maybe it was a good thing in the end
Frankly the most annoying interviewer I ever encountered. Served as a low water mark and inspiration for me to be as helpful, thoughtful, and kind as I could be in the next 100 phone screens/interviews I conducted for my employees.
FWIW, I've been to many a Google campus and know many employees there, so I think this was an outlier.
I really dislike when companies do this. It's very time consuming and psychologically/emotionally draining.
I mean, we have things like the SWEBOK (https://www.computer.org/education/bodies-of-knowledge/softw...) that could be used to build a set of interview questions and acceptable responses, but does anyone use it for that?
The best interviews I've had, either as the interviewer or the candidate, have been when there was a discussion and a free flow of information in both directions. Unfortunately, it seems that in a lot of places, this degrades quickly into a hazing ritual.
I haven't participated in technical interviews in a long time, but when I was asked to do it, I made it a point to throw as many lifelines as I could until I got a satisfying answer. For instance, if want to know if the person understands generics and they can't answer the question outright then I'll ask them about C++ templates. Similarly, if someone can't describe the term "idempotence" I'll ask them "can you tell me what makes a function pure".
Mind you those terms aren't interchangeable but if you catch one it should be trivial to understand the latter.
He asked five or six questions related to C and C++ undefined behaviour, a very open-ended one about a technology I'd never used. I answered as best I can, but always opened with "I'd be referring back to the C standard and opening a JIRA task to fix the code". We got on to how I'd fix the code -- remove the UB, but only if there's a unit test covering it. What if there are no unit tests? What if there's no JIRA? Lots of what-if-maybes.
A few days later I was on a 3-way call with the recruiter and one of the guys that interviewed me. They spent the whole thing telling me how "any decent developer" should have known what the UB would result in, shouldn't have to refer to standards or books... and on and on. But as a courtesy, they'd be happy to make an offer.
Half the minimum posted salary, no benefits. It was right in the middle of the minimum wage and the "living wage" lines.
I declined politely, and the recruiter hung on the call...
"Wow. I don't know what to say. That's never happened before... do you mind if I share the recording of that call with my manager?"
They were still advertising to fill several positions when I last stumbled across them on Glassdoor a few months ago...
Someday soon we may accept that what gets classified as software engineering is actually an amalgamation of skills from an entirely different set of titles/careers, most of which treat software creation and management as a tool and means to an end.
I don't generally consider a blacksmith and a welder to be the same occupations. You can lump them under metalworker, but would you really expect the interview process for these roles to be at all similar?
In other words, there flipside of what you said is that sometimes you'll excel and be offered the job on very attractive terms.
Or, why did the screen just scroll down and lose my place in the paragraph? Oh, they loaded an ad in the middle of the document and the page re-rendered itself causing jerks and fits on the screen. Nice job FAANG site!
Or try performing a sort of items by price or whatever other criteria … doesn’t work because the website wants the user to see the “suggested” items no matter what search criteria was desired y the user.
And …
Keeping aside the universal bar, even a firm/interviewer who interviews you will refuse to define a bar( and it's not too difficult to define one) or define a bar that is vague. Defining a bar will means that now they will have to come up with a really good reason to turn down a candidate. IMO they might as well as be honest and do the "culture" fit interview first and as an icing on the cake ask some simple technical questions, once they have settled for a candidate.
It's profession is filled will low status, low self esteem, insecure males, who bolster their ego by making the interview experience for the potential candidate as tough as possible. Not surprisingly the 'victims' (candidates) are also often the "victimizes" (interviewers).
This manifests inflated job vacancies because so many firms have an evergreen job posting for "Senior Full Stack". Because talent is scarce these roles rarely get filled (hiring managers expect million-dollar candidates to accept $100-200k compensation).
Also, because lots of software requires specific expertise, there are vacancies that can't be filled because of a knowledge gap (novel industries / projects, etc). For example, how could SpaceX possibly fill all their engineering roles? Surely money is not a limiting factor, but rather the limited supply of qualified expert rocket engineers?
I've seen all of those things happen at a single company before (and relatively quickly, over two years), and several of those things happen at several companies.
Oh and it's not that easy to even find a "trainable" junior. Even if you have a fairly strict hiring process, at least 1/3rds of the people coming out of the edication system will be draft busts if using sports terms
And because it doesn't take a full two years before that junior is a valuable contributing member of the team; because they'll likely refer other qualified and/or educable applicants; because they might not jump ship, but be happy to get promoted if you actually reward them comparatively to what another company would pay them.
But sure, if you're not willing to invest either time or money in your employees, then no, you shouldn't hire juniors.
A junior dev hire involves sifting through many resumes, and then interviews, onboarding, and then three to six months of lower productivity for the mentor.
All of that represents losses against the current status quo. The current status quo is predictable.
This completely discounts the "accept and renege" that also is common with juniors looking for a job which can reset the job search back to square one even when you do find a good candidate.
Taking six months or a year to hire a senior has fewer resumes to sort and fewer interviews to conduct. When the person is hired, they've got a much shorter onboarding and has the necessary skills to be able to become familiar with the codebase without causing a hit to the productivity of the rest of the team (or other seniors).
In this situation, hiring a senior is likely a much better outcome with fewer seen and unforeseen negatives and an eventual positive.
yes - assuming the senior also doesn't leave.
Additionally, even if it is the case that they leave in a year or two, the org has likely spent less time on going through resumes (fewer resumes applying) and overall interviewing (individual interview may be longer, but again - fewer overall being done) and less time on onboarding.
You're likely able to have productive contributions from a senior in 3 months rather than 6-12 months for a junior.
So even if the senior does leave in a year or two - the org is still better off trying to hire a senior than a junior.
---
It really boils down to "if you can't compete with big tech salaries, there likely isn't a way to hire a junior dev that will be a net positive to the organization.
Junior salaries are low because they're a huge gamble. If after two years you know they're a decent engineer that has learned a lot, then you need to pay them like it.
It's something I see a lot of. Your "junior" that has been there for 2 years should be getting the salary you'd be paying a new hire that has 2 years experience. If they've been there for 3 years, and you've only been giving them 3-7% raises every year, you deserve to lose that engineer for someone that will pay them 50+% more.
Thats because most roles aren't the core of the business. Most are supporting the core. You don't need to be a flight engineer to build the system that tracks parts during manufacturing. You don't need to know how swaps work to build an order management system for traders. You don't need to know how to do surgery to build a scheduling system for the surgeons.
I currently work for an agtech company, the domain-specific stuff is just context for the generic numbers and equations, or a reason to choose one over the other, to the extent that I need it it suffices to have a colleague who's a domain (but not software) expert.
You might say that's the other extreme, aerospace is different, but I don't really see that it is. I don't think anybody's claiming SpaceX doesn't have or need aerospace engineers, but once they've, idk, specified a formula for a parabola representing a flight path say (yes, I don't know what I'm talking about!) then the domain doesn't (needn't) matter to the software engineer implementing it.
Basically nobody in any of those places had any domain knowledge outside that which was learnt during the act of developing and, in some rare cases, some "familiarization" courses during a day or so.
Is this a euphemism for an employer overworking and underpaying their talent?
i.e., did it seem like a lot "for an intern"? Did it seem like a lot when you take into account what was expected of them? I mean, if interns get hired to jobs that seniors (for the sake of argument) should be doing, and the interns are getting sub-senior pay, then they are underpaid.
Their intern pay was also in line with this. I got paid a little bit less as an intern at NASA, but much more as an intern at a non-aerospace (also non-FAANG) tech company.
how are senior engineers supposed to be created if very few companies are willing to train junior engineers? Why aren't these companies offering paid apprenticeships if they are so desperate for workers?
As a plumber, you pay your apprentice usually 60% sr/journyman salary with a 5% increase every 6 months to match the value of the skill up.
There are also industry standard, industry funded classroom settings, that teach things like building codes and industry standards and some adjacent trade craft.
Instead you just throw a Jr to an overworked mid/Sr and they can help with some design and questions and code review but that takes 10-20 hours per week so you have to pretty much have one or more per Jr. Position. Then, after 18 months when the Jr hasn't received a 15% pay raise to reflect the enormous amount of time an knowledge you've sucked out of a Sr position, they go elsewhere for a 20% raise and it looks like you've waisted your time.
In truth, it wastes the talent you've built to not be aggressively increasing their comp to match the skill increase you're providing.
Having a base of expected/certified knowledge would take a lot of that away.
I'm not really sure how you test for a base level of that, besides proven demonstration on your resume and doing semi-correlated coding quizzes.
This is why we don't have a base of expected knowledge in the field and why we do strange coding tests to try to guess if someone is competent.
The issue is that we don't quantify what hiring someone actually costs. We're willing to spend $20k on finding a candidate for 160k yet the people in the same position are sitting at 120k and getting a 3-4% raise.
The new person needs time so expect at least a month of training, yet no one quantifies that as well.
I'm fine with an annual cost of living adjustment once I get to a SR level because I'm not increasing skill at a rapid pace, I'm exercising my skill in the expected way. For a Jr path, that doesn't make sense. getting a cost of living adjustment and being twice as good as you were last year means you're a flight risk and that will cost the company more than just paying people what they are worth.
But industry standard groups, unions, people who have a vested interest in having a supply of quality labor so they can do business. Some of the classes are sponsored (especially in smaller places where there's not enough support) and in return, they get to train you on a specific product or just hang a banner and give you a 10% tools coupon.
Wait, not even that.
Even if you are senior you can get that job (because, for example, you are from another country and suddenly you are "cheap" even if senior).
That's a red flag. Because we all know the top of the market, no matter where, is working at SV rates.
The reason they jump ship is because the firm refuses to re-evaluate them for what they are worth, and keeps them on work meant to free up the company's existing senior staff (i.e., dead-end grunt-work that results in burnout). If you, as a junior developer, want to be re-valued, you need to jump ship.
This creates a feedback loop. Companies view juniors as a cheaper developer you _might_ get 2 years of low-cost work out of (after training) before they'll leave, creating a self fulfilling prophecy.
I've watched (and experienced) this loop multiple times. It's utterly baffling how firms would rather go through the cost and drain of finding and replacing talent rather than re-evaluate and pay their existing, proven talent what they are worth on the open market.
Workers would rather not move around. Workers would rather have a stable position in a job they like, in a community where they can purchase a home and build lives and/or families. Once you get past 35, playing the required musical-chairs needed to advance your career is a real drag. It does not need to be this way.
I really disagree. These junior engineers you're talking about are mostly in their early 20's (even if they're older and switching from a different career track, they're by definition new to the industry and still have a lot to learn). In my experience, they definitely do want to move around. And even if there is a great track for internal promotions and the compensation is going to be the same whether they stay or leave, it honestly is usually in their best interest to move around every couple of years anyway early in their career. They'll meet more new people to grow their professional network faster, work on new problems, see different ways of how teams operate and what works better/worse, and gain more experience faster.
I do think that for the very top performers, most companies should probably be much more aggressive than they are. If someone is really crushing it, like in say the top 1-5% of performers, be ridiculously proactive and promote them from junior engineer to Staff Engineer within 18 months or something. I've seen a couple of people over my career that actually were performing at that level, and no external company is going to give them that big of a boost, so it's a good chance to use your inside information to be more competitive. Otherwise, for the majority of folks that are learning/advancing at a more normal pace, I don't think there's really much a company can do to keep them longer. (Not that you shouldn't even try, it's still a continuum and if you do a really bad job at career growth internally you'll lose even more people faster. But you shouldn't expect to be able to keep most people beyond 2-3 years).
It's interesting that the worse the interview process, the less the Junior will want to go through it, the more the company benefits. You make your process painful so your competitors make their process painful so both of you hold onto your Juniors for more time.
If you can fix the externality problem this goes away, but that's not easy.
I do however, agree with your sentiment, those junior folks that are getting all the work done only get rewarded with more work to do.
Most of them still want to move on, usually to change technologies or gain more responsibility even faster.
Sometimes they want to move cities for almost random reasons, and they're willing to just find a new job and do it.
So while I somewhat agree that devs don't want to move jobs, juniors devs often do, and I think they're a lot more likely to move jobs than senior devs.
It's not that they don't want to hire juniors, it's that you need a solid ratio of mentors to mentees.
I've worked at a LOT of companies, and for the more well known one, the ratio of junior resumes to seniors was easily 1000:1.
We hired entire cohorts of juniors, often interviewing HUNDREDS of them in a couple of weeks, hiring dozens. That still meant that from all the resumes we got, only a few % made it through.
What choice did we have though? We can only train mentors so fast, and hiring them is hard and expensive. You can't ask someone with 5 years of experience to train 30 people at the same time.
People often underestimate just how many people are entering the field right now, vs how many were 10-20 years ago. Add in people who EXIT the field, as well as people who are poor fits to be mentors, and it gets really dicey.
Also why companies will hire someone with 3 years of experience into a senior position.
At some point I actually reminded the manager that I was a junior, which resulted in them acting shocked and saying something to the effect of "well, let's hope that's not the case", and was basically flat out told they have no time for a junior. This was the manager who interviewed me, read my resume, and recommended me for the position.
I was replaced by a university undergrad student on summer break when I quit. I don't think people realize how the problem here often isn't you. Organizations with deep dysfunction are more common that you'd like.
Happy ending though. Got a new position the week I quit, and all turned out well.
Juniors write a lot of code. Often significant amounts for a company's products and services. They're the ones who are implementing all the decisions that seniors spend their time making in all their meetings.
Most senior engineers I've seen have most of their days filled with meetings with very little actual coding time.
The seniors are valuable, making decisions, coming up with solutions, building frameworks etc, but it's the juniors who then take that and run with it and build everything on top of it.
So while some will still code, it's far less than what the junior engineers are creating.
Yes they require some more training, and clear direction, but they are the ones actually creating and executing the vision of the company informed by the seniors.
What companies really want, like others have said, are senior engineers who are willing to accept a junior salary.
> Most senior engineers I've seen have most of their days filled with meetings with very little actual coding time.
Is actually a symptom of the shortage of senior engineers. Big companies that can afford to hire as much talent as they want actually will let seniors write code all day (my company does) because they have the economies of scale that lets them afford doing so; no one else can.
At a lot of non-tech companies, the trick is to get hired as a consultant.
Or many firms want to hire senior-level talent at junior-level prices.
My salary is above $100k and I could probably find a job doing what I’m doing for $150k or higher. My next choice is do IT consulting or try to find a management position but I don’t want to be tied to a vendors platform. Plenty of people have made entire careers on the backs of vendors like Oracle and others but I don’t want to be a crusty old dev keeping things alive until I retire.
What the people who insist on giving these interviews don't realize is they are extremely hackable most of the time. The people who give them often aren't bothered to make up their own tests, so they go to the google and type "whiteboard interview questions for bla bla." I suggest you do the same and study up.
The process seems completely random and based more on pedigree than on anything else. If you have a signal like an Ivy League school, an older friend in the industry who can refer you, or a FANG on your resume those seem to be the only ways to be picked from the sea of resumes.
The best way to get an interview if you didn’t go to Stanford or MIT (I didn’t) and haven’t yet worked at a famous company is to get a referral.
Which requires somehow making a friend or connection with someone at the place you want to be.
What worked for me was that I had been studying Kubernetes and was probably the cheapest guy on the market with that skillset :)
The first part is the University Hiring recruiters determining whether out of the 1000+ resumes they have read you are likely to have the basic skills required to learn to be a FANG engineer. In this part they don’t actually care much about what you did at your internships or what technologies you’re interested in all they care about is whether you know how to code in a language, know how to manage time and be managed by a superior, and know how to learn to do your job independently. If you pass this, great now you’re off to the races that was the hardest part due to the volume.
Then there’s a second part in every FANG university pipeline where University Recruiting and different hiring managers bounce around your application to find an intern for their team. In this part your demonstrated interests, prior work, and skills are important you’re way more likely to get a deep learning internship if you have deep learning on your resume at this part.
I posit that most university hiring advice focuses on the second part whereas the first part is the most difficult to pass. Think about it is the person with 4 hackathon awards and 3 deep learning side projects more likely to grow into a FANG software engineer than someone who has 2 internships?
Do your side projects involve reporting your progress to your team? Writing design docs and getting feedback from your team? Thinking about maintaining the code base and providing documentation to your coworkers? Those software engineering skills are learned not taught and you learn them on the job even though to other software engineers we would value the candidate with hackathons and side projects more than the one with 2 internships in terms of ability to grow.
I’m probably going to write a blog post or something about this cause I feel quite strongly about this after my experience following everyone’s advice.
I had no open source contributions, no hack-a-thons, and no side projects with users. No experience or internships whatsoever, I had work experience in the service industry that I didn't put on my resume. GPA barely above a 3
All I had were side projects on github, listed prominently on my resume, that showcased skills. My side projects were all toy projects- things like a tiny Go API with a dockerfile and Kubernetes YAMLs, an arduino project that creates a CSV based on inputs from a GPS sensor, etc.
When my interviews went well, it was because I had demonstrable expertise in Kubernetes
Also since I’m writing advice, don’t ever stop applying to places. You might feel demoralized after everyone gets offers and you don’t have a single one in May, or in my case getting 149 oddly similar rejection emails from different companies, but I applied to a place in June and got an interview and offer a week later its never too late and in fact you might find a company/team who also thought it was too late to get an intern for the summer.
The top comment seemed to capture the problem best:
"What is in extremely high demand is programmers with 20 years of experience in a technology that has been around for 5, no older than 19 and working for 20k a year.
And that demand will be high, forever.
Pay more and you get more. Pay this and what you get is code monkeys that couldn't find a better employer"
Is there evidence that's it's hard for devs to get a job in general? E.g. The average hiring times for software devs (on popular platforms) in London was on the order of a couple of weeks.
I know from personal experience that junior devs from bootcamps were getting snapped up quickly - source, I worked for 3 years in the recruitment industry and also hired many devs in that time.
Doesn't seem to be a problem in general?
Is it far more difficult for a median skill software developer to find a job than the equivalent person seeking employment as an accountant, electrician, or plumber? I doubt it.
The persistently very low unemployment rate for software developers rather speaks volumes about how not difficult it is to find a job. The interview processes are obnoxious in the field? Sure, that's a reasonable claim and seems to widely be the case.
A decade ago my region of the country would produce maybe 50 fresh CS candidates a year, now it’s closer to 500 spread across multiple different educations. This may not sound like a lot, but in a region of 1 million people it’s actually quite a lot, and those are the technical CS/SE types not the myriad of soft IT/design/communication educations which produce a further couple of thousand each year. It’s like this because we (as in the employers) have been telling everyone we needed more and still need more for that same decade. But this is a half truth. We don’t actually need more people to become CS candidates, we need more trained plumbers who are proficient in X technology that we can use for 5-10 years until they leave us or we replace them with someone cheaper. And how do you get cheap labour? Well, one way is to make sure enough people are educated in what you need them to be, and while it may have been the case that the world needed more CS candidates a decade ago that is no longer the case, but it’ll take a while for young people to realise this.
Well that’s one part of it, the other part is how the educational organisations educate our young people by giving them the wrong kind of skills. I’m not exactly sure why they’ve abandoned teaching people actual computer science, but the part that the most students fail on and the part that shrinks year by year is now computers work. I can see how the fundamentals aren’t as necessary as they were in the 90ies when I got my degree, and I also remember how much some of us hated that stuff even back then. But it’s what’s required to fill the best paying jobs, like running the cobol systems for a bank. Cobol itself isn’t hard, a cobol system is hard because it came with nothing and was build in a time where everyone invented the wheel their own way. So what you need to become a good hire for such a system is all the basic CS knowledge that nobody no longer teaches so that you may understand and reverse engineer whatever all those cobol programmers did in the 50 years before you arrived.
It’ll be sort of interesting to see where it lands us though, but I’d frankly get into actual plumbing if I was young today because that’s bound to be a better career for most people who aren’t aces in either the technical or the financial/management side of CS.
A degree is not the same as “talent”. The degree doesn’t even mean you really “learned” the fundamentals, so much as you were able to regurgitate information and pass exams.
I’m a Principal at Amazon. One issue I see among CS graduates is a lack of understanding in very basic CS fundamentals. On paper, these candidates have CS bachelors degrees. On the other hand, they struggle to pick the right algorithmic approach when something is clearly a graph or tree traversal problem.
Even if you don’t “need” a degree you still get one because it would be a serious handicap if you didn’t and our educational system doesn’t cost the individual money. In fact we pay you $1300 a month for 6-7 years while you work on your higher education. I’m sure we could debate the system, but the result is that almost everyone in CS/SE get a degree of at least academy level once they finish the mandatory 10 years of school + 3 years of gymnasium granting them access to the higher educations, and as such the number of educated is a very strong indicator of how many new programmers are entering the field.
But this doesn’t mean these graduates are skilled? From your explanation, it sounds like there’s an incentive to get a degree - both cash payments from the government and an opportunity to avoid labor work.
> as such the number of educated is a very strong indicator of how many new programmers are entering the field.
But “educated” in this context means they passed. It doesn’t mean all or even half of these graduates understand the discipline sufficiently to be productive employees or even work at a FANG tier company.
I guess my point is - the market might be saturated with these graduates, at least on paper. But that’s not the same as the market being saturated with talented programmers, engineers, admins, or whatever the job title is.
http://pyxisinc.com/NNPP_Article.pdf
The bibliography is also something to track down and read if you're interested in the subject.
Maybe that's what we need here, something to gap the "I'm brand spanking new" and "I'm a senior" time period.
Oh, man, to have somebody to do all the stuff I don't feel like doing...
Firing sucks, but it’s hard to truly tease out quality during interviews. So most companies go for false negatives over false positives. Generally this means that of the 3-to-6 interviewers, all have to have strong positive opinions of the candidate for the hire to happen.
Because of this, as a candidate, it’s a bit of a number’s game. You can be a great candidate, but still not get hired on any individual interview, because companies heavily bias towards allowing lots of false negatives to avoid the odd false positive.
I'm not sure I agree here. I doubt most interviewers have actually given much thought to what they are actually trying to look for in a potential candidate. The widespread practice of over-focusing on algorithmic whiteboard questions is a symptom.
There's got to be better processes in assessing candidates' qualities beyond solving algorithmic puzzles (which perhaps is 5% of a software engineer's job at best).
It’s just really tough to figure out in 2-3 hours how someone is going to perform in a given role over the next few years. Interviewing is an inexact art, not an exact science, and it’s very much my experience that companies compensate for this by favouring false negatives (not hiring possibly strong candidates) over false positives (hiring weak candidates).
The hiring percent was below 0.5%. There are a lot of candidates, but most of them could not fulfill our core requirements a new team member must be able to accomplish. In our case it was TypeScript itself, unit tests, integration tests, working in a Linux environment. Salary requirements for the same position varied $1000 - $20000/mo. Because there is a lot of supply side (read: developers available), one can be picky.
More details and statistic here:
https://www.linkedin.com/pulse/hiring-remote-angular-nestjs-...
This is just how I look at it, but if I reply to a company about a position, I'd like to know about the position before you make me jump through hoops. The exercise itself is okay, and a brief test like this is much, much better than making a candidate fill out an assessment, but why would I invest that kind of time if I don't even know whether or not I want the job. Think about it from the candidate's perspective, some people in this thread note having done 10s/100s of interviews. Imagine how much time they would spend doing menial coding exercises before even getting to know about the actual position other than the JD.
Again, its probably just me, but last year I literally thanked companies for their time because I didn't know anything about the job and their company and they were already asking me to do take home assignments. Sorry but I have a life, and critically to anyone who's hiring; plenty of people reaching out to me not trying to make me jump through hoops. Maybe if you invited more than 24 people for the exercise or just spoke to some people first, you would've gotten a better pool of (potential) candidates.
I wrote another post for another position later which has more juicy details like country breakdown
https://www.linkedin.com/pulse/angular-typescript-frontend-n...
Somewhat related, In the interview, the first question I asked if the candidates had tried to sign up on the website and what they thought about it. It is not encouraging if a candidate had not tried to figure out the company product himself/herself at all.
The people hiring people SUCK at finding people and waste everyone's time in the process.
The amount of Java / JavaScript confusion that persists among the people who are involved in just finding people reeks of incompetence / and maybe worse.
Head hunting corps, even random company recruiters / HR seem more interested in bringing in mass volumes of names / resumes / warm bodies regardless of how qualified they are. Then they filter and I guess justify their work?
I think of it as the Hiring People Industrial Complex where it feels like the end goal is not actually having even the slightest chance of getting a job, rather the goal is to have a process, go through it, and that's it.
I get so much spam for jobs that aren't right for me, not even in the slightest. I'll even do calls with them and explain that it doesn't really fit, and they still want to move forward to some other inane level of the process, but I know I've got zero chance.
It just eats so much time.
There are exceptions, but they are rare, and they don't work for the big recruiting firms. They are just body pushers.
Never tried waterboarding, but my issue with white boarding is that it’s deeply subjective. With working code you at least can judge the correctness straight away with a real piece of runnable code. You can also observe how the candidate reasons around the problem and how they formulate and test hypotheses. With a white board you can observe the candi^Wvictim making a table test, a term I first heard in the 70s and last heard in the early 80s. It is just cruel.
And yes the recruitment process can be very tedious, illogical and sometimes even unfair.
On the other hand, there are leagues of junior engineers (or just self-taught people after bootcamps) applying for all these jobs, so the process is hard for both sides.