Whenever I scroll a job board, I have a feeling that the things that matter to a company are (in their order of importance):

1. The technologies that the candidate knows.
2. The care for the product.
3. If the candidate is a good fit for the team.

Let's see how (and if) companies try to assess those points.

I am assuming that money is not an issue here.

1. How companies assess candidate's knowlegde

Probably the only thing that companies do well these days is to assess that a candidate has the requested set of skills. Your stack is Kubernetes, NodeJS, R, Backbone.js ? You know what to ask.

2. How companies assess if the developer is good for the product

Here, things start to become more imprecise. Usually, companies write a product description in the job listing, and that's it. Then, during the various steps of the job interview, the candidate is informed by the recruiter/manager about the company, the current state of the project, what he is needed for, what will be his responsibilities.

Startups usually do this step in a better way than bigger companies, because startups have to become profitable in a short time period and all team members are required to have a clear vision/direction of where the product wants to go. A candidate that has opinions, or that helps shaping the future of the product, is needed (required!) but nobody practically assesses this skill.

Enterprises, on the other hand, have thousand of teams (and open positions) and they have no idea where the candidate may end up. So they tend to hire generalists that can play well in many teams. Specs will arrive from the "Specs Department", and if the specs are wrong or bad you'll only know when your customers are not using your feature!

3. How companies assess that a developer is a good fit for the team

In this field, only a few companies try to do something upfront and usually they do it unconsciously; for example:

• try to let the candidate speak to as many people as possible, from future colleagues to managers;
• try to understand, during whiteboard/coding assessments, if the candidate is not only competent but also nice to work with;
• "hire and wait", i.e. you hire a candidate and if he is crap you fire him. If the candidate does not create problems to the team, we can safely assume he is a good fit. Good job, recruiters!

The sad reality is that the third option ("hire and wait") is the most used by all companies; nobody really cares that the team is happy with the new hire until the new hire is a problem.

Apart from the fact that job searching is time consuming for both parties, I see another BIG problem here. From the developer perspective, here's the list of priorities:

1. The team is a good fit for me.
2. the product being built is one that I can help build.
3. Lastly, I'm really zero-concerned about the technologies being used.

... exactly the inverse of the previous list, LOL.

1. Is the team a good fit for me?

The best thing about my job is that I've met a lot of people in my 10 years of experience and I know who I like to work with and the price of toxic hire. When you work with the right people you really don't care about work because you want to work.

So, for me, I prefer to work with positive people, that are nice and also funny, and that can crack a joke.

And, I love to work with competent people that stays updated, that continously study new things, that can highlight or predict new practices / tendencies in IT.

And finally, I prefer to work with people that treats me as an adult, by saying the hard things when things are difficult and share successes when things go well.

The problem: there's no way to know the team before actually working with them.

2. Am I a good fit for this product?

After being in the industry for 10 years I know that I am a good fit for startups and companies that build their own product, because I love to discuss about how to enhance it. I don't care if it's a nuclear power system administration system or a tool to buy new followers on instagram. I like being part of the product making: it's like an art, where you have to write a new song and you have to fit the words on some new music you've just composed. So, if the product is nice, this is a big plus.

The problem: Sometimes products are dedicated to a small set of customers, that you cannot see the value beforehands.

3. Do I know the technologies?

This is the least thing I care. The fact is, after 10 years in software development, I never decided to go in a place because of technologies. (I told you a lie: the only time I changed company to one with the same stack, I regretted it - not for the stack itself; there were other issues too).

When I started my career, Java was the king of enterprise with Spring & Hibernate, GWT was the main frontend framework, jQuery was used everywhere, and the first code sharing tool I was exposed to was SVN.

After a few years, I found myself working in Typescript, Docker, NodeJS, Python & PHP... Very different things from what I started. All of this was either learned on the job or with a book, in no more than some days. So... I am confident enough that you can learn technologies in a small amount of time, expecially if you use them daily for work.

The problem: companies want to hire people that is using the same stack because they want to minimize new hire's time-to-code.

Can we fix this?

1. there's nothing wrong in assessing the candidate skills; but please, companies, do not decide who to hire based only on their knowledge of a specific language... Nobody can know everything but everyone that take this job seriously can learn almost everything in no time. Yes, the price to pay is the mentorship for the first few weeks. But that would happen anyway. And th price of a bad hire is much higher.
2. As a company, am I hiring a robocoder - one that can code everything but with zero idea of what the product is supposed to do - or a thinking head? The first ones may produce great code, without any value to the company. The assumption here is that your company has a very good Specs Department that will exactly define every task with inputs and outputs, without errors, inaccuracies, conflicts. If you have that, coooooool but... i don't beleve you :D So, thinking heads - that study also the domain problem, the users, the
3. The power of a good, cohese team is that they know how to make things done better than a single individual. My advice is to let team members - of the team where the new hire will be put - to meet and interview candidates and decide who to integrate into their family.