The crux of the problem is that we've interviewed dozens of applicants and none of them have been able to pass the sniff test. We are setting the bar pretty low, but the average skill level of the people we've had access to is shocking. There just isn't a supply of good developers for companies that aren't FAANGs or unicorns. And before anyone says we aren't paying enough, or we are being unfair, the reason these interviewees are not passing is because they can't answer basic questions about the languages and frameworks they've been using for years. Things that you would know if you spent five minutes reading the first few pages of the official documentation. It's baffling. If I could even get a talented junior that I thought was capable of leveling up to a senior position in a few years I would be ecstatic.

Edit: for example, when interviewing for a react/redux position, one of the first questions I ask is "if you need to make a network request in an app using redux, where do you put it?" at least 3/4 interviewees answer "in the reducer". From page 3 of the "Basic Tutorial" in the redux documentation:

  Things you should never do inside a reducer:

  Mutate its arguments;
  Perform side effects like API calls and routing transitions;
  Call non-pure functions, e.g. Date.now() or Math.random().

>There just isn't a supply of good developers for companies that aren't FAANGs or unicorns.

...at the salary you are offering.

I see many people hiring adjusting for cost of living but not adjusting for the place being less desirable to live. Also, given the reputation of FAANG and similar, working for them is viewed as something of a future investment. That is a benefit your company likely cannot offer. So even if everything else was on par with a FAANG in terms of pay, benefits, and working conditions, ideally you would have to pay a slight bit more to make up for the difference. Granted, the market is never that rationally acting in any individual case.

Having seen numerous IT managers having trouble hiring, the most common shared issue is too little pay.

No, that's why I said "before anyone says we're not paying enough...". There are team members making $2xxK/year here, and we're not in a coastal city. The problem we have is that almost every person that comes in here bombs out in the first five minutes of the interview.

If that's a competitive salary for your area (you would know better than me, but that range in the middle of the country certainly seems competitive), then have a look at your recruiting sourcing funnel.

If you're only sourcing the same 75% of active job seekers who are bombing most of their other interviews [thus leaving them available to come in and bomb yours as well], start advertising your positions elsewhere or trying to recruit passive job seekers/encourage employees to scour their own networks.

If you don't change something, you're likely going to keep getting more of the same.

You're correct. The problem is that the positions we have open are for front end developers, and for a variety of reasons (mostly that the scale of complexity on the front end has increased so rapidly that the industry still has a lot of people in it that were writing mostly HTML and CSS a few years back) the supply of competent developers is far lower than the demand, and anyone worth their salt is already happily employed. Highly skilled front end developers can basically write their own check these days, and if you manage to find one in the brief amount of time they're in-between jobs it's pure luck.

... so you're not paying enough to entice them.

Which is what was said three posts up.

Thanks. Unfortunately we can't afford to pay front end developers $300k/year. And what we are paying is more than competitive. It's not an issue of pay, it's an issue of availability and not having the resources to stalk and poach developers from other companies. We also have a generous internal referral bonus, and various recruiters sourcing candidates. Is there something else I'm missing?

Edit: I don't think you are understanding what I'm saying. We are offering higher than average pay for a job with average requirements, and we haven't been able to find average candidates. And I'm well aware of average, upper, and lower bounds to salaries here.

If you have budget for two poor front end devs, IMO you’re way better off paying 1.5x and getting one good one, if comp is the sticking point for landing a good front-end dev.

“We can’t afford that!” “But you can waste money on two crappy devs?!”

(If you only have budget for one, the cash flow doesn’t work, of course.)

> Is there something else I'm missing?

Yes, probably. Why do you need a supply of new front end developers? Is your workplace exceedingly lethal?

Have you considered that paying $2XX/year is a signal? It attracts a certain type of candidate and you can't extrapolate the talent level of the entire market just based on your experience with those that would try to land a $2XX/year job. Where I live, trading firms can pay that much and more, with potential bonuses that would make your eyes pop out of your head. Yet many extremely talented people I know would never submit a resume: "No thanks I like having a life." Many people I know that used to work in that environment think of it as an insurance policy: "at least I know that if I ever need money I can go back."

> We are offering higher than average pay for a job with average requirements

A lot of people will pass you by and assume that something is really wrong at your company to need to offer so much money for an average job.

Seems like Paul can’t catch a break here. He is simultaneously not paying enough and paying too much...

If there is both a pool of qualified candidates that don't think the pay is high enough and thus don't apply and a pool of candidates that think the pay is so high there must be some catch and don't apply, they could both be true. You have to decide which pool to target.

At least one of those two pools exists, because if not it means there are no qualified developers looking for a job, in which case perhaps the issue is with the definition of qualified.

Also, there is the possibility they are getting great applicants that are filtered out before it reaches the individual currently here. It may be possible HR or some automated system is filtering them in such a fashion that good candidates are lost. Maybe HR is demanding 7 years experience in a 3 year old technology.

What we can reasonably assume is that the hiring manager is not finding qualified talent and qualified talent does exist. The idea that qualified candidates are only applying to FAANG or unicorns seems far less likely than something about the position is the reason they aren't getting anyone qualified.

Have you considered hiring remote workers so that you are not limited to those living in, or willing to move to Austin, Texas?

Maybe hire people with the a good teamwork attitude + ability to learn, and training them up to the required standard?

Sounds like it'd be more effective than spinning wheels without traction. :/

If you're paying $2xxK/year and allow remote just post your job link here. I, and all my social circles, are fairly successful devs in a coastal city and would jump on any offer that high as long as we didn't have to move to the midwest

Edit: I mean this as in I know several people including myself who apply for 2xxk/year and remote. Post or dm me and I'll see what people I could send your way

Wow, $250k/year is quite high for Austin, Texas. It's shocking to realize that you can't find decent programmers even at that pay grade.

> There just isn't a supply of good developers for companies that aren't FAANGs or unicorns.

> interviewing for a react/redux position one of the first questions I ask is [very vendor-specific technology question]

FAANGs don't hire people for "react/redux positions", they trust smart, conscientious people to learn it when needed. Maybe that's your problem.

Maybe the good people aren't already "react/redux programmers".

Could you not hire someone smart who doesn't already know react/redux and teach it to them? Or give them a couple of weeks to do some tutorials?

I knew almost zero about web dev (I had been a decent C++/Java/Scala backend programmer) when I was hired to work in a web dev role -- I spent the first two weeks doing RoR tutorials on the internet and was just as productive as anyone else a couple of months after that.

This is usually not a consideration and has not really been there for decades. What many forget is that people who are speciallists in the area thay are recruiting for are not necessarily the best candidates for the actually position.

Sometimes (many times) if you can get someone who is more of a generalist and is capable of diving in to gain the necessary skills is far more valuable. They are quite often the first to be discarded from the interview process.

Many of the psoitions I have participated in required handling new tasks that were not within the broad scope of what the position was expected to handle. Yet, having the attitude of "let us see what is needed", meant that I was bale to be functionally more effective in that position, including being the "go to" person for those who needed problems to be solved that their normal IT groups would not handle.

I have found too many "code guru's" to not be capable of thinking outside of the box whaen it is necessary. You don't have to be a "brilliant coder" but more of a person who can develop an understanding of the "problem space" of those having the problems that require solutions.

This is what we've resigned ourselves to, but it's very expensive. We're building crud apps, not doing cutting edge research, so I assumed we would be able to find someone that is already up to speed on the language and frameworks. You also have to factor in the cost of senior developer time spent coaching, the lost productivity, and the code quality suffering in the meantime.

You might be shooting yourself in the foot by having not picking an ecosystem that better supports your business case. No one I know who's good at React+Redux would pick a CRUD app as the domain they'd like to exercise those skills in.

The app in question is used by retail employees at hundreds of locations to manage inventory. It runs on a tablet, has to work offline, and has a very dynamic UI that has to keep thousands of complex relational entities in local state, and perform aggregate functions on them in real time. It's still a CRUD app, but it's very much the use case for a SPA.

> We're building crud apps

Perhaps you shouldn't be using complicated faddish framework then?

Was just thinking that too. Many folks like to complain about the quality of "the help," but don't look in the mirror.

How quickly do they answer that to get that so wrong? I freeze like crazy with interview questions. Even you just putting the question there, my brain froze and I couldn’t remember the word “action” for a couple of seconds.

They usually answer confidently right away. It's one thing if you're nervous in interviews, it's another if someone asks you a novice-level question about your area of expertise and you give an answer that is objectively wrong.

Judging by your posts in this thread, have you considered the problem might be that you (and many other companies) hire people based on their ability to answer theoretical questions (which also happens to be while under a lot of pressure), rather than their ability to code? I'd like to think there are plenty of candidates that have open source projects that showcase their coding skills, or that have made impressive side-projects.

It's not really a theoretical question though. It's a very concrete example of the most common operation you would need to perform in a front end developer role. And none of the applicants we've seen have side projects or code on github. If you know of a method to ascertain someone's ability to code in a professional environment in a one hour interview, I'm all ears!

Honestly you don't seem to be a well put together environment and it feels like you expect to hire experts in some random framework instead of good software engineers. I'm not surprised you're only getting code monkeys who have used your framework in passing or have done basic pixel dev applying that don't meet your bar.

I'm getting tired of replying to troll-ish posts, but:

> Honestly you don't seem to be a well put together environment

That is a pretty bold and unfriendly statement to make based on very little information.

> you expect to hire experts in some random framework

We're hiring front-end developers to work on a react and redux application, which is kind of a de-facto standard for single page applications these days. We have an app with a highly dynamic UI that requires immediate user feedback and must work offline. I don't think we're misapplying the technology.

> I'm not surprised you're only getting code monkeys who have used your framework in passing

Again, we're interviewing people with several years of professional experience using react and redux listed on their resumes. We're also not tailoring the interview process to only react and redux specific questions, but if someone claims to have been paid to write react apps for three years, I'm going to ask them some questions about writing react apps.

Even so, you shouldn't underestimate people's ability to have a meltdown during the pressure of an interview.. I won't comment on the React question, since I've never used it and don't know what a 'reducer' is.. but even the truly bizarre for-loop you posted is likely to cause confusion to some people during the interview. If I saw it while I felt the pressure of an interview, then I'd possibly feel confused and would need a couple of minutes to understand what was happening. This would no doubt reflect poorly on me, which is unfortunate because when I don't feel the pressure of the interview then I can instantly understand (and laugh at) the code.

I believe you'd have much better results if you ascertained the applicants technical ability before the interview, and instead spent the interview getting to know the person, to see if (s)he had a positive and friendly personality. If none of your applicants have side-projects or code on GitHub then perhaps you're searching the wrong places, and/or failing to properly promote the position (especially if some of your developers are earning 2xxK). I'm sure if you posted the position in HN's 'Who's Hiring' and included a 100+k salary, then you'd get flooded by talented developers that have open source code/impressive side-projects. And if somebody with an impressive resume doesn't have that, then you can just request a small take-home assignment that's related to the work you do. If you'd like to avoid getting flooded with resumes', then you could also just reach out to the developers you find interesting on GitHub.. considering your salary range then I imagine you'd have a very high interest rate.

This question is really tricky, though: depending on your frontend stack, the answer could be in an event handler prop (e.g. onClick). In mapDispatchToProps, in a thunk, in a saga, etc.

Correct. Any one of those answers would be acceptable :) (except mapDispatchToProps, that will fire the API request every time an action is dispatched anywhere in your app). Also, the context of the question is very specifically "within redux", and all I'm looking for is an understanding that redux is synchronous by default and asynchronous logic has to be performed in a middleware. If your answer is "put it in literally the only place you aren't allowed to put it", you lose some credibility. Also, so many people in this thread are getting hung up on the fact that we're trying to find people that understand a very common framework that we use, and that the candidates claim to have professional experience with. I wouldn't expect a junior to understand the details of redux, but we need senior people that don't require a year of hand-holding to be productive. If I am hiring a plumber to fix my toilet, and they say they have three years of experience fixing toilets, and they don't know how a toilet works... am I at fault for having unrealistic expectations?

Plumbers with 3 years of experience fixing toilets are usually still in their Apprenticeship programs. Around year 4 or 5 they'll graduate to Journeyman at which point they're authorized to work without the supervision of a more senior plumber. You hired a plumber to fix your toilet, but you have a waterless composting toilet and your plumber's knowledge is still at the level of "water and poo goes down the pipes".

Your hiring woes will get easier to handle once you start treating the Competent Sr React+Redux Developer role as rare. React is certainly popular tech, but solid knowledge of the ecosystem is still far from common. All the places I've done react at had ~10 frontend capable devs, but only 1 or 2 people who really knew what was going on.

I mean in the functions in the object returned by mapDispatchToProps, something like `onClick: v => fetchJson(‘/foo’).then(w => dispatch(fooAction(w))`

Thunk, saga (as far as I know), etc have you put the code in an action [creator].

No, usually with sagas, your action creator stays synchronous and you yield your actions from a generator function that contains all the asynchronous bits.

It’s a beautiful system that brings a lot of the benefits of a Free-monad style effect system.

Javascript sucks.

I work with lots of really, really good developers who struggle a bit with JS. Most of it is because they come from a totally different background, and the other part is Javascript in general just makes things difficult.

This is just false: there are a bunch of sharp edges in JavaScript, but once you know them, the language itself is one of the more pleasant languages to use: this can be a bit of a problem, since the languages itself doesn’t force a particular structure on your code like Java or Haskell do, but on the other hand, JavaScript is an amazing language for experimenting with new programming paradigms and application architectures.

What structure do you believe Haskell forces on your code?

My experience with Haskell is that it's the most expressive and flexible environment for exploring different ways of structuring code that I've ever used. I've seen everything from extremely-imperative code carefully managing memory allocations and munging bits, to very abstract high-level libraries that declare abstract computations that can be interpreted or executed in a variety of ways.

I'm very confused and surprised to see someone assert that Haskell forces a particular structure on your code.

Haskell doesn't force anything, but it does make some pretty strong suggestions. Haskell suggests immutable data, pure functions, and algebraic thinking. You can make your data mutable, do everything in the `IO` or `State` monad, etc., because Haskell doesn't force structure on your code -- but the suggestion is still there, whispering in the back of your mind.

(This is what I love about Haskell, BTW, so please don't read this as a criticism.)

This is what I was thinking: if I just want to sit down and design myself an object system, Haskell’s type system gets in the way of the necessary parts. (Unless you want to limit the interaction between your object system and haskell’s types in annoying ways). I’ve implemented CLOS-style mutimethods as a handful of functions basically translated from the Common Lisp in the art of the meta-object protocol. And the multimethods work transparently with any ja type.

This isn’t a criticism of Haskell: there are plenty of benefits to forcing declarative IO and limiting the language (roughly) to features that don’t break type-inference, but those advantages of Haskell make it much less enjoyable to experiment with programming paradigms in.

Thanks for the clarification!