If software engineering is in demand, why is it so hard to get a job?

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.

foxfluff• 5 years ago

I get the feeling that mediocre business should be able to run just fine on mediocre people. So it can't be that bad.

Of course, every business likes to pretend they're the top and can only hire top talent.

slickrick216• 5 years ago

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.

Jenk2• 5 years ago

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.

tluyben2• 5 years ago

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!

wayoutthere• 5 years ago

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.

ThrowawayR2• 5 years ago

"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.

AshamedCaptain• 5 years ago

Even worse is hiring someone merely mediocre and not actively harmful.

What's so bad about... mediocrity? For obvious statistical reasons, most companies, most jobs, and most people are mediocre (or worse).

wheels• 5 years ago

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.

Pelic4n• 5 years ago

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).

slumdev9• 5 years ago

What's so bad about... mediocrity?

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.

nitwit005• 5 years ago

What's so bad about... mediocrity?

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.

raxxorrax• 5 years ago

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.

MontyCarloHall• 5 years ago

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.

afpx• 5 years ago

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.

Clubber5• 5 years ago

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.

jgwil22• 5 years ago

Even worse is hiring someone merely mediocre and not actively harmful.

How is hiring a mediocre developer worse than hiring a charlatan?

ghaff9• 5 years ago

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.

Clubber5• 5 years ago

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.

https://worldpopulationreview.com/state-rankings/at-will-emp...

hcho• 5 years ago

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.

justaguy88• 5 years ago

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

shagie12• 5 years ago

(Montana isn't at will)

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).

slumdev9• 5 years ago

I've never seen this question posted by anyone who had either a CS degree or any nontrivial amount of experience.

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.

pdimitar6• 5 years ago

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.

slumdev9• 5 years ago

Well, where are you coming from?

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.

sumtechguy2• 5 years ago

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.

commandlinefan5• 5 years ago

anyone who had either a CS degree

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!

WrtCdEvrydy2• 5 years ago

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.

throwaway1492• 5 years ago

A recent comment from reddit:

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.

WJW2• 5 years ago

There's (at least) a third category:

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.

joelbluminator3• 5 years ago

You are underestimating the effort it takes to inherit a big codebase and maintain it, this is not a task for a junior.

nkingsy2• 5 years ago

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.

ghaff9• 5 years ago

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?

cableshaft2• 5 years ago

So you're suggesting new software engineers spend a full year with no pay before trying to get their first job? That's not feasible for most people.

mooreds• 5 years ago

This is a really useful perspective, thanks!

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).

supergeek1332• 5 years ago

The trades have apprenticeship programs... might be an interesting model to try to replicate.

shagie12• 5 years ago

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.

stripline• 5 years ago

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.

frant-hartm• 5 years ago

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.

habibur• 5 years ago

The best and most practical comment so far.

That's what my experience says, including the conclusion.

pdovy• 5 years ago

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.

larrymyers• 5 years ago

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.

firebird84• 5 years ago

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.

selfhoster11• 5 years ago

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.

dntrkv• 5 years ago

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.

moksly3• 5 years ago

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?

Nbox92• 5 years ago

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.

omarhaneef• 5 years ago

This is a great point.

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.

ghaff9• 5 years ago

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.

commandlinefan5• 5 years ago

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.

gabereiser• 5 years ago

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.

shagie12• 5 years ago

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).

zamalek• 5 years ago

Or they have have a really high hackerrank score and know the answer already.

danjac• 5 years ago

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.

bserge• 5 years ago

Or their standards drop enough to hire someone

bryanrasmussen5• 5 years ago

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.

on edit: clarification.

obviouslynotme• 5 years ago

I have known of many positions that stayed open for years until the position or company disappeared.

jelling• 5 years ago

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.

greenhatman• 5 years ago

Maybe they don't really want to fill it.

_f1dq• 5 years ago

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.

toomuchtodo3• 5 years ago

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.

bschwindHN• 5 years ago

They're too busy writing self congratulatory blog posts on their hiring process to have time to improve it.

https://alexgolec.dev/reddit-interview-problems-the-game-of-...

thenanyu• 5 years ago

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.

It was quite weird.

ctvo3• 5 years ago

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.

pkulak• 5 years ago

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

EvilEy3• 5 years ago

I have over 20 years of programming experience, am a founder, and have worked for multiple venture backed startups.

Do you want a pat on the back or something?

kryptn• 5 years ago

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.

hangonhn• 5 years ago

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.

mbesto• 5 years ago

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.

hogFeast4• 5 years ago

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.

tootie2• 5 years ago

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.

robotnikman• 5 years ago

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

poulsbohemian4• 5 years ago

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.

duxup2• 5 years ago

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.

slumdev9• 5 years ago

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’.

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...

Nbox92• 5 years ago

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.

wheelinsupial2• 5 years ago

Didn’t this exist with the PE designation in software engineering in the US?

https://www.nspe.org/resources/pe-magazine/may-2018/ncees-en...

Clubber5• 5 years ago

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.

cratermoon6• 5 years ago

If a 4 year CS degree isn't enough

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?

908B64B1978• 5 years ago

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.

Not all CS degrees are created equal I'm afraid.

skrtskrt• 5 years ago

A CS degree often doesn't have jack to do with being a professional software engineer

unoti• 5 years ago

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.

bavila• 5 years ago

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.

ravroid• 5 years ago

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.

HeyLaughingBoy4• 5 years ago

You mean like Law?

PeterisP• 5 years ago

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.

teeray• 5 years ago

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.

steelframe• 5 years ago

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.

mitjak• 5 years ago

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.

hirvi743• 5 years ago

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.

move-on-by• 5 years ago

In an environment I am unfamiliar with

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.

digitalmouse2• 5 years ago

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

jmuguy• 5 years ago

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.

ggktk• 5 years ago

next set of interviews

I really dislike when companies do this. It's very time consuming and psychologically/emotionally draining.

exadeci• 5 years ago

Leave a review on glassdoor please

HeyLaughingBoy4• 5 years ago

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.

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.

disintegore• 5 years ago

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.

nitrogen2• 5 years ago

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?"

philpem• 5 years ago

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...

randomswede4• 5 years 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.

weeblewobble• 5 years ago

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

musingsole• 5 years ago

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?

Frost1x• 5 years ago

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.

da39a3ee2• 5 years ago

Your comment explains why the variance is high; it doesn't explain why the mean should be low.

In other words, there flipside of what you said is that sometimes you'll excel and be offered the job on very attractive terms.

tootie2• 5 years ago

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.

cudgy• 5 years ago

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.

And …

engineer_t• 5 years ago

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.

DeBraid• 5 years ago

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?

dimitrios1• 5 years ago

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.

aNoob7000• 5 years ago

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.

gmadsen4• 5 years ago

which I think I'm fine with. I can learn skills on my own time. But I expect compensation to be commensurate with that

cwbrandsma• 5 years ago

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)

runevault• 5 years ago

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.

tsywke44• 5 years ago

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

nickff2• 5 years ago

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.

colordrops2• 5 years ago

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.

exdsq• 5 years ago

I find this insane and terrifying.

dfxm122• 5 years ago

they hire a lot of interns and junior people willing to grind

Is this a euphemism for an employer overworking and underpaying their talent?

ren_engineer• 5 years ago

seems like a chicken and egg problem

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?

jethro_tell6• 5 years ago

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.

closeparen• 5 years ago

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.

mamcx• 5 years ago

(hiring managers expect million-dollar candidates to accept $100-200k compensation).

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).

908B64B1978• 5 years ago

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.

NullInvictus• 5 years ago

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.

cactus2093• 5 years ago

Workers would rather not move around.

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).

ItsMonkk• 5 years ago

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.

longhairedhippy• 5 years ago

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.

wccrawford• 5 years ago

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.

shados• 5 years ago

Very few firms want to hire juniors

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.

cratermoon6• 5 years ago

"Senior Full Stack"

Also why companies will hire someone with 3 years of experience into a senior position.

trutannus• 5 years ago

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.

bern4444• 5 years ago

I take a different take here.

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.

Hermitian909• 5 years ago

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.

908B64B1978• 5 years ago

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.

ndesaulniers2• 5 years ago

Very few firms want to hire juniors, while nearly all firms desire senior-level talent.

Or many firms want to hire senior-level talent at junior-level prices.

thevinter• 5 years ago

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.

notapenny2• 5 years ago

"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.

wil421• 5 years ago

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.

Clubber5• 5 years ago

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.

faizshah4• 5 years ago

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.

gonehome• 5 years ago

The lottery of front door applications is largely a waste of time.

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.

jonfw2• 5 years ago

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 :)

faizshah4• 5 years ago

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.

pictur• 5 years ago

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.

southphillyman• 5 years ago

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.

djtriptych• 5 years ago

bruh done grown up since #thatsite lol.

tomkat0789• 5 years ago

Slashdot had a post about this topic a few years ago that I thought was colorful enough to save for posterity: https://developers.slashdot.org/story/18/03/14/1428242/deman...

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"

bob332122• 5 years ago

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?

gscott• 5 years ago

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.

co2benzoate• 5 years ago

That is how labs hire postdocs on the cheap too.

agd• 5 years ago

I want to challenge the premise of this article.

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?

adventured• 5 years ago

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.

SilurianWenlock2• 5 years ago

Computer science has the highest levels of graduate unemployment in the UK

moksly3• 5 years ago

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.

ozzythecat2• 5 years ago

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.

moksly3• 5 years ago

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.

aikah• 5 years ago

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...

paulpauper• 5 years ago

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.

shagie12• 5 years ago

The classic article on this is: The Net Negative Producing Programmer

http://pyxisinc.com/NNPP_Article.pdf

The bibliography is also something to track down and read if you're interested in the subject.

supergeek1332• 5 years ago

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.

commandlinefan5• 5 years ago

apprenticeships

Oh, man, to have somebody to do all the stuff I don't feel like doing...

bmn__3• 5 years ago

https://news.ycombinator.com/item?id=27662804

yashap3• 5 years ago

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.

hnfong• 5 years ago

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).

yashap3• 5 years ago

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).

ipnon2• 5 years ago

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.

yashap3• 5 years ago

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.

miohtama2• 5 years ago

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.

More details and statistic here:

https://www.linkedin.com/pulse/hiring-remote-angular-nestjs-...

devit• 5 years ago

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.

notapenny2• 5 years ago

"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.

miohtama2• 5 years ago

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

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.

duxup2• 5 years ago

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.

It just eats so much time.

Clubber5• 5 years ago

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.

gldev3• 5 years ago

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.

rbanffy• 5 years ago

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.

odiroot• 5 years ago

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.

mistrial9• 5 years ago

you ignore the methodical, persistent, pre-meditated and enthusiastic efforts of business development people to marginalize, reduce wages and commoditize human workers !

mihaifm• 5 years ago

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.

ffggvv• 5 years ago

i feel like everyone just wants to fight for the top 20% of talent with insane salaries while disregarding the other 80%

asah• 5 years ago

Because you need 10 years of experience in a technology platform that's 5 years old. /s

devwastaken• 5 years ago

High experience on paper is in demand. You with a college degree and not having already worked for X titan of the industry, is not. Marketers and managers always run to the cash cow, and ruin it. They have no clue how the job works, they're just following what their professors told them to do when hiring accountants and laborers.

Fire corporate, that's how you get good workers.

allo372• 5 years ago

Is this an American thing? Or maybe just a non-embedded systems thing? I live in Canada and was looking for a job recently...got two offers! One was just a casual chat about my experience, the other was a casual chat + take-home exam, which took about 3 hours.

Ater reading all these scary whiteboard interview stories on social media I studied up on programming puzzle-type questions...was a bit of a let-down, honestly.

UncleOxidant3• 5 years ago

My experience with the embedded world is that the engineers and managers working in that field tend to be older. They're from the era when it was common to get a job after a casual chat. About how old was the manager who hired you?

I got a contract gig with an embedded development house a few years back after a couple hour interview - more of a chat. The guys hiring me were in their early 60s.

ryandrake2• 5 years ago

Can confirm. I had two jobs in the past which could be considered embedded development, and got both of them after casual (but technical) chats. The first one converted to employment after a 6 month trial period as a contractor. No whiteboard hazing, no leetcode, no take-home "challenges". And the average age at both shops definitely skewed older.

I also got the impression that there weren't a huge torrent of engineers with assembly and JTAG debugging experience banging down their doors, which probably helps.

allo372• 5 years ago

Yeah, you're definitely on to something: The average age was much older- maybe not early 60's, but definitely older.

I wonder if we'll see the same sort of thing creep into the embedded systems world as these managers/engineers retire.

siva73• 5 years ago

Same in Europe, i also believe most of these rants on hn about hiring are describing a unique trend in the united states.

rsweeney21• 5 years ago

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.

UncleOxidant3• 5 years ago

Do medical doctors face this? Their work is confidential as well - patient data is highly confidential.

6gvONxR4sf7o4• 5 years ago

Medical doctors have licenses which include exams and all sort of other barriers before they’re a ‘real’ independent doctor.

jaaron3• 5 years ago

No.

As a software engineer for 20+ years, I've talked with my sister, who is an ER doctor about this often. Most folks outside of engineering think our interview processes are crazy.

Keep in mind, there's significantly more training that goes into the medical field, so there's more emphasis on the institutions. Where did you go to school? What hospitals or facilities did you work with? Your resume and references speak more strongly.

Other hurdles in software engineering hiring:

- It's both a technical and (often) a creative field.

- Most work requires teams to complete and there's very little insight into who contributed what into a project.

- You don't have many of the signals from other fields, such as published papers, law cases, or hard numbers such as sales, certifications, etc.

Long story short: we don't have good mechanisms within companies to measure engineering productivity, let alone measure programmers outside of an institution.

I'm reminded of Steve McConnell's intro to "Software Estimation":

"Meanwhile, the typical software organization is not struggling to improve its estimates from +/-10% to +/-5% accuracy. The typical software organization is struggling to avoid estimates that are incorrect by 100% or more."

908B64B1978• 5 years ago

No, but they have a legalized cartel to make sure there's never an over-supply (that would lower the price for the consumer, we don't want that!) that also gatekeep credentialing.

Meanwhile in Software there are initiatives for "Gender X of Minority Y can Code" and "Everyone can be an Engineer after 3 months of BootCamp".

JohnBooty6• 5 years ago

    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.

vlovich1232• 5 years ago

- 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.

I don't know. I think I'm pretty good at troubleshooting on the job (since I can be the one to troubleshoot & solve the trickier bugs) but thinking about doing it in an interview setting makes me nervous. It feels too fickle & up to the biases of the interviewer that day, not to mention that any serious production bug relies on knowing how the software stack operates & which things are relevant, all things that are ambiguous in an interview the interviewee would just be stuck grasping in the dark to try to figure out which scenario you might be describing.

The rest seems fine, but I'm curious about your experience with the live debugging & if you've considered cutting it.

msie• 5 years ago

"tell us about a tricky technical challenge you solved"

I have so much trouble remembering previous challenges I've overcome. I don't ruminate on them, I just move on...

majormajor2• 5 years ago

I've generally found more people flunk this sort of interview than flunk a whiteboard one.

Namely, if you've had only boring, uninteresting jobs so far, you might not have a truly interesting "tricky technical challenge you solved," and similar gaps around the other questions. Like, you can't name many of the ways a big, high-traffic site might slow down, because the internal tools websites you work on don't need caching or proxies or load balancing or...

Whereas tossing an algorithm question or two at them too to see if they can figure it out at least potentially screens for potential in a way this conversation doesn't.

So I always make sure we do both on interview loops, because I don't want to reject you just for lack of good past jobs, OR because of lack of studying algo problems recently (the good senior candidates crush the conversational one even if they're rusty on the algorithms).

mywittyname3• 5 years ago

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.

WalterBright2• 5 years ago

That's one advantage to working on open source. Your work is all just a click away.

dangwu• 5 years ago

Have you ever gotten a job from just showing off your open source work, though?

roberthahn2• 5 years ago

I have had good luck hiring developers by asking them to do a code review of something WE wrote (but framed as if a junior developer wrote it)

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.

lytefm• 5 years ago

I'm using the same technique. Taking MRs from Junior Devs together with the Ticket description, reducing the scope a bit and sprinkling different errors or incomplete implementations here and there.

In the interview, I'm checking of problems that the applicant notices and see how he approaches the problem.

So far I've been satisfied with all hired who passed that test. And they liked not having to solve stupid whiteboard problems.

gwittel• 5 years ago

I do something very similar and it works quite well for anyone except fresh grads (I've a different variant for them).

I pose a situation and introduce the v1 code. They look for bugs and propose fixes. Then I add on a new feature, and they look for more bugs. I've maybe 4-5 levels overall each having different classes of bugs, some of more or less subtlety. Fits on one whiteboard / single piece of paper in the end.

There are no syntax errors, just logic. Errors are in categories like: robustness, failure handling (internal or external), data/thread races, unforseen side effects, etc. The more experienced you are, the more problems I expect to be found. A "I don't know" is just fine (and often the following discussion is MORE informative).

bojo• 5 years ago

That is such a refreshing approach to the process. May borrow this next time I hire a developer.

Thanks for sharing.

Matthias247• 5 years ago

I disagree on 2 points:

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.

cutemonster• 5 years ago

And, about reviewing code from someone's previous job -- they might have had to write sloppy code because of time pressure

fuzzfactor• 5 years ago

Seems to me it's just so much in demand that it pays more than companies are comfortable and they almost never want to introduce any applicants to higher pay levels than they have experienced in the past.

mtnGoat• 5 years ago

something i have seen a few times: candidate is far more qualified for the job than the existing employees and they are afraid of their superiority showing, of the possibility of replacement, so they railroad every candidate. imposter syndrome can prevent teams from growing in positive ways and limit their creativity.

newbamboo• 5 years ago

When big tech says engineers are “in demand” they mean “we can make money off them.”

There could be 10 jobs worldwide, as long as companies can make money from those 10 people, they will say they are in demand. Rather than think demand equates to quantity of jobs, it’s better to think of it in terms of cost. The more engineers competing for the 10 jobs, the lower their cost to the company and the higher the demand. Lower salaries mean more money can be made by employing them. “In demand” means the exact opposite of what most people think. And by telling people the demand is high, it increases the supply further lowering costs for the companies and thereby increasing the demand. Engineers could organize and form guilds or unions, like lawyers and doctors have. But that would decrease the demand because it would increase costs. Tl;dr software engineers don’t grok labor economics. VC do.

betaby• 5 years ago

Even mom and pop shops copied FAANG interview process.

hsn9152• 5 years ago

Software Engineering is not in demand.

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• 5 years ago

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.

hsn9152• 5 years ago

They need senior level programmers, but most of them are not willing to pay much more than junior level salaries, because they think they just need copy-paste programmers.

HeyLaughingBoy4• 5 years ago

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?

nsonha• 5 years ago

Is it hard? Seems that it only is at entry level which is true for all fields. However in other fields there are very few ways to stand out as a grad so opportunities are distributed more evenly.

nell• 5 years ago

So many singles, fewer marriages :)

justinzollars2• 5 years ago

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.

It looks something like this:

  Sunday - Stack | Queue | Priority Queue (Heap)
  Monday - String | Math
  Tuesday - Tree | Dynamic Programming
  Wednesday - BFS | DFS
  Thursday - Graph
  Friday - Linked List
  Saturday - Sabbath

lifeplusplus2• 5 years ago

this is actually funny

justinzollars2• 5 years ago

agree.

6gvONxR4sf7o4• 5 years ago

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.

Apocryphon4• 5 years ago

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.

diogenescynic• 5 years ago

Because companies don't want to train anyone.

sixstringtheory• 5 years ago

Every time I think about this topic it reminds me of The Grapes of Wrath. Flyers everywhere talking about how much the orchards need fruit pickers, creating a veritable gold rush of workers. The outsized demand for jobs from the supply side of labor drives down wages and working conditions.

black_13• 5 years ago

H1b/ageism/purple squirrels

mywittyname3• 5 years ago

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.

ipnon2• 5 years ago

0.9^7 < 0.5

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.

stakkur• 5 years ago

I’d argue that the ‘demand’ is overstated, largely because job listings and forecasts != actual jobs.

dleslie2• 5 years ago

Outside of the browser space there's a lot more opportunity to land work, since there's _far less_ competition for jobs.

Thanks to the billions of dollars spent and hundreds of millions of hours expended, anyone who takes a four week bootcamp can become a passable frontend web developer. The tooling is just that simple and accessible. And so there's a lot of folks taking such bootcamps, and employers have no lack of choice for roles.

spo81rty• 5 years ago

Just because you have a degree or think you are a software developer, it doesn't mean you are any good at it and should be hired. Companies are substantially better off having fewer developers than having bad ones.

Bad developers take a lot of time to train, manage, QA their work, fix their work, fix their work again, and then finally someone else just does it. They are in fact a net NEGATIVE impact on the team. You are actually better off without them. They actually slow you down instead of improving productivity.

It's akin to hiring a cook who screws up every meal they make. Not only did I pay them to do so, now I have to pay others cleanup their mess.

phendrenad22• 5 years ago

Why does it take longer to QA their work? Do you not QA "the good developers" work? Why does their work need to be fixed and re-fixed? Do you not have a test suite?

bankim• 5 years ago

As an experienced software engineer with a CS degree and having worked as an Individual Contributor for over 12+ years, finding some job is not hard but finding a job that pays well like FAANGs and other similar top tier companies is indeed very hard.

krony• 5 years ago

Coding interviews should just:

- review your recent resume

- have some conversations around coding topics that dive in enough to know if you generally know what you're talking about

- focus on things you really expect them to do on the job

- if you really love giving algorithm riddle programming tasks, only use them on recent university grads who are used to such things. it has zero (ZERO) usage for experienced devs in our industry

- basically much of the US already interviews conversationally with little or no coding exercise. but for some reason big tech and the valley fail to change (which is funny since they are usually on cutting edge of other aspects of our industry)

TL&DR: don't do live coding interviews, they are a waste of everyone's time

darepublic• 5 years ago

Not sure but.. some people I know who work in less well paying office type jobs (perhaps with a large data entry component), see the trend and think they want to get into programming. But they just don't enjoy it whatsoever. Their preferred approach is going to the cheapest college course they find, passing the courses by the skin of their teeth and then showing up with diploma in hand at a job interview. But unfortunately that process doesn't leave them able to contribute much and the employers know it.

lake-effect• 5 years ago

I've done two technical interviews this summer. The first one was shakey, the second went really well, but ultimately both places moved on with another candidate. It's definitely a skill and learning to not get so nervous about them helps a ton. I went from grad school physics to my first data science job and I'm trying to further transition into ML engineer type roles. My biggest insecurity is not knowing the comp sci 101 basics, since my programming was self taught along the way (learning what I had to learn for my thesis research simulations and then whatever else I learned in my first 2.5 years as a data scientist). I long for the day that I have enough experience under my belt that I'm a ML unicorn and companies view me as highly desirable, but I probably got many more years of grinding til I reach that point.

kiliantics• 5 years ago

I got into software from a similar background. You can get pretty solid CS basics very quickly if you go through a book like Cracking the Coding Interview and do a few leetcode problems. It will also probably dramatically improve your experience writing code.

MeinBlutIstBlau• 5 years ago

The best way to actually learn how to code is have someone else teach you whose been doing it for several years.

I wouldn't be where I'm at today had I not had my lead help me out during my internship. My school was just trash at teaching programming. Not only was it basically self taught, but everybody got A's so long as they just submitted code that compiled. My lead actually taught me how and why this stuff works.

debarshri9• 5 years ago

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.

c4m• 5 years ago

This is super interesting!

With a traditional interview and job offer process, a new employee can ramp up without worrying their job is on the line. And I think this is important, because it can take awhile to ramp up to full productivity, which can be stressful if the new employee feels like they're being evaluated already.

Where I've worked, my new manager told me "Hey, welcome to the company. Please feel relaxed and take your time ramping up, you've already passed the interview and we're happy to have you here."

With your process, how do you deal with people getting stressed out during ramp up or feeling imposter syndrome?

dannyw• 5 years ago

If you are a semi-experienced software engineer and haven't been deliberately lying during your interview, you shouldn't really worry about getting fired.

mrtksn2• 5 years ago

Wouldn't people go from stages similar to culture shock?

1) Wow, very interesting company. I didn't know so many things can be done in different ways than I'm used to. Very smart ideas out there.

2) OMG, this company is full with idiots. Everything is done the wrong way but somehow it has not collapsed yet.

3) Yeah okay, some stuff is the way it is because it would't be feasible any other way due to the quirks of the business. Other things are the way it is because of historical reasons and it doesn't make sense to re-do it at the moment.

4) You know what, I think I understand what this company is all about. It's not perfect but people are actually doing great things here.

5) OMG, this business is crime against humanity. It shouldn't exist, I don't know how I'm supposed to do this anymore. Money can't buy me.

6) Well, the world is not perfect and I understand the imperfections and I can function. It's not like they are doing it any better anywhere else. I grew to appreciate upper management, now I understand our business and I'm happy to do my part.

3 months should be enough for a nice honeymoon stage. Both sides can know that longterm relationship is achievable if they have a nice honeymoon stage.

0xbadcafebee• 5 years ago

30 minutes? Not even an hour? I'm a senior and I need an hour to work my way through deep questions (not just technical) to see what real-world experience the candidate has while simultaneously judging cultural fit. I prefer an hour and a half to allow time for the candidate to feel more comfortable and come up with their own questions.

I definitely agree with the taking risks part. Hiring should not be about the most talent or experience, but the best mix of qualities (including their own personal goals) to fit what you're hiring for.

zoomablemind• 5 years ago

...to see what real-world experience the candidate has while simultaneously judging cultural fit.

Could you expand on how do you evaluate the cultural fit?

debarshri9• 5 years ago

Generally it is 30 minutes meeting. If the we and candidate have a click we extend the meeting. I think works different for different organisations.

hogFeast4• 5 years ago

This is something that I have never quite understood. In most of the places where software engineering is big, you have very loose labour laws. But companies treat hiring as if employees are signing on for life (compare this to how they treat downsizing). It is very strange, particularly given: the fact that almost no-one thinks current hiring practices are perfect, and the difficulty in producing a process that actually works (again, it seems odd that people hiring are engineers but take an approach to hiring that is very precisely wrong, rather than roughly correct...this confusion between precision and correctness seems common with engineer backgrounds).

addicted• 5 years ago

The cost of a bad hire is extremely high. It's not their salary or bonus, etc. It's how they can affect a team, the product, and the deliverables.

PragmaticPulp• 5 years ago

if yes then offer a year contract with 1-3 months of evaluation period

Contract work is a great way to find good talent, but it's a different candidate pool. Lots of good candidates can't or won't give up their full time jobs to take a time-limited contract job.

Those who can take contract work are often more talented and more in demand, meaning they're less worried about finding another job if the contract isn't renewed. Contract work (without benefits) is not an option for a large number of developers.

debarshri9• 5 years ago

When I mean contract, here in Netherlands it refers to the offer. It is not a hourly contract position. It is position with all the benefits.

lowercased3• 5 years ago

Contract work (without benefits) is not an option for a large number of developers.

Probably should be...? You're typically getting paid more because of "no benefits". (I HATE the word 'benefits', FWIW).

Buy your own health insurance - it's more accessible in the US via ACA. Yeah, you might miss out on some 401k matching. Save it yourself?

SilurianWenlock2• 5 years ago

How do you find contract work in London?

loftyal4• 5 years ago

Isn't contract work looked down upon in the US? Here in the UK, its the opposite, contractors make atleast 2x the money, and most wouldn't dream of going back to salary position because no company wants to pay that for a permanent employee (apart from american companies and qaunt finance with nice bonuses)

anonuser123456• 5 years ago

Sometimes, people who you think are not capable to do the job, often outperform expectations too.

I think everyone, employers and employees get too caught up in requirements and forget that humans are very general purpose. And in particular, highly capable and intelligent humans can rapidly acquire skills.

In particular, if you are hiring someone for a potentially lengthy career, capacity for change seems incredibly more important than immediate skill.

debarshri9• 5 years ago

Key problem is software engineers are generally bad at hiring. Hiring is a skillset of it's own. For example, you are technical writer for writing user facing docs, similarly I think it is specialized job where you use cognitive abilities to make a judgement, use psychology to see how the person will be in various situation.

mrtksn2• 5 years ago

Trying to measure people is a very hard thing, especially people who are not at senior levels. IMHO, top talent can show some signs but other than that it is all about the motivation.

Given the chance, motivated people can improve at great rates.

The other thing that could matter is deep knowledge. I think I heard it from Steve Jobs, in one speech he was talking about hiring people with deep knowledge in a topic and not only because you can leverage that but because the person will know what it takes to acquire deep knowledge.

Sutanreyu• 5 years ago

Can I get a job? I've been on multiple stages of interviews, of which, some are 2+ hours of coding and even if it seems promising and that everyone's happy... I still end up getting looked over. Even programs like returnships that are specifically for people who've been out of the game for 1+ year, despite showing them that I can code and architect software... I'm still kept waiting and don't get in. I feeling pretty dispirited at this point.

debarshri9• 5 years ago

What would be the best way to get in touch with you? Would love to have that "30 minute" chat with you?

da39a3ee2• 5 years ago

That's completely irrelevant to the discussion. We're talking about positions for which many people will apply. You're not going to be able to eliminate enough with a 30 minute informal "chat". Honestly, I think your comment says more about how programming still isn't taken seriously in Europe to a large extent (just look at the salary gap vs US).

webmobdev• 5 years ago

If I remember right, Google found something similar too. Everyone knows Google makes the candidates jumps through a lot of hoops to evaluate them and hire the "best and the brightest". But an internal study showed that apart from the really top talent (the rare few), all that technical knowledge doesn't matter much in the long run:

"Google originally set its hiring algorithms to sort for computer science students with top grades from elite science universities. In 2013, Google decided to test its hiring hypothesis by crunching every bit and byte of hiring, firing, and promotion data accumulated since the company’s incorporation in 1998. Project Oxygen shocked everyone by concluding that, among the eight most important qualities of Google’s top employees, STEM expertise comes in dead last. The seven top characteristics of success at Google are all soft skills ..."
"Project Aristotle analyzes data on inventive and productive teams. Google takes pride in its A-teams, assembled with top scientists, each with the most specialized knowledge and able to throw down one cutting-edge idea after another. Its data analysis revealed, however, that the company’s most important and productive new ideas come from B-teams comprised of employees who don’t always have to be the smartest people in the room. Project Aristotle shows that the best teams at Google exhibit a range of soft skills ..."

Source: The surprising thing Google learned about its employees — and what it means for today’s students - https://www.washingtonpost.com/news/answer-sheet/wp/2017/12/...

bsder• 5 years ago

All that tells me is that Google is a big company and, like all big companies, "success" is dominated by politics.

Politics never goes away unless you're the only employee, but the ratio of politics to technical ability that defines success changes drastically the smaller the company.

ndesaulniers2• 5 years ago

How do I as a candidate compare job offers between an offer in hand vs a 1-3 contract that may or may not result in an offer?

stronglikedan• 5 years ago

Same. Except, we actually hire them as a full employee, with a 90 day "probation" period. That's just the 90 days we get where we can let them go for any reason without having to pay them unemployment.

It's worked out well so far, especially for those tasked with doing the hiring.

lostapathy• 5 years ago

We tried similar in my last job. Interviews were often in the 45 minute range, but similar idea.

We didn't get into deep technical questions. Rather, we asked questions meant to figure out if the person excited about the work or not. I can bring somebody up to speed on our language, but I can't train my way into curiosity or interest.

For example, we asked what source control software they'd use if they were starting a project. Ultimately I don't care what they're into, so much as that they have used something and see enough value to have an opinion to offer - even if they've only ever used one tool.

InvOfSmallC• 5 years ago

Are you using this contract with juniors? Maybe this is a cultural difference but I would never accept a one year contract. Especially because In EU a permanent contract has a trial period in it.

debarshri9• 5 years ago

One year contract is pretty normal in netherlands.

lmilcin5• 5 years ago

Some people that don't have ability just "surf" projects. They try to stay as long as possible without contributing anything, then they find another one. I worked with people like that.

They do it because they can't do honest work that will pay comparably to their scheme.

The only way to deal with them is to not let them in.

m0llusk• 5 years ago

This reminds me of this historian's theory that WWII generals were unusually successful because of the dynamic way they were assigned and potentially reassigned within weeks: (US Berkeley Events 2011) https://www.youtube.com/watch?v=AxZWxxZ2JGE

nickjj2• 5 years ago

One drawback to this is that the engineer interviewing you, if he/she is human, will not be familiar with all of them

I see this as a potential plus not a downside. If the person doesn't understand the language you're using but you can explain how your code works in such a way that you can get them to understand it that's a really good demonstration of being able to communicate and how you would describe your code to a co-worker.

I've only sat in on a few interviews (as a person doing an interview on the sidelines) but all of the questions I tend to ask are more casual and around thought processes, or at least the pseudo code implementation. Personally I don't really care if you can't remember the exact syntax of something off the top of your head but I do care that you know how it would work and what you would Google to look it up.

Personally I don't know what it's like being interviewed tho. I've been doing contract work for my whole career and every job came from either talking casually or someone finding me with intent to hire me as long as I didn't come off like a maniac. I know for absolute certain I would fail any algorithm based whiteboard test (I never went to University) but if you're struggling to find employment, just know there's a whole world out there where people don't care about traditional software engineer interview strategies. They only care that you're dependable and can solve their problems in a reasonable and maintainable way.

isitdopamine• 5 years ago

Roughly: if there’s one job per person in the field, and for each opening there are 100 applicants, it will take 100 applications for the average person, on average to get hired.

flashgordon• 5 years ago

Because we interview for CS and not software engineering? Software engineering is at the very least requirements understanding, customer empathy, resolving ambiguity collaboratively, and on a more technical side class/interface design, maintainability, tradeoffs, testability and finally the implementation. What we test for is 3 leet code in an hour and oh asking too many questions shows lack of independence! Worse interviewers often have a different interpretation of interactions as they present the candidate at the hiring committee!

jppope• 5 years ago

As software developers/ engineers we love talking about this issue... but realistically it's just a symptom of the growth in our industry.

Anyone who pretends you can accurately assess a candidate in 3 hours worth of interviews is lying to themselves. The only real way to know if someone is good is to work with them and get to know them over a long period of time. I wrote a little bit about this here: https://jonpauluritis.com/articles/a-better-way-to-hire/. Practically speaking this means the best way to recruit is via "networking," but networking takes a lot more time than posting a job advertisement and having someone solve some leetcode questions.

(related article: "Why Aren't Developers Paid MORE" https://jonpauluritis.com/articles/why-aren-t-developers-pai...)

wreath• 5 years ago

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.

ArtTimeInvestor• 5 years ago

I think the concept of "getting a job" will go away. It is from an area where we did not have software and the internet to work together efficiently as we do now.

"Giving you a job" carries work and risk. "Accepting a job" too. We do not need that type of friction anymore.

I think systems like Upwork will become the norm. Where you just start working on some small task. Without much of an application. Without much expectation. Then both sides can grow together over time and work together more and more.

To me, the old way of writing and reading applications seems rather insane these days. Imagine we would do the same for relationships. No more dating. Write and read letters instead. Then meet and talk once or twice and then BOOM: Marriage. Nobody would want that. I think we will abandon it for jobs too.

kodah• 5 years ago

I think SWE requires two things:

- a centralized accrediting authority with uniform standards.

- a apprenticeship model.

An apprenticeship model let's you score folks while they're early in their careers and provides a standardized way to traverse levels of software engineering. This will show an engineer can write code.

In my opinion, writing code is not the same as writing optimal code, and also isn't uniformly required. For finding people that can write optimal code you need someone with a more mathematics heavy background. That is where a centralized accrediting entity can determine that you have tested on algorithms, data structures, and how they are related for entities that need that. This differs from college because the standard is uniform.

bmn__3• 5 years ago

https://news.ycombinator.com/item?id=27662804

rdw• 5 years ago

I currently believe that it is because software engineers are non-substitutable. The hiring manager is not looking for any qualified engineer, they are looking for a very specific engineer who is also qualified. Engineers also are not looking for "any programming job", they want a job at an early-stage startup or in an infrastructure team or to learn a new framework. This is true in many industries, of course, but significantly more so for software.

theshrike79• 5 years ago

Nobody wants to hire juniors and train them to be seniors because there are very few incentives to hire them.

Partly because projects are sold at such low margins that they don't allow for tutoring. Or the customer plainly states that they want 5 engineers with 10 years of experience each. It's a hard sell to make that 2 10 year guys and 8 juniors instead.

Partly because the junior will bolt to a higher paying job as soon as they've learned enough. People don't stick with companies for the long haul like they used to. Even if the pay is good, people just get bored and switch jobs.

SergeAx• 5 years ago

Whiteboard interview is a non-specific skill for software engineer, but it is relatively easy to hone for any decent coder. Like a week or two 1-2 hours in the evening. It's like solving chess puzzles, and could be entertaining as well. I think that people who are ranting about "broken hiring process" are either mediocre coders or became old and ossified.

lifeplusplus2• 5 years ago

Guys I've the solution.. Companies should do an ISA agreement. And see JR and interns as students. The new model works like this...

- If you leave/fired < 4 months no responsibility.

- If you stay after 4 months you agree to ISA agreement.

- Agreement is that if you leave within 4 years you agree to share 20% of income up until you have paid $60k.

- ISA is valid for 4 years. Then it's VOID.

- ISA is also valid if you get a tech job.

zcw100• 5 years ago

Because your premise is wrong. Software engineering isn't really in demand. It's a very dysfunctional system. I'm not even sure how you'd define "in demand".

marcellus23• 5 years ago

can you elaborate?

sharadov• 5 years ago

After being interviewed and interviewing the best course of action is have standardized exams akin to the GRE/GMAT, it's worked well for doctors, accountants and lawyers. Those professions are a lot older than software engineering.

And once you pick candidates, bring them on board and have your behavioral/cultural interview to judge if they are a good fit for your team.

Will save time for both interviewers and interviewees.

bob332122• 5 years ago

A lot of these jobs pay between 60-130k/year, have a very high preference for someone 2-5 years of experience out of college.

That only covers a small percentage of the population. I used to fit that profile and back then, the minute I made any change to LinkedIn, I had people message me. Now people don't want to waste their time on someone that will be out of their price range or more experienced than their boss. FAANG is the exception, they seem very interested in scheduling an interview.

phendrenad22• 5 years ago

There are two problems here: Getting your first software job, and getting all of your other software jobs.

Getting your first job is harder, but for different reasons. You're an unknown quantity, and the only way to know if you're any good is to grill you on things you learned in data structures & algorithms class.

Getting all of your subsequent jobs is also hard, because there's no way to know if you've been a stump who just sat there and collect a paycheck at previous roles.

Perhaps the solutions are different too.

the_only_law2• 5 years ago

So I've had this idea for a little while, still extremely rough and potentially controversial, but I've talked to a number of people who agree. Its based both on my own experience as well as chatting with other developers.

It seems to me, that there are "classes" of developers. This is not necessarily tied to market or ability, but those can definitely be be big contributors to which class you fall in. Prior to me entering the field professionally, blog posts, articles, etc. seemed to promise an easy six figure salary to anyone who could remotely code, smooth sailing after you get that first job and other highly appealing things. I have a good feeling a number of people on here would likely agree with this reality. For others I've spoken to, this was never the case. I never saw any of that personally. Reasons being both circumstantial and me not understanding the reality of things and being to quick to settle.

I talk to developers from all categories: new grads in the bay area bragging about offers at companies and startups you've heard of, experienced guys in the midwest who claim to still be able to take home salaries unheard of in any other field, or guys who have a decade of experience, but struggle to find a role to pivot into, and all sorts of others.

What always strikes me is they seem to live in different worlds. I had always considered local market to be the big differentiator, but the more I speak to people in the same market with wildly different experiences I start to question that. Particularly in this time where remote work should in theory expose more opportunity to people tied to local markets for whatever reason. Type of company seems to be the big differentiator here, and I don't mean in domain/industry or a tech/non-tech oversimplified manor.

Instead of noticed personally, that the only companies willing to talk to me are very similar to the ones I've worked for in the past. This isn't even about the "stack" being used either, but more about the organization. Similarly people working in prestigious companies seem to be targeted by other prestigious companies. But the interesting divide to me is not upper bound/lower bound, but lower bound/middle bound. People who claim to be commanding impressive salaries while doing run-of-the mill, not particularly intense or specialized work at no name companies, but are talking about median salaries above what any roles I've ever seen is willing to offer. These aren't even in high CoL cities all the time, but the numbers I could likely get cap out at least a few dozen thousand below the quoted median salaries without moving into management.

The problem of course, is when you're in the lower "classes" and want to move up. Especially at the experienced level, where you're expected in more desirable roles to have experience with X or Y, but the roles in your past never could have given you the exposure to that. The typical move seems to be to grind leetcode and pray you can get an offer through some avenue or another, but most people agree cold-applications are a waste of time, and the sort of recruiters you need are not the ones reaching out to you. Referrals seem to be the best shot here. Personally I never figured out networking. I've typically jumped more often and more quickly than my immediate colleagues, due to severe underpayment in my earliest years at places most people settle and become lifers.

I actually enjoy discussing things like this, so if it doesn't get buried by the hundreds of other comments, so please tell me why I'm wrong/right/etc. This was probably an very poor description as the idea is still rather abstract up in my head.

mrdoops• 5 years ago

More demand -> increased prices for developer time. Greater costs / impact / scale of software development -> greater risk to the collective stakeholders. Greater risk -> more potential for reactionary measures to implement more stringent hiring / control mechanisms.

That's how you end up with many many interviews, lengthy code exercises, and huge opportunity costs for everyone involved.

Consequently the same pressures would apply to software project management procedures towards growing complexity, and less agency/autonomy.

Why does it seem like 'AGILE' often transforms into less of an idea of short feedback loops, context and communication and more into a bureaucratic control system? We implement control systems to reduce state space of unknowns / chaos and trade-off variance in favor of consistency. So if software in organizations is under high demand, increased cost, and greater risk it would also suggest likelihood of similar reactionary measures to implement control systems measures on software development as a whole.

Consequently the ever present trade-offs of exploration vs exploitation or global vs local maximum would also apply meaning the reactionary measure of increasing control and consistency has side effects counter to its very purpose: improving software capabilities. Instead of increasing stringency / consistency through process/procedure also increasing cost of interaction one would instead want to reduce cost of interaction, but also reduce costs of downsides upon hiring (e.g. contract to hire + tasks to prove but where acceptability of failure is present). This has the added benefit of not accidentally removing "exploration" from the equation allowing higher risk higher reward employees into the organization which reduces risk of overfitting and innovator dilemma problems.

hintymad• 5 years ago

I remember someone on HN said a few years ago that $500K a year was a CEO's salary in a midsize company in the midwest of the US. Now imagine how long it takes a CEO to find a new job.

robot• 5 years ago

My answer is that it is not in high demand at all. It is the news sites that tell these false stories for hype.

spirodonfl• 5 years ago

Top anybody interested, I setup a google form, completely anonymous, asking programmers their opinions on the interview process. I'm working towards building something better that is re-usable and makes life easier across the board.

https://docs.google.com/forms/d/e/1FAIpQLSc8neScWE0-gmc00u1s...

So far, based on the responses, I'm seeing trends like: side projects barely matter, wages can be used as leverage to find better jobs, companies investing in your career are really important, etc...

If I get enough data, I will post my results somewhere public and I will offer some packaged services to companies and developers alike that I think alleviates the issues we're currently seeing in the tech hiring process.

deeblering42• 5 years ago

Why is it hard? Because Google ruined technical interviews with irrelevant trivia and excessively long interview loops.

For some reason a lot of the industry said "hey, if Google does that it must be right!" and they also started asking pointless trivia questions in very long loops.

But why stop there? Let's build out pointless trivia as a service, and assign a numerical score to represent your ability to perform pointless trivia outside the context of an interview.

I really think it's that simple. Tech interviews are broken and need to be drastically simplified. Candidates should be evaluated conversationally as humans and given the opportunity to learn on the job. It's a risky proposition in both directions, there's really no need for trivia, it doesn't prove anything (except act as a red flag for candidates).

nickff2• 5 years ago

I agree with most of what you say, especially about simplifying and shortening the process, but I'm not sure about:

"It's a risky proposition in both directions"

It seems like the worst case for the developer is that they get paid for doing nothing useful for a while, then have to find another job. The worst case for the company is that they pay out a bunch of money, and dedicate a variety of resources, to someone who delays a (hopefully non-vital) project. This is not a symmetrical proposition.

deeblering42• 5 years ago

they get paid for doing nothing useful for a while, then have to find another job.

That's true, but if they took advantage and get fired then they would have poor references and a spotty employment history, which will negatively affect getting another job (and would have been a factor in the hiring of the current role). So in that way there is an incentive for the candidate to perform well in order to maintain their career, and they do risk that track record to some extent when taking on a new role. It sucks for both sides if things don't work out.

Areading314• 5 years ago

I think one imbalance in the industry is that software engineers require years of on the job training to be able to independently get things done. In medicine this is also the case which is why doctors have to go through a residency. Junior engineers are kind of like hiring a resident and asking them for medical advice -- it'll work in a pinch but you really want to have at least one doctor in the room when making important decisions. This is also reflected in the salary. If companies understood this and gave juniors much bigger raises (really an annual market adjustment) there would be far less turnover and interview time wasting in the industry.

munk-a• 5 years ago

At one point I was working in the gaming industry and really wanted out. I was talking to a hiring consultant and asked if it'd be helpful to give my notice now so I could be available for an interview at the drop of a hat... to which they responded "Hell no, not only will you put yourself at financial risk - it'll likely take you longer to find a new job." I've been unemployed and snapped up for a job before - but it was that gaming job and I wanted to hop over to a place that offered a better work-life balance.

It's been my personal anecdotal observation (enough qualifiers yet?) that unemployed folks are similar to the last pear in the supermarket. Sure, that pear might look fine and be perfectly ripe - but two hundred people picked two hundred pears from a pile... and no one picked that one. When you are unemployed and looking for work I suspect you end up getting rejected by a number of places out of hand since, while there's no solid evidence proving it, you might have something wrong with you as an employee since no one is currently employing you. Once you've landed a position - especially if your LinkedIn shows several title bumps during your tenure - all the vultures salivate over how likely it is that you're a high value employee.

With engineering in particular, solid reliable team-players are worth their weight in gold, and, from the outside, there is a strong perception of vast differences in employee skills that I think is mostly driven by the extreme wage disparities we can observe "Sure I've got Sharon and they're a really solid developer - but I only pay them 45k, those hackers in SV make 250k plus bonuses. I can only imagine how amazing they are!" I think this is somewhat further entrenched by the extreme role experience with similar problems plays - and the really deep levels of specialization we have in our industry. Database specialists are absolute wizards when it comes to database stuff and can resolve problems in a fraction of the time someone who's never touched a DB would[1] - and yet both of those developers might be employed as full stack developers. Engineering is really complicated and our field has yet to fracture as much as it really ought to into specialization - so the majority of folks dip their toes into a lot of different pools.

This is totally based on opinion and personal experience but I think that specialization is what really makes it hard to "break in" to engineering - and that specialization makes overcoming the unemployed stigma even harder than in other fields.

1. This isn't an insult to the other developer btw - it's just a lack of experience and possibly a pre-disposition. There are plenty of people who are wizards with a database that will just fumble like they've never seen a lego before if given a ticket to resolve having to do with ops - or systems programming.

dandersh2• 5 years ago

Looking seriously for the first time in a few years and it's shocking how much worse the process has gotten.

I did a technical, live coding screen for 45 minutes. It went well enough that they were interested in moving forward. 4, one hour long technical interviews and another hour with management, all spread out over the course of a day. I'm already working full time with a family and I'm expected to burn through an entire day of PTO? And to add to it there was no response as to what would be covered during these 4 separate technical interviews.

What's really maddening is that it's our fellow software engineers that are doing this to us. We're the ones that think it's okay to do "take home assignments" and essentially work for free. We know how awkward and stressful live coding exercises are but yet we do them. We value our time and work/life balance but yet think it's okay for every candidate to go through 3+ hours of interviews.

The one thing that's helped keep me sane through all of this was having watched Jem Young's Frontendmasters course "Interviewing for Front-End Engineers".

Justsignedup• 5 years ago

Personal advice from going on and giving a total of at least a hundred job interviews in my years:

- no matter how desperate the situation, always treat an interview as a date -- you might meet some really interesting people, you might hear some interesting things, learn how different people think about problems. Or it might really suck and you can't wait to leave. This attitude works amazingly well. If you are happy to be there and talk, you'll have a good time, they'll have a good time, they'll like you, you win.

- always think about how would YOU interview yourself. What info is useful for you to interview someone for 30 minutes and make a decision. Shadow some interviews. Your literal job as an interviewer is to get an understanding of the candidate. If you know what they want to know, just focus every word on giving them that answer. Any interview I ran where everything I was gonna follow up the interviewer mentioned intentionally, I was like "wow, okay cool you really answered everything I wanted to know, let's move on" and those interviews are really the best with time to just chit chat and get to know the person. This is also useful for understanding why they ask you questions, asking clarifying questions to make sure that you understand what they're looking to get out of you. There's nothing worse than losing 5 minutes to someone talking about something completely pointless during a 30 minute interview. "Tell me about a time you failed." "Oh I have plenty of those, but are you looking for say a failure with my team, or a time I crashed production, or when a project got really late" doing such a prompt instantly makes the question easier for you AND makes you look 100x better.

- coding is a tricky one. 90% of the companies want you to code an okay solution, but they mainly want to see how you _think_. Like who cares if I can sort a billion numbers in memory in O(1) time, write a paper and move on with life, if I can't explain it to anyone I am useless to the team. Code out loud, just slowly solve whatever problem, and talk about the problems you're trying to tackle, what is important, what is not. If you mumble make sure to create "okay, I have a solution, I can walk you through it" because mumbling = they disengage. If you explain your strategy, it makes you look better AND if your strategy is flawed, the interviewer will often help or prompt "I really want to help but this is what I really want you to solve" and now their cards are on the table, you know what they want (see previous point).

- learn to whiteboard at least a bit. You need to be able to explain your thoughts to other engineers. Sometimes pulling out a whiteboard is an amazing way to do it. Yeah its cliche but it really is a practical skill.

- If the interview requires you to solve a complex mathematical problem perfectly on the spot or get out, you're either interviewing for FAANG (and have studied for a month or 3) or you probably don't wanna work there.

lmilcin5• 5 years ago

I interview candidates regularly.

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.

loftyal4• 5 years ago

While I agree with you that theres a few like that, you have forgotten about the candidates that genuinely don't want to spend their spare time grinding leetcode.

I worked at facebook, when I started looking for a new job, I had to start grinding leetcode again to prepare for a new job. Take a step back and realise how ridiculous this is.

Big companies that have prestiege and pay alot of money use it to eliminate false positives, not to actually recognise true positives. If your at a big company that can afford to throw away many true postives, sure use leetcode, but the rest are hurting themselfs by blinding following the mantra of FANG.

lmilcin5• 5 years ago

If you can't readily demonstrate ability to write a simple function but insist on getting hired as a developer you are, by definition, overestimating your ability as software developer, because you can't code.

If you need to grind to be able to write code you are doing something wrong. Like spending too much time at work copying code from stack exchange or relying on running your code to tell you if it is correct.

jackblemming• 5 years ago

Software developers are like studio musicians. In software hiring, we evaluate them as if they're stage musicians. Now clearly a lot of stage musicians can do good work in a studio, but you're throwing a way a lot of talent by doing this. And if you're competing with FANG, this might not be a sustainable thing to do.

rsanek• 5 years ago

I feel like a crazy person but this comes up so often and it seems to me like the answer has never changed? We don't have a lack of software engineers, we have a lack of qualified/competent software engineers. If it's difficult for someone to get a job in that area, there is at least some likelihood that they don't happen to be in the category of folks that are in demand.

user_named• 5 years ago

I think hiring processes fail when they tro to do the impossible: predict future performance of a candidate. And many processes do this. You need to be okay with some risk - so thankfully there are high-growth startups that hire less discriminately in order to scale (though of course this comes with other trade offs).

mbrodersen• 5 years ago

Interviewing is a numbers game. A large percentage of interviewers are incompetent and/or more interested in showing off than hiring. So keep rolling the dice until the stars align in your favour.

berkeshire• 5 years ago

The interviewers want to prove how much more they know, as compared to the candidate. Or worse, they have one optimal solution in mind and anything else is a square peg / round hole.

Ageism is also a factor with some age cohorts preferring to hire within their age groups who play with their cohort's favorite tech-stacks.

A badly behaved interviewer - arrogant, rushed for time and treating the interview as a nuisance, egoistic - all of these make it harder for candidates to get a job.

Data point of one: I have faced the worst lot of interviewers in startups and Unicorns, and have had the best-behaved and reasonable folks in FAANG companies.

mbfg• 5 years ago

if you are interviewing with a global company you also have to realize you are competing against potentially cheaper regions. If two candidates are anywhere close to similar levels, it may be that one candidate can be hired for drastically less money due to region. If you are living in a generally expensive region, this may be affecting you.

sandos2• 5 years ago

In Sweden it has never been hard getting a job as a developer, as far as I know. I have never had to do gruesome coding tests. Just very small ones. Say, finding syntax errors in a page of C++.

Blackstrat• 5 years ago

Having recently retired, I suspect I’m a bit older than most of the people here. I began my career in the early 80’s as an entry level developer at a large company. Eventually, I chased the money into management. In those days, we tended to hire talented, motivated individuals. As time went on and the Internet became more prevalent, everyone who had ever built a family website in FrontPage was marketing themselves as programmers. As the Internet matured, the diversity of technologies proliferated. Now senior management was telling those of us in the middle ranks to hire specific skill sets, e.g. Rails. The problem was such resources tended to be scarce and expensive. And even graduates of boot camps and weekend warriors who had crunched through a couple of Dietel & Dietel or OReilly books thought they should be paid $100k+, regardless of experience or the local market. Enter the off shore providers: Infosys, Cognizant, et al. They offered senior management what they sought - specific skill sets at bargain basement prices. And senior management at many commercial firms went all in on the offshore/outsourced model. Disney is one of the most egregious examples. Up until the last two years of my career which were spent working at a startup, I was in management at a large Fortune 100 company. This company spent 9 figures, never delivered a product, and eventually sold off the division. At one point, we had 100’s of offshore developers. In the startup, we dealt with the same issues. Senior managers often read literature targeted to their level, i.e. marketing. Hence, micro services and the cloud were the big thing when I retired. At our startup, neither was necessary for the market size and scale that we were targeting. We hired a younger architect who had the lingo nailed and told the CIO what he wanted to hear. Finally, they bought me out and I retired. They still haven’t brought the product to market, now 18 months after my departure. So, at least here in the States, we have an expectations problem and a lack of engineering discipline. Is the technology proposal appropriate to the opportunity/problem? Often, it’s not and the failures are costly and all too frequent. Retirement looks better each day.

danielyaa5• 5 years ago

It’s because they pay you a ton of money so they want to feel like they didn’t make a mistake

jimmont• 5 years ago

software engineering is decades behind other engineering disciplines; it's in the phase of elixirs, etc; that's why it's "so hard" because the industry is optimized around various insular self-reinforcing patterns; like recruiting practices in the movie Moneyball;

If software engineering is in demand, why is it so hard to get a job?

Related Stories