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.
We made the interview process very simple and traditional in our current organisation. 30 minute chat, judge whether the person can do the job or is a good fit, if yes then offer a year contract with 1-3 months of evaluation period. Changing a job is risky also from the candidate's perspective so if the person is pretending, the lies will catch up. Most of the scenario it has worked pretty well.
Sometimes, people who you think are not capable to do the job, often outperform expectations too. It is all about taking a risk on a person and giving them respect and a chance. We could have done leetcode, or pair programming session. It takes more energy and effort to do it from both sides and probability of finding a good candidate is more or less the same.
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?
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.
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.
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.
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.
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?
> 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.
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.
It's because in software engineering your work product is confidential/proprietary and work samples take a very long time to produce.
If you could review someone's code from their previous jobs, I think it would be quite easy to vet applicants. And it would be much easier to move from job to job.
Instead we have to simulate work samples through whiteboard coding, pair programming sessions, take home coding projects, coding knowledge tests, etc. We know that none of these methods are particularly good, so we err on the side of failing candidates when we are on the fence. They also take a long time to complete, so software engineers are reluctant to change jobs because they know how much of a pain it will be to go through interviews again.
It is much easier for product designers and product managers to pass interviews. You can see their work product.
At my company we're working on a way to create standardized coding projects that can't be faked so you can use them across job applications. If you are interested in this space, shoot me a message: robert at facet dot net.
> If you could review someone's code from their previous jobs, I think it would be quite easy to vet applicants.
I disagree, somewhat. In positions where I work with a medium or large team, any code of mine you reviewed would give you an idea of how the team leads want code to be written, not really how I as a candidate write code. I've often disagreed on design/architecture but was forced to go through with it because I really didn't feel like arguing and getting on the shitlist of a high-ranking engineer with influence in the company.
If you want an idea of how I would design something, it's probably best to have me write something specific to the job. I'm not talking a whiteboard red-black tree implementation, but something that is actually indicative of the work I'll be doing.
Instead we have to simulate work samples
through whiteboard coding, pair programming
sessions, take home coding projects, coding
knowledge tests, etc.
Very small sample size but we've had good results skipping coding exams entirely, and simply talking through some scenarios with candidates.
- give them a hypothetical problem ("the page is loading slowly") and role play how they'd troubleshoot it - do they understand how different bits of the stack fit together? have they ruled out network issues before digging into the code? etc.
- "tell us about a tricky technical challenge you solved"
- ask them what makes a for good code review on a pull request / what makes good code review culture in general
- ask them about things the team did well at their previous role(s) and things they'd improve, and how they'd improve upon them. (not looking for "correct" answers or opinions - but they should have some opinions)
- what are some technologies/frameworks/languages you'd like to learn next? again there's no "right" answer. but if they don't have any - red flag, right?
- etc
This of course presumes that some minimal screening has been done to make sure they're actually a software developer; an initial Fizzbuzz screen etc.
At each step of the way we discussed relevant technical bits in a natural and conversational way. For example if they mention that they "optimized" or "refactored" or "fixed" something at a previous job then naturally we ask them for the details and usually wind up swapping some stories as well.
If they passed this conversational interview, we usually extended an offer to them within 24 hours or less. Sometimes we waited longer and they got snatched up by another company.
Of course this sort of interview doesn't tell you about their work ethic and how reliable they are and so on. But, neither does a lengthy coding assignment-based process either. And the "conversational" method gives you a sense of how they'll fit in with the team.
Considering how quickly good candidates are snapped up, doing "fast" interviews like this can be a big advantage for your hiring efforts. If worst comes to worst, and they don't work out, you can part ways. It's not like either side is locked into the employment agreement. Depends on your specific locale a bit, of course -- and at my current employer we're helped by being a remote team, so it's not like we're asking folks to relocate or anything.
> It is much easier for product designers and product managers to pass interviews. You can see their work product.
You don't see any more work of a product manager than of an engineer. What you see is always the finished product, and you have no idea who contributed what parts. If the overall product that can be publicly experienced is good, then some engineers in that team seem to have been doing a good job. You won't easily know which ones - and you especially don't know whether a product manager on the team really a lot of influence on this or whether the products vision and execution was mostly driven by engineers.
And the second point:
> If you could review someone's code from their previous jobs, I think it would be quite easy to vet applicants. And it would be much easier to move from job to job.
Sometimes employers can - because candidates have open source code. But experience has shown that these datapoints are not used, and employers still fall back to the default process of assuming nothing and doing whiteboard/leetcode style interviews.
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"
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.
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?
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.
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.
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.
One aspect not mentioned: Tech really want to be a meritocracy. We don’t generally succeed, but we try. Engineers at least want to be unbiased, and the Bay Area cares about it culturally, generally speaking.
So we fight against increased barriers to entry like credentials (but that Stanford/MIT degree is still a golden ticket into the interview). We try to give as objective an interview as possible, meaning it’s explicitly technical, rather than just talking about past projects open endedly and going with the feeling you get about the candidate.
I’d bet if we collectively decided not to try to be a meritocracy, we could make tech interviewing a lot easier, but I wouldn’t like that. I came from a nontraditional background too. I only got in the door because whiteboard style interviews let me demonstrate what I knew despite my total lack of credentials.
We suck at being a meritocracy, but I’m glad we try to keep the barriers low and unbiased. I bet we’re better than most other fields that pay this much.
But just as with companies that attempt holocracy and having no hierarchy, de facto hierarchies just creep in. And so the data structures/algorithms interview is a de facto credential, except worse, because it needs to be re-taken at every single company, rather than however many times it takes to pass the credential exam.
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.
> 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 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.
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 was laid off during the recession and was "out of shape" in terms of algorithm and interview skills. There is a lot to know. The two previous interview cycles in my career were a completely different experience. I could probably leverage my personality more - in the pandemic it was just a zoom call.
Now I do regular practice problems so I'm always ready. I actually recommend this.
Everything about interviewing sucks. Being the interviewer sucks. Being the interviewee sucks. The politics of hiring sucks. I hate it on both sides.
The more I interview people the more empathy I have for good candidates who can't get hired. I've seen so many potentially good candidates passed over because someone in the hiring chain didn't find them good. Usually this has to do with "lacking experience with X technology."
This is incredibly frustrating because usually the person doing the rejecting didn't know X when they were hired, but they were paid to learn it by the company.
On the flip side, I've been forced to re-interview obviously poor candidates because a hiring manager liked that they had "experience with X technology." Even though I was pretty confident that they were lying. Usually this ends up being merely a waste time, as I've never changed my mind and usually bring along another interviewer who concurs.
I think the hiring process is 50% luck, and 50% having experience with the right tools. My new strategy, after working in the sausage factory, is to look at prospective jobs, find the tools they are looking for, and find a reason to use them in my current role. Read all of the documentation so you really sound like you know what you're talking about, then interview. I'm not sure if this works in the SV startup culture, but it does seem effective in my situation.
If you have a 90% chance of getting everyone you meet to like you, but any one of them has the power to veto your entire candidacy, then after 7 "rounds" you are not likely to get the job.
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.
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.
Most engineers need no more than half a dozen interviews to get couple of options to choose from.
Unfortunately, there is population that grossly overestimate their ability, don't prepare effectively at all and take as many interviews as they can thinking it is numbers game. Then blame "broken system".
It reminds me when I went for exam for driver's licence. There was a group of people complaining at the examiner and broken system after one person failed their 27th attempt due to some "silly" problem like almost running a pedestrian. I had fun noting they already all know each other and then I passed on the first try.
The people who complain the loudest are mostly ones like that. Clueless about what they are doing wrong, not willing to honestly retrospect and evaluate their situation, learn from mistakes.
This is their modus operandi. If you always try to find external cause of your problem where a lot of other people clearly succeed, there is a systemic problem with you that prevents you from effectively learning anything.
If this is you, I don't want to work with you. I want people who if they encounter same failure over and over again will eventually stop to think what they are doing wrong. Or who will not start by blaming compiler for their broken code (I had a coworker like that - total disaster).
The first step to solving a problem is admitting there is a problem.
The whiteboard problems we give are nothing out of ordinary. Unfortunately, they are also biggest filter as a lot of candidates who seem to know basics of Java can't write a simple function to specification. I understand some are due to stress even though I try as much as possible to relieve stress, give hints, etc. My boss once tried to listen to popular "advice" and get rid of whiteboard tasks. The next two hires were total loss and we had to fire them within 6 months. We are again giving whiteboard problems.
I think that a lot has to do with his #2 point: Software is BROAD.
I've changed jobs twice in the last 6 years and in none of the interviews was I asked any coding questions. There were sometimes broad questions about design and concepts "how would you handle situation X"), but no actual coding or whiteboarding. In fact, going back 15 years to the start of the previous job, I don't recall coding questions then either. They were more concerned about my general capabilities and knowledge of useful algorithms that I would use on the job than the actual code.
But then, I'm mainly an embedded systems developer. Sure, I do the odd webapp or desktop application or tool, but controlling hardware is where most of my time is spent. Maybe in this field there's less of a culture of "interview by whiteboard?" Or perhaps it's because I was applying to higher level team lead positions that were more concerned with architecture & design than the framework of the month?
Or is it mainly the web guys (admittedly the largest section of the pie) that are being asked the odd algorithm & whiteboard questions?
As of recently I started having really confusing opinions on the state of interviewing and our industry in general.
Since there is no gatekeeping (for better or for worse), you get a large pool of people with wild variety of skills, so these silly interviews are the laziest way to assess people as an alternative to having credentials such as that of a Civil Engineer, Doctor or other professions.
I don't know of any other industry where the interview is this silly, but studying for it for a few months top could get you a 6 figure salary (not everyone makes it, but the chances are quite high) if you know what you're doing/skilled enough.
I started to play the game as well and actually got a lot better at solving this type of problems than say few months ago. My confidence is high and I'm a lot less intimidated by this type of interviews, but so is my I-take-no-shit-ometer since even if I aced some of these interviews recently and the interviewer(s) was/were acting in ways I didn't appreciate, I can just say no. I mean, I can play your game, but I'm not gonna put up with your shit.
What is in demand is cheap labor that can churn out low-quality web applications, label them MVP, and use them to convince investors to pour in money to hire more cheap labor.
The biggest tell that this is true is hiring for a specific library/framework/platform.
If you wanted a software engineer, you wouldn't care what particular thing they have worked with most recently. Maybe you would care about the general category of work, but mostly you would care more about practical experience and past achievements/results.
This isn’t true at all. Maybe in some locations (Silicon Valley? I don’t know), but every job I’ve been on has needed top level programmers for critical applications that have real world value.
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.
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.
"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.
[+] [-] Nbox9|4 years ago|reply
[+] [-] debarshri|4 years ago|reply
Sometimes, people who you think are not capable to do the job, often outperform expectations too. It is all about taking a risk on a person and giving them respect and a chance. We could have done leetcode, or pair programming session. It takes more energy and effort to do it from both sides and probability of finding a good candidate is more or less the same.
[+] [-] DeBraid|4 years ago|reply
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?
[+] [-] NullInvictus|4 years ago|reply
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.
[+] [-] shados|4 years ago|reply
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.
[+] [-] dimitrios1|4 years ago|reply
[+] [-] colordrops|4 years ago|reply
[+] [-] ren_engineer|4 years ago|reply
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?
[+] [-] 908B64B197|4 years ago|reply
At a lot of non-tech companies, the trick is to get hired as a consultant.
[+] [-] bern4444|4 years ago|reply
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.
[+] [-] mamcx|4 years ago|reply
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).
[+] [-] ndesaulniers|4 years ago|reply
Or many firms want to hire senior-level talent at junior-level prices.
[+] [-] cratermoon|4 years ago|reply
Also why companies will hire someone with 3 years of experience into a senior position.
[+] [-] rsweeney21|4 years ago|reply
If you could review someone's code from their previous jobs, I think it would be quite easy to vet applicants. And it would be much easier to move from job to job.
Instead we have to simulate work samples through whiteboard coding, pair programming sessions, take home coding projects, coding knowledge tests, etc. We know that none of these methods are particularly good, so we err on the side of failing candidates when we are on the fence. They also take a long time to complete, so software engineers are reluctant to change jobs because they know how much of a pain it will be to go through interviews again.
It is much easier for product designers and product managers to pass interviews. You can see their work product.
At my company we're working on a way to create standardized coding projects that can't be faked so you can use them across job applications. If you are interested in this space, shoot me a message: robert at facet dot net.
[+] [-] roberthahn|4 years ago|reply
This helps us look for good signal around their communication skills, mentoring skills, empathy, reasoning skills and software development skills.
We used this review as a diagnostic - there are no wrong answers since we know they’re not aware of our style guide and conventions.
It worked for us. Maybe it could work for others.
[+] [-] mywittyname|4 years ago|reply
I disagree, somewhat. In positions where I work with a medium or large team, any code of mine you reviewed would give you an idea of how the team leads want code to be written, not really how I as a candidate write code. I've often disagreed on design/architecture but was forced to go through with it because I really didn't feel like arguing and getting on the shitlist of a high-ranking engineer with influence in the company.
If you want an idea of how I would design something, it's probably best to have me write something specific to the job. I'm not talking a whiteboard red-black tree implementation, but something that is actually indicative of the work I'll be doing.
[+] [-] JohnBooty|4 years ago|reply
- give them a hypothetical problem ("the page is loading slowly") and role play how they'd troubleshoot it - do they understand how different bits of the stack fit together? have they ruled out network issues before digging into the code? etc.
- "tell us about a tricky technical challenge you solved"
- ask them what makes a for good code review on a pull request / what makes good code review culture in general
- ask them about things the team did well at their previous role(s) and things they'd improve, and how they'd improve upon them. (not looking for "correct" answers or opinions - but they should have some opinions)
- what are some technologies/frameworks/languages you'd like to learn next? again there's no "right" answer. but if they don't have any - red flag, right?
- etc
This of course presumes that some minimal screening has been done to make sure they're actually a software developer; an initial Fizzbuzz screen etc.
At each step of the way we discussed relevant technical bits in a natural and conversational way. For example if they mention that they "optimized" or "refactored" or "fixed" something at a previous job then naturally we ask them for the details and usually wind up swapping some stories as well.
If they passed this conversational interview, we usually extended an offer to them within 24 hours or less. Sometimes we waited longer and they got snatched up by another company.
Of course this sort of interview doesn't tell you about their work ethic and how reliable they are and so on. But, neither does a lengthy coding assignment-based process either. And the "conversational" method gives you a sense of how they'll fit in with the team.
Considering how quickly good candidates are snapped up, doing "fast" interviews like this can be a big advantage for your hiring efforts. If worst comes to worst, and they don't work out, you can part ways. It's not like either side is locked into the employment agreement. Depends on your specific locale a bit, of course -- and at my current employer we're helped by being a remote team, so it's not like we're asking folks to relocate or anything.
[+] [-] UncleOxidant|4 years ago|reply
[+] [-] Matthias247|4 years ago|reply
> It is much easier for product designers and product managers to pass interviews. You can see their work product.
You don't see any more work of a product manager than of an engineer. What you see is always the finished product, and you have no idea who contributed what parts. If the overall product that can be publicly experienced is good, then some engineers in that team seem to have been doing a good job. You won't easily know which ones - and you especially don't know whether a product manager on the team really a lot of influence on this or whether the products vision and execution was mostly driven by engineers.
And the second point:
> If you could review someone's code from their previous jobs, I think it would be quite easy to vet applicants. And it would be much easier to move from job to job.
Sometimes employers can - because candidates have open source code. But experience has shown that these datapoints are not used, and employers still fall back to the default process of assuming nothing and doing whiteboard/leetcode style interviews.
[+] [-] WalterBright|4 years ago|reply
[+] [-] tomkat0789|4 years ago|reply
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"
[+] [-] gscott|4 years ago|reply
[+] [-] bob33212|4 years ago|reply
[+] [-] faizshah|4 years ago|reply
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.
[+] [-] gonehome|4 years ago|reply
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.
[+] [-] readams|4 years ago|reply
That said of course the modern coding interview is I think only very loosely correlated with quality.
[+] [-] foxfluff|4 years ago|reply
Of course, every business likes to pretend they're the top and can only hire top talent.
[+] [-] yashap|4 years ago|reply
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.
[+] [-] 6gvONxR4sf7o|4 years ago|reply
So we fight against increased barriers to entry like credentials (but that Stanford/MIT degree is still a golden ticket into the interview). We try to give as objective an interview as possible, meaning it’s explicitly technical, rather than just talking about past projects open endedly and going with the feeling you get about the candidate.
I’d bet if we collectively decided not to try to be a meritocracy, we could make tech interviewing a lot easier, but I wouldn’t like that. I came from a nontraditional background too. I only got in the door because whiteboard style interviews let me demonstrate what I knew despite my total lack of credentials.
We suck at being a meritocracy, but I’m glad we try to keep the barriers low and unbiased. I bet we’re better than most other fields that pay this much.
[+] [-] Apocryphon|4 years ago|reply
[+] [-] larrymyers|4 years ago|reply
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.
[+] [-] dntrkv|4 years ago|reply
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.
[+] [-] firebird84|4 years ago|reply
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.
[+] [-] moksly|4 years ago|reply
[+] [-] jstrH|4 years ago|reply
[deleted]
[+] [-] justinzollars|4 years ago|reply
Now I do regular practice problems so I'm always ready. I actually recommend this.
It looks something like this:
[+] [-] lifeplusplus|4 years ago|reply
[+] [-] mywittyname|4 years ago|reply
The more I interview people the more empathy I have for good candidates who can't get hired. I've seen so many potentially good candidates passed over because someone in the hiring chain didn't find them good. Usually this has to do with "lacking experience with X technology."
This is incredibly frustrating because usually the person doing the rejecting didn't know X when they were hired, but they were paid to learn it by the company.
On the flip side, I've been forced to re-interview obviously poor candidates because a hiring manager liked that they had "experience with X technology." Even though I was pretty confident that they were lying. Usually this ends up being merely a waste time, as I've never changed my mind and usually bring along another interviewer who concurs.
I think the hiring process is 50% luck, and 50% having experience with the right tools. My new strategy, after working in the sausage factory, is to look at prospective jobs, find the tools they are looking for, and find a reason to use them in my current role. Read all of the documentation so you really sound like you know what you're talking about, then interview. I'm not sure if this works in the SV startup culture, but it does seem effective in my situation.
[+] [-] ipnon|4 years ago|reply
If you have a 90% chance of getting everyone you meet to like you, but any one of them has the power to veto your entire candidacy, then after 7 "rounds" you are not likely to get the job.
[+] [-] duxup|4 years ago|reply
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.
[+] [-] Clubber|4 years ago|reply
There are exceptions, but they are rare, and they don't work for the big recruiting firms. They are just body pushers.
[+] [-] odiroot|4 years ago|reply
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.
[+] [-] lmilcin|4 years ago|reply
Most engineers need no more than half a dozen interviews to get couple of options to choose from.
Unfortunately, there is population that grossly overestimate their ability, don't prepare effectively at all and take as many interviews as they can thinking it is numbers game. Then blame "broken system".
It reminds me when I went for exam for driver's licence. There was a group of people complaining at the examiner and broken system after one person failed their 27th attempt due to some "silly" problem like almost running a pedestrian. I had fun noting they already all know each other and then I passed on the first try.
The people who complain the loudest are mostly ones like that. Clueless about what they are doing wrong, not willing to honestly retrospect and evaluate their situation, learn from mistakes.
This is their modus operandi. If you always try to find external cause of your problem where a lot of other people clearly succeed, there is a systemic problem with you that prevents you from effectively learning anything.
If this is you, I don't want to work with you. I want people who if they encounter same failure over and over again will eventually stop to think what they are doing wrong. Or who will not start by blaming compiler for their broken code (I had a coworker like that - total disaster).
The first step to solving a problem is admitting there is a problem.
The whiteboard problems we give are nothing out of ordinary. Unfortunately, they are also biggest filter as a lot of candidates who seem to know basics of Java can't write a simple function to specification. I understand some are due to stress even though I try as much as possible to relieve stress, give hints, etc. My boss once tried to listen to popular "advice" and get rid of whiteboard tasks. The next two hires were total loss and we had to fire them within 6 months. We are again giving whiteboard problems.
[+] [-] HeyLaughingBoy|4 years ago|reply
I've changed jobs twice in the last 6 years and in none of the interviews was I asked any coding questions. There were sometimes broad questions about design and concepts "how would you handle situation X"), but no actual coding or whiteboarding. In fact, going back 15 years to the start of the previous job, I don't recall coding questions then either. They were more concerned about my general capabilities and knowledge of useful algorithms that I would use on the job than the actual code.
But then, I'm mainly an embedded systems developer. Sure, I do the odd webapp or desktop application or tool, but controlling hardware is where most of my time is spent. Maybe in this field there's less of a culture of "interview by whiteboard?" Or perhaps it's because I was applying to higher level team lead positions that were more concerned with architecture & design than the framework of the month?
Or is it mainly the web guys (admittedly the largest section of the pie) that are being asked the odd algorithm & whiteboard questions?
[+] [-] wreath|4 years ago|reply
Since there is no gatekeeping (for better or for worse), you get a large pool of people with wild variety of skills, so these silly interviews are the laziest way to assess people as an alternative to having credentials such as that of a Civil Engineer, Doctor or other professions.
I don't know of any other industry where the interview is this silly, but studying for it for a few months top could get you a 6 figure salary (not everyone makes it, but the chances are quite high) if you know what you're doing/skilled enough.
I started to play the game as well and actually got a lot better at solving this type of problems than say few months ago. My confidence is high and I'm a lot less intimidated by this type of interviews, but so is my I-take-no-shit-ometer since even if I aced some of these interviews recently and the interviewer(s) was/were acting in ways I didn't appreciate, I can just say no. I mean, I can play your game, but I'm not gonna put up with your shit.
[+] [-] hsn915|4 years ago|reply
What is in demand is cheap labor that can churn out low-quality web applications, label them MVP, and use them to convince investors to pour in money to hire more cheap labor.
The biggest tell that this is true is hiring for a specific library/framework/platform.
If you wanted a software engineer, you wouldn't care what particular thing they have worked with most recently. Maybe you would care about the general category of work, but mostly you would care more about practical experience and past achievements/results.
[+] [-] bluedevil2k|4 years ago|reply
[+] [-] moksly|4 years ago|reply
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.
[+] [-] miohtama|4 years ago|reply
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-...
[+] [-] notapenny|4 years ago|reply
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.