Let's review your company options:

1. Wait months for a perfect candidate - If you have reasonable expectation that such candidate will appear, and you can handle workload for months without him, this is a decent option.




2. Hire more junior candidate and train him - At first, this will cost money and increase workload. "may even slow down the projects" is usually false hope, only safe assumption is that it will slow them down. On the other hand, after a month or two you will have someone to offload boring repetitive tasks to, and it is less chancy than option 1.




3. Change your offer - if offer will be significantly better than ones of your company competitors, it will attract more senior developers sooner. But can your company afford it?

What you should do is to talk with your manager, let him know the cost and risks of all three options, and let him decide. Do not lower company standards on your own. Present it as possible solution and let manager, well, manage.

Think about the first time you found someone who lacked experience but could code and learn. Would you have successfully trained the person by now? How much longer would have been needed? That's your guideline.

How long is the test assignment? I personally try to avoid companies that give long assignments, especially if I already have a job, because I simply don't have that much time to dedicate. Other people seem to think they don't want to give the company free work. I understand you need someone who actually can code, but there are less time-consuming ways to find that out.

Also, if your company doesn't offer remote work but could, it might also help attract developers.

Other things developers seem to avoid are toxic work environments and low salaries. OTOH, from my experience with my friends, a higher salary doesn't seem to make up for other problems.

We have a test assignment for the position in our team, that each candidate needs to solve before receiving any invitation to the interview.

our test assignment is quite short. 1 hour, 2 hours max

So here's an idea. Pay the good candidates for the test assignment.

An unemployed candidate might be willing to do an unpaid assignment. An employed one would be using vacation time for what could be a complete waste of time. Even as a European getting plenty of vacation, I wouldn't want to blow that vacation on interviews unless I were really miserable at my current job.

So make it enticing by compensating them. If you get a candidate with a good CV and who does well at a phone interview, offer to compensate them half a day's pay, or even a full day's pay, if they come in and do the assignment. Even if they end up doing terribly, pay them for their time.

Imagine that you have 40 developers come in with this system. You're shelling out eight weeks' pay. So what? How much would you be paying a recruiter to find you somebody? How much would you pay a contractor over and above market rate?

If the market is as tight as you say, then you're not going to find candidates who aren't already employed. Paying your candidates for the time they're expending on your test is far more likely to get these already-employed candidates interested.

This may be above your pay grade. If you want a good guy, you need to pay market rates for him. Management may not be giving you the funding to get great people.

But yes, you should be very self-critical about your own application process. Walk through it from the standpoint of a candidate: if if is irksome, rankles or offends, then you need to change it.

You must avoid at all costs the mentality of the castle guardian (or the TSA screener), righteously demanding the tribute, the absurd formalities, from any who “seek to enter the sanctum”. That mentality is made of fail: it makes you feel oh, so self-important, but it is dehumanizing and off-putting to your victims. Especially in tech or management, interviews are not an inquisition, but a romance. There's no second chance to make a first impression.

It sounds like your test regime is ungainly, and even you feel that, or have gotten feedback to that effect.

Do not lower your expectations...

Hiring good quality staff is the most important thing any company can do. Whoever you hire is going to impact the direction and quality of everything the company does for the next several years. A bad hire will hold you back. It's worth waiting months, if necessary.

It might be acceptable to hire at a more junior level than you had intended - in fact, that can be a valuable long-term investment, where you hire a junior and five years later have a highly skilled, experienced, and loyal senior. But, sometimes you need a senior right away, so a junior won't cut it - and if that's the case, don't hire a senior who does not meet your standards. They will just make everyone else's lives harder.

Among other things, this means you should keep the test (though it's worth double checking that the test gives meaningful results. How does it help you decide "GO" or "NO GO"? If it asks them to write some code, in an IDE not a whiteboard, it might be OK. If it's a collection of obscure trivia that they could look up on Google, forget it).

...but understand that this is an applicant's market.

The best developers can pick and choose which job they want to take. You are finding it difficult to attract good staff. That means your company needs to change its recruitment process.

Firstly, you need more CVs (less than one a month gives you nothing to work with). As much as it pains me to say this, you probably need to work with professional recruiters. It will then be their job to find staff for you - and they will only get paid if they succeed. If you are a small company, an applicant is unlikely to stumble across your job advert. A good recruiter will put them in touch with you. It can be frustrating to work with recruiters, and it will cost you money, but they solve this problem that you cannot solve yourself.

Second, remember that deciding whether to hire the candidate is only half of the problem. The other half is convincing them to work for you, when they have plenty of other choices of companies to work for. (Read a few threads here on the workplace and see how often the phrase "red flag" comes up. Talented people can afford to be picky. Don't let them see any red flags at your company).

Respect their time: don't ask them to complete a test before they even know anything about you. Screen candidates by CV and a brief (10 minute) phone call. Those who pass that screen get invited for interview. Spend the first part of the interview "selling" your company to them: why are you an awesome place to work? Tell them that. (Same goes for the job ad, actually. If it's just a list of things you want from them, nobody talented will be interested). Only then, when they already think they might want to work for you and they can see that you are putting as much time into this as they are, give them the test.

If all goes well, the recruiter will provide you with good applicants, they will want to work for you, and you can see if they're up to the job. Eventually you'll find the right hire... even if it takes months.

Interviews are a 2 way street.

You're requiring a time commitment by a highly paid, senior level candidate, up front, without without offering anything in return. Therefore, candidates who know they're good will sometimes politely decline taking the test, and move on to one of the other 20 companies that want to hire them.

Use a 15-20 minute phone interview instead. This will allow you to get a rough idea about the candidate's abilities, same as a test would, while also allowing the candidate to get a rough idea about your company. That is something a candidate wants to do.

There are other issues with tests:

• Some test mostly test how much time a candidate committed.


• Some tests are assumed by the creator to be much easier/faster to complete than they really are.


• Some tests fail to allow a candidate to clarify the requirements (are you looking for code with lots of comments? something finished on time? something pretty? something over-engineered?)

Due to the above issues, I find tests that are on site, with someone observing and assisting the candidates, to be much more valuable. You learn more about the candidate by looking at how they create the result, than by looking at the result.

Who make work that would be done by someone hired on that position opened for years?

Wouldn't it make sense to promote that person to that position and fill that lower position? Or hire even lower position with a task to just relief that "filler" of their mundane/repetitive tasks?

It make hard to believe that by that time you didn't acquired a lot of debt in coding. And people doing the work are busy filling that open position (because someone need to do that job).

If you have a filter assignment before even sending invitation to interview it mean you are the best paying and most prestigious company in Europe and people are dying to work for you.

[in best Maury voice] Your statement that you have one CV a month prove that it's not true.

You should lower the company expectations to hire people in your price range and expected experience with that extra step at the beginning.

There is one don't and many do's:

Don't lower your requirements.

It would do more harm than good - headcount is no measure for productivity just as number of SLOCs is no measure of program quality (in worst case it's quite the opposite!) It'd cost your company money and you personally your valuable time in tutoring subpar coworkers.

Do offer your HR your views.

... and the views from anonymous internetians here at Workplace SE. Tell them what would work for you, and tell them what works for your peers from your network (I didn't think I had a network up to about a year ago when I discovered I had a reasonably big one, singing in unison we neeed mooore peeeople!) The developer recruiting landscape has changed considerably very recently and it may be hard to keep up when you are not a dev yourself.

This too will pass - if you can wait this one out, it is the easiest way. Economic spikes like this one usually don't last long and in a few years time things will get back to normal. With your current cadence, your company will pass up tens of candidates, one or two of whom would be hired at the most expensive of times (and perhaps with lowered quality requirements!). It may make economic sense to take a step back and have a look at what this would mean once the times are not as good and your company can't effectively lower the (now) too high a pay.

Offer culture and non-monetary perks:

• Doing away with the test-before-interview would be a good signal that you are a human-first company.


• Home office, flexible hours, "pick your own kit", etc.


• Help with removing obstacles from your devs' lives: my company helps me with taxes, offers great eating even as a takeaway for the evening (frees up an hour of cooking for my wife who now doesn't want me to change jobs:)


• With relocation offer support for the partner or spouse*. This is a big one (and I'd reckon it's the best recruiting trick my company has).

All of these don't need to cost that much money or even effort (it's still much easier to get a top cook than to get a top dev, and the cook costs half as much), and can do wonders with the number of job applications your company gets for development positions.

*Anecdote: the company I work for hires regularly spouses of new applicants when they have to relocate (there is always something more to do and two lower pays are tax-wise much better than one higher one in my location). We've had an opening in my team for years for a decent web dev, and couldn't for the love of god find one. Once I got a quick e-mail with "there is this spouse of our new dev, could you talk to her since you both speak this one language well. She probably won't be a good fit but out of courtesy for our new coworker please do try your best." And guess what, we have our new pretty good web dev with a quarter of the usual onboarding time (which costs a huge deal in pay!) at the price of a language teacher for three hours a week.

Briefly, I've read several companies, after doing increasingly complicated job application tests, found that (assuming they are willing to do on-the-job training) it was as simple as "Print the numbers from 1 to 10, using fewer than 10 instructions (and not just by putting 1 through 10 in one print instruction.)" No language specified, vague psuedocode is fine.

That's it! They found this question alone was enough that candidates who could not answer it were effectively incapable of logical reasoning and untrainable; those who can answer (even if they appear to know no real computer programming language and used pseudocode) could be trained in the programming languages and tools your business is using.

This of course doesn't help distinguish between people who can write some code and excellent programmers; but I'm really uncertain if any before-employment test will do this for you.

My role is to give feedback to my manager whether particular candidate is 'GO' or 'NO GO'

Your feedback should not be binary. For instance, here's what I told the hiring manager for the last candidate I interviewed:

The position calls for the ability to mentor developers in technology X, but the candidate has only superficial knowledge of that technology. Based on the character traits I observed in the interview, and his past personal development, I judge it likely he would do an good job if given a couple months time to familiarize himself with the technology.

The hiring manager is now considering to hire the candidate, and to employ a contractor until the new guy is up to speed.

He could not have considered that option if my feedback had been binary.

That is, by giving more nuanced feedback that a mere 'GO' or 'NO GO', you allow your manager to make an informed decision whether he wants to take a risk on a candidate, and give him the opportunity to help mitigate that risk.

In contrast, if you silently lower the standards, your management will believe the candidate a perfect fit, and will not account for any slack. In particular, you deprive management of the opportunity to make the accommodations necessary for the less than perfect candidate to succeed.

Delivering nuanced feedback works better in person than in writing. I usually start with a short summary like "not suitable now, but could learn to", then explain why I think that (as far as the manager is interested, of course). If a manager is desperate to hire the guy, we can brainstorm what accommodations would be necessary.

I think that you should give interview questions to already hired staff which can be used in the internal appraisal process. Maybe they got hired at a time when that skill was not necessary, but now they are obsolete. Creating pressure should happen on both sides.

1) Do not test before the interview. This is not good for anyone. In the best case, you have thousands of developers applying, and since there is no barrier to entry for the test (because the test is the first barrier for entry for the interview), you have thousands of tests to go through, by yourself. But that's the best case. The worst case is you make it harder to apply for your job. If one company says "email me your resume", which is something I can do in 30 seconds from my cell phone while I'm sitting on the toilet, and the other company says "do this one-hour programming test" which I have to book time off and also sit in front of a computer, I'll definitely apply to the first one, and I'll probably forget about the second one in 5 minutes, because chances are I'm reading your job posting, on my cell phone, and likely also on the toilet, and therefore things I can do right now are more attractive to me than things that I can't.

2) This is a major problem in the software industry, worldwide, right now: It is easy to get a job when you have experience. It is hard to get a job when you don't. Most companies are not willing to put in the time investment into getting a new grad fresh out of school to be a productive employee. Most companies want to hire the super rock-star who already knows everything and can get up to speed in a week. But here's the thing: Time exists, and people age. Eventually all those super rock-stars will be 50 or 60 years old and want to retire. And who's going to replace them, if every company just wants those rock stars and nobody wants the fresh faces? Junior developers are important, because someone who is 25 years old and knows nothing today, might be 30 years old and a project lead on the most important project at your company in 5 years from now. Don't focus on only hiring senior developers, that helps nobody.

3) What is your compensation package like? Perhaps you're not paying market price. As you said, you seem to be aware (I'm not European so I can't verify or contest) that there is a shortage of developers in Europe. Meaning the skill of software development is a seller's market. In a seller's market, the seller (in this case the employee or applicant) is free to say "sorry, I'm not going to work for you because the other company is willing to pay me twice as much/better benefits/better location/etc" (I'll get to more soft stuff like work-life balance in a moment). You may need to engage in a bidding war with similar companies in your area to attract talent.

4) Check your social media. Glassdoor being the obvious most important one, but whatever other sites exist over there are also useful. Are people leaving negative reviews? This is where things like work-life balance, company culture, overwork, interesting projects, bad management, etc tend to get reported. Again, in a seller's market, if I can apply to 2 companies, and one company says "Great company, I always leave work at 5 pm every day, I've gotten 2 raises in the last 6 months" and the other one says "I work 13 hour days in constant crunch mode and we haven't attracted any new clients in a year and a half", I know which company I'm going to favor in my applications. Be aware of your reputation, and if your reputation sucks then your management has to do something to fix it.

Should I accept the candidate that is way more junior than our expectations, just because waiting for the better candidate may take months?

Wrong question, what you should really be asking is this:

Why is my company unable to attract candidates of the requisite experience level?

and unfortunately you haven't given us enough information about what sort of languages and tech stacks your company uses, in order for us to definitively answer. If, for example, your company is working for a government department that requires security clearances, or specialises in a niche language like Cobol, then you are always going to have trouble finding people.

Assuming that's not the case, then it's likely that forcing prospective hires to take a test before even being interviewed is discouraging them from applying. Right now, developers - especially good ones - get to pick and choose where they work, which means that given the choice between a job prospect that requires them to write a test versus one that doesn't, they're probably going to go for the latter.

This is not to say that a test is a bad thing: it allows you to weed out the chancers who are completely incompetent, which means your company doesn't have to waste time on interviews that will go nowhere. But you should remember that for a developer to come to your office and write a test, is an investment of time from their side.

My suggestion would be to ditch the test. Go directly to interviews and instead of looking for candidates that are experienced in the tech stack your company uses, and/or can answer rote questions about said stack - concentrate on finding candidates who are able and willing to learn. Personally, I'd be more interested in a candidate with many years of experience spread out over a wide variety of languages, versus someone who has spent their entire career ensconced in the comfortable bubble of the one thing they know.

Once you find someone who you think is going to fit, don't sign them onto full employment. Instead, offer them a 3-month contract that is essentially a probationary period; at the end of the period, you either convert that contract to full employment if the candidate has performed well; or if they have not performed as needed, the contract simply lapses and they need to make alternative arrangements.

You are probably also using the current test as a way to ensure that anyone hired will write quality code, but this is not a reliable indicator: just as people can lie about their experience and skillset, so they can write code that is far better than their norm. Quality is ensured via regular code reviews, not a once-off test.

Finally, you should consider that a test (which is probably timed and taken in an unfamiliar environment, hence somewhat nerve-wracking which will impact performance) is not necessarily the best tool to judge someone's competency. In particular, a written test is an extremely poor tool because no programmer writes code out by hand on paper: we live in IDEs and command-lines with productivity features that we take for granted and probably can't live without.

Anecdote: I work for a software company that also uses a test as a pre-screening. Not only are we in the same boat as you regarding getting enough developers, one of my friends wrote our test and flunked it, which to me was absurd because I know his skills... after being rejected by my company, he's gone on to become the head architect of a different company.

Interview first, Test Later.

If the dev role has specific needs (eg: must be able to code data science algorithms in cobol) then that's just part of the job description / weed out.

Get applicants by offering interviews. You'll get more folks coming in the door.

Being able to do a test perfectly from the start is not indication of a "perfect" candidate. You could end up with a rock star that drops performance of all other employees due to being so hard to work with. You could end up with a great employee who leaves you 3 days later, because they got another job offer.

When you interview up-front, you get to weed out people for all non-tech things... can they speak to people well? can they talk about past projects clearly? does it seem like they added value at their last jobs? do they lack a few skills needed for your task that they could easily pick up and become that "perfect" team member you're looking for?

After you weed out interviews, then put them through the test and see which ones perform well (or well enough).

At my last job, they had a SQL test. It had been a couple of years since I coded pure SQL. It was a hand-written test. I was sure my SQL wasn't perfect. But, they gave me the job. Why? They had a huge lack of "qualified candidates". But, my SQL was better then what they had seen. They were also paying peanuts compared to what most SQL developers were wanting. (I had skills, but no college degree or certs, so I had to take what I could get). I ended up working there for 8 years and was a rock star employee for them. I started in a dept with 5 people that got whittled away as I learned more SQL on-the-job and automated things. I wasn't hired to do data auditing, but I did so anyways, and found million-dollar-problems with their systems (ie: there systems let CSR's input incorrect data that was costing the company millions per year). I brought more to the table then a simple coding test could relate.

So, instead of using a 1-2 hr test to find the perfect diamond from the start, use interviews to open up for diamonds in the rough and then polish one you feel has a lot of potetial.

Just make sure that in the job description you let folks know that there will be an initial interview, and then, if selected, candidates will be required to follow-up with a 1-2 hr test.

It really ticks me off when potential employers don't let me know what I'm getting into when I apply to them. (EG: finding out they have 5 rounds of interviews when most places only have 2-3, or finding out they have some obtuse testing requirement and I have to go to some special location 5 hours outside of town or any other absurd requirment.) Potential employees want to know what the obstacle course will be to get hired UP FRONT, and if it has a huge time-investment up-front (like making them take the 1-2 hr test first), then chances are good they're going to pass you by as other places have started to change how they hire in order to cater to the limited employee market.

You're looking for a junior dev. They're not going to be perfect, they're going to need time to learn, and they're going to take up more senior developer's time as they learn. You cant avoid this so stop looking for the perfect candidate who already knows what you need and find one you can teach.