Should I give a feedback to this hiring process? What feedback should I give?

Question

T.L.D.R.: I have been excluded after a second programming exercise where i was asked to provide a correct, efficient solution without using compilers or documentation, and without having the chance to actually discuss the solution given. I want to give a feedback on how unfair I think this process is, should I? what should I say?

---

LONG VERSION:

I have just been through a recruiting process, unsuccessfully.

The process has started with an automated programming test, where from start I was given several hours to complete a quite challenging exercise, with two chances to submit a solution that was evaluated on the fly.

All in all a quite satisfactory exercise, which I successfully executed. I could compile, read standard documentation and not much else, but it was a positive experience.

After the exercise I had been set an "interview" about a week later. In this "interview", I had been called using a video-conference application, asked to share my screen and given one more smaller programming exercise, this time I was asked to submit a solution via email without any chance to compile it or check any documentation. After submitting the solution (twice, because after the first time it was asked to me to improve it in a way), I have been dismissed saying that I would be contacted again the day after with the following steps. But I never got the the following steps, since apparently my solutions were not considered good enough, or so they said in the following email. No chance to discuss my reasoning or anything about those solutions has been given to me.

Now, I am obviously upset about the outcome, but what I am more upset about is the process itself. I am not particularly fond of programming questions, but with the right tools (the same I would use every day on the job, nothing more, probably something less), I can successfully complete them. But being evaluated on a programming question open-loop, without any chance to verify independently my solution and with the correctness and efficiency of the solution, and not the reasoning behind it, as main evaluation points, I think it is unfair, and useless. Is there anything wrong in this?

The subsequent email mentions the possibility to provide feedback, and I would like to provide one. Should I do it? What should I say to provide a useful feedback without looking like just an upset excluded candidate?

Answer 1

should I? what should I say?

No, there is no point to providing feedback. Best to just move forwards and focus on where you're heading, not the minor setbacks on the way.

Answer 2

It's not worth it.

The recruitment process, as you've described, appears ill-conceived. If your application was successful you would presumably not be expected to work without a compiler or IDE. To assess your suitability for the role based on these artificial parameters (and without further discussion of the exercise) is absurd. They risk letting excellent candidates slip through the net.

Their recruitment process is going to help select the people who will be working with them every day. If they don't care sufficiently to ensure it is capable of identifying the best candidates (and not incorrectly eliminating strong candidates), why would you expect them to take your suggestions on board?

I'd add 2 quick things to this:

• All of the above is working on the assumption that they didn't see something while watching you work that made them feel you weren't a suitable candidate. I know when I ask people to code in interviews, I'm often more interested in their thought process, the approach they take and how they write/structure* their code than the result. (*If somebody takes care writing well structured code, using suitable design patterns, adhering to the SOLID principles and adding comments when they know the file will be deleted in 30 mins, that suggests somebody who takes pride in their work and is passionate about good code).
• If asked to do a coding exercise in front of somebody, ALWAYS verbalise your thought process. This will help them understand how you think and also the options your have considered (and dismissed) before deciding upon your chosen course of action. In addition, if you have misunderstood their requirement, this will become clear to them and allow them the opportunity to correct you (it would be a real shame if you missed the cut because they thought your solution was poor when, in actual fact, the problem was that they hadn't communicated it effectively in the first instance). Finally, if the problem is difficult or complex, seeing somebody looking at a laptop screen for a long time without typing anything can give the impression the candidate is lost or stumped - if they hear you considering your options, mulling over the boundaries imposed by the requirements etc. they know you are giving the problem due consideration instead of just diving in.

Answer 3

The last thing any company wants is feedback from someone they rejected, pointing out the flaws in their process. The only thing you would achieve is being blacklisted at that company, and at any company people from the original company move on to.

It's petty, unprofessional, and possibly fattening.

Seriously, we had someone do something like that once, and they have been the subject of stories for years.

You don't want to be the subject of stories that start with: "Hey, one time we had this guy who actually....."

Don't do it. They don't want you, and you wouldn't be happy with a company who ran things that way. Move on and find a good fit.

Answer 4

What's happening here? You're upset.

What do you want to do about it? Write a feedback.

Who needs this feedback, the company or you? It's a part of your coping process, you're the one who needs it.

Solution: Talk about your feedback with someone, eg. publish it on a dedicated site (like Glassdoor). In fact, by posting here you're already doing it, just wrong site : ) Don't send your feedback to them.

Answer 5

When the interview process is broken to the point that you probably wouldn't take the job anyway, why bother?

Asking developers to code without compiler, IDE, documentation and all the other customary tools of the trade shows either a profound lack of understanding of how we work, or a desire to be exclusionary in that you can be rejected without providing solid reasons why. Both are red flags.

(I've experienced similar - being asked to do a coding task with pencil and paper in a silent room with no machine, which was "marked" out of my sight)