Alright. It's me. The "bad" man on the other side of the email conversation.
I was struggling with myself if I should reply to the post at all because
publishing a private email conversation without letting the other party know and agree on it upfront is a no-go for me.
so many false claims and hypothesis have been brought up without even trying to think about the intention of the other side.
To find a way for myself, I don't want to get into any of the details of the posting itself.
But I'd like to talk about motivation.
In my reply, I will focus on our way to evaluate and handle applications and why we are doing so.
Why are we doing this at all?
We're advertising our job offering world wide. Therefore we receive hundreds of applications a month.
As you can imagine, we need some kind of differentiation/filter. Is a candidate good or not? How can you tell?
We decided to standardize our application process and try to be as transparent as possible right from the beginning.
Our job description already states the main technologies required to fulfill the position. Python, Django, RDBS, HTML/CSS/JS are hard requirements. Celery, RabbitMQ, Sentry etc. are a huge plus.
However everyone can claim knowledge of these fields. CVs usually are full of fake details. People listing technologies they just slightly got in contact with.
Our approach are multiple steps:
Screening CVs - even if most of them are meaningless, we can filter hard requirements. E.g. we can only get a blue card for people with recognized diplomas (thanks, German government), we can check GitHub profiles, StackOverflow, etc. if provided
HR phone call - check salary expectations, English language, reloaction/remote setup, etc.
Django ORM questions - three questions to challenge knowledge of the Django ORM and if the candidate knows what's going on behind the ORM courtains
Django test task - the thing we're discussing here. More on that one later.
A video interview with the tech team - 50/50 technical and personal questions, get to know each other
Two day onsite workshop - we fly the candidate to Germany to spend two days on different challenges with the team, have a team event in the evening hours, etc.
Moving for a job is a huge change. We believe that both sides need enough time and enough insight to make a proper decision. We don't want to make anyone move from a foreign country to Germany when we're not 99% sure that it will work out.
After each of these steps, we have a commitee of people making the decision if we should continue.
The test task is evaluated and judged by the senior staff, after the workshop the whole team decides. The decision to continue must always be unanimous. If only one involved person has doubts, we stop the recruiting process.
Why exactly such a test case?
Let me start with an open question to everyone reading the text: What would be the alternative?
How can you get to know what someone's really able to do?
This is our biggest question during the recruiting process.
Most of our applications are coming from outside of Europe. Thousands of kilometers/miles away. Even if that would not be the case. A long interview or an onsite workshop at this point would cost the candidate as much time as the test case does.
We're doing the same test case with slight variations over the last few years. It changed from virtualbox to Docker, from Python 2 to Python 3, the API was added etc.
We never got any bad feedback until this posting came out..
Please ping me if you know a better and faster way to tell apart people who can fulfill the job and ones that don't.
What feedback to give?
Ryan already pointed it out in his reply. We're trying to be as open and give as much feedback as possible.
It's always people involved. Humans made of flesh and blood. With hearts and souls.
Even if we reject someone, we want to treat them with respect, give feedback on why we made our decision and what someone could change and learn in the future to compensate. Give them a chance to grow.
Treat everyone the same way you would like to be treated yourself!
I know of US companies that don't give any feedback at all because they fear to be sued or will be confronted with any other kind of resistance. This is not how we want to be remembered.
Why not just try?
Imagine living in south america. Moving to Europe will be a huge change and huge challenge.
We're not happy with the idea of relocating someone here with serious doubts if it will work out.
What if it doesn't? Depends on the visa your embassy will assign.
Usual working visa -> they would basically have to leave Germany right when the contract ends
EU blue card -> better but still only six weeks to find a new job or leave the EU
I would not be able to arrange that with myself.
We fortunately only had to terminate one contract during the probation yet - this was one of the worst days in my life. Not because it wasn't justified, but because we were ending the dream of someone!
Every story has two sides. This was ours.
Connect the dots. Let me know your feedback!
I'm a software engineer working as a full-stack developer using JavaScript, Node.js, and React. I write about my experiences in tech, tutorials, and share helpful hints.
I'm glad everyone can hear the other side of the story. Your reasoning and process make complete sense, especially for international candidates.
I'm not sure why everyone is jumping to unwarranted employer-bashing. The assignment does not seem out of the realm of possibility, especially for an experienced candidate. It isn't doing a full project for the company that you are not being paid for, the value of this project is assessing a candidate, not putting it into production. I'm sure their developers are more than capable of building this, they do not need to outsource it to interviewees. I do not know too much about Django, but breaking down the project seems like:
Fire up a local Django/Postgres environment, which I'm sure there is a clear how-to guide out there and anyone experience with it should be able to get up and running quickly.
Create the database schema, populate some test data.
Implement CRUD functions to work with the data.
Implement some basic pages to interact with those CRUD functions.
Create a few API endpoints to output some of the data with some filtering options.
Document your solution.
If you are experienced in the language and framework and starting a brand new project, does that take days?
I'm not sure why there are so many dismissive attitudes on performing coding challenges or a demand to be paid for doing them. I find this method to be much better than white-board coding or trivia questions that aren't representative of a good candidate. This method is a better representation of what you will be doing every day (plus you can use any resources you like and are encouraged to do so), so why not interview candidates that way? If the project is massive, I would understand, but I don't feel that this one is.
(4) In Django you don't even have to implement a frontend. There is a builtin admin interface which can be easily configured and would fulfill the CRUD requirement.
I will only answer on these claims because you're talking about a non-involved third party:
This task had an additional requirement to implement an Angular frontend for someone who never used Angular.
The candidate was a personal reference and we had some extra agreements with him on that part.
Also commits spread over multiple days don't mean that this time has been spent. Most applicants have at least one job and a family. We don't expect them to finish the task within a day just because we ask for max. 5 hours of their time.
Please don't assume anything you cannot know for sure.
// , “It is not so important to be serious as it is to be serious about the important things. The monkey wears an expression of seriousness... but the monkey is serious because he itches."(No/No)
Let me start with an open question to everyone reading the text: What would be the alternative?
How can you get to know what someone's really able to do?
I can't comment on processes I'm directly involved in. But just to give you some hope, I'll just say that it is possible to apply DevOps / kanban styles of reasoning to this, to the point of a single day process from initial contact to structured interview to hire with very, very minimal cost of time to the candidate within that day.
Haven't personally seen ways to deal with the time zone thing, but I've heard rumors of good things in that area too.
Would love to hear details about streamlined application processes.
As this post is quite old yet, we've since heavily revamped and automated our process and test.
The application test is now using a scaffold and is hard limited to 2 1/2 hours.
Sorry to resurrect a dormant post, but I liked seeing the other side to this.
I won’t comment on whether the test was onerous or not. I’ve spent a week on programming tests before. I did when I really wanted the job and didn’t when... well, I didn’t. I’ve spent multiple weeks navigating through multi-stage interview processes only to not get an offer. It sucks, and it hurts, and it really sucks. But you could have reapplied at a later date... until you posted this.
After a decade as a hiring manager I understand both sides of the resume better than anyone that hasn’t done the same. I’ve seen it all; unacceptable people get hired for unacceptable reasons, and acceptable people not get hired for unacceptable reasons.
But whatever you do, don’t post it online for potential employers to find, and learn to move on.
// , “It is not so important to be serious as it is to be serious about the important things. The monkey wears an expression of seriousness... but the monkey is serious because he itches."(No/No)
Yeah this is the most reasonable part of the thought process where a lot of the hiring anti-patterns originate. Beyond hiring, to any market selection process.
Aside from antagonistic people like me (or at least like I was a few years ago), people aren't going to respond "No." to a job post.
So you don't see all the people who pre-reject you.
Just keep in mind who's filtering you, and that you will often not see the negative results. Even if some change to the hiring process bumped the rejection rate by qualified candidates, how would you know?
Did you know that there's often an inverse correlation between available time and the factors that create demand on it (competence, grit, hard working attitude, customers first)?
// , “It is not so important to be serious as it is to be serious about the important things. The monkey wears an expression of seriousness... but the monkey is serious because he itches."(No/No)
Thank you for posting your side of the story. I would have sided with the author from just the article, but he lost my respect by posting private conversations on the comments. Also for continuing to argue in the comments. I think a nice tall glass of humility is overdue on Yaser's part. Sucks that he wasted so many days on a project like this - maybe there could have been more timely feedback, pair programming etc to avoid this.
I came to this post from the newsletter expecting a totally different vibe. I thought this was going to be a post about being humble because we're all mediocre, and that there's always someone better than us. On the contrary, the author seemed to get really bitter about being rejected...
For future tests, we will let the applicant know that we expect them to stop after a maximum of five hours - no matter how far they've got. After that we should have a look at the implementation together. Maybe a video call to discuss it.
And we will be more clear on what we don't expect.
As long as we don't specifically ask for it, we don't expect a single page application or a deployment on some cloud provider.
Firstly, thank you for stepping forward & joining the discussion - and for keeping it professional.
I have no stake in the "game" but since you asked for alternatives...
You say each step has to have a unanimous decision, yet no-one had concerns when the email to the CTO had "gotta" and emoji etc? You missed an opportunity for early rejection there, and with hundreds of applications per month, I'd be taking everything I could to reject early.
Now, with hundreds of applications per month, and the whole team discussing each stage of each applicant, how do any of you get any work done? I know I'm deliberately exaggerating the point, but surely a select few can make the decision at each stage?
We also hire internationally, but I think we have a radically different approach (even though we use resume, phone call, tech test and Skype call before a flight). Successful candidates also get 6 months accomodation & food paid for by us, and we pay the costs of relocating in the first place...
Our tech test is significantly simpler than yours (basic CRUD application with maybe 7 requirements). Senior Devs can complete it in an hour & change, and it's done that way, because sometimes we choose to do the test at our office, and we can lend the candidate a laptop of they like. Juniors are allowed longer, or we simply skip the tech test.
When we receive the test answer, I don't look at the code, at all. I do look at the test coverage report, any comments in the code, and the commit history (one big commit at the end equals a rejection just the same as 400 commits an hour).
The point I'm making here, is that the tech test is looking for aptitude... If they already know the answer & hammer it out, good for them, they'll be highly productive. If they struggle & try things and back track a few times - I get to see how they think, if they're capable of learning etc.
A good developer should, in my view, know when it's ok to Google & read stack overflow. They don't need to know the way we work, or the depths of any frameworks we use - that'll come in time with the right attitude.
No one involved in our recruitment process is an English native. It's our second or even third language.
We'd like to start with a feelgood settings for our applicants. If that means using shortened words and emojis, that's fine - we will use them later in Slack too.
Not all of the team is involved in every stage of the recruitment.
We can already reject a big share of the applications based on letter of intention and CV.
Since most of our positions are on-site, we expect applicants to think about what it means to make such a move. E.g. expected salary in Indian Rupies for a German position is a direct rejection. I'd guess that only 20% get to the three ORM questions and 5% will get to the test.
The senior staff comes in at the test implementation and the whole team during the on-site workshop which happens at most 2-3 times a year.
Your approach sounds great. But also costy. We're still a relatively small company overall with a dev team of around 10 people. We just cannot afford getting people on-site for a workshop and then reject more than half of them. Most of the workshops have to work out or I'm running out of budget :-)
Same for the learning part - I cannot hire someone on a regular or senior position because they know the language but then have to learn the framework for half a year.
I'd really love that to change over the next few years.
publishing a private email conversation without letting the other party know and agree on it upfront is a no-go for me.
But if you hadn't replied, we'd have no idea who you are, so it would make no difference whatsoever that he published a private conversation. That said, you make some fair points about the coding challenge.
It's unfortunate that this conversation seemed to escalate the severity of what was a pretty tame post. The emphasis of Yaser's post was essentially for one to accept one's mediocrity/less-than-greatness (if one feels mediocre/less-than-great). His only actual criticism of you and your company was that your bar seems unrealistic; it's certainly a fair assertion given that such a judgment is highly subjective (i.e., there's no right or wrong about how realistic your bar is -- it's just opinion). But as the comments started flowing, some of Yaser's comments showed that he was, in fact, more bothered by your rejection than he claimed in his post... and there's nothing wrong with him feeling that way, though, again, we'd never know if you hadn't replied.
I certainly don't fault you for your interview process -- you have to do what you think is right for you, and it appears you and your team put a lot of thought into it. But I still don't get why you replied and put so much effort into this comment section when none of us could possibly know who you or your company were.
Best of luck with your new hire (I'm not being sarcastic; I mean it).
// , “It is not so important to be serious as it is to be serious about the important things. The monkey wears an expression of seriousness... but the monkey is serious because he itches."(No/No)
publishing a private email conversation without letting the other party know and agree on it upfront is a no-go for me.
This is a really good point Jens I am ashamed I didn't think of that sooner.
dev.to has come to resemble long-form Twitter enough already without pushing it further toward that abyss, without egging on their "publish screenshots of my side of an extremely private conversation get internet sympathy" pattern here.
Thanks for posting your side. The test does seem a bit much. Being that you expect most candidates to change countries, I understand some of the consideration there.
I do want to point out: if properly configuring the Django admin interface was necessary to pass the test, it should have been mentioned in the requirements. Especially when considering workers from a different culture, such an important requirement being unstated seems like a landmine.
Side note: Requiring deep knowledge of a specific framework seems like a trap for your company long term and limiting on your candidate pool. The time that you saved using a framework now has to be paid by new employees knowing "what's going on behind the ORM curtains" (plus product knowledge) in order to work on your product. As well as probably restricting your design choices. The fact that it so thoroughly influences your hiring practices should be concerning, IMO.
In any case, this seems like a bad fit for Yaser and your company, so it probably worked out for the best.
Using the Django admin is not a requirement but it could fulfill most other requirements without the candidate needing to code their own frontend and views. Why do more than requested. As some other comments already pointed out: this is also something you would expect later on. If the task is to cross the ocean, you don't need a QE2. A Comanche or whatever other transatlantic vessel is fine.
Please excuse if that sounds harsh - I just don't know any better words in English: I don't get the second part about the framework.
We're almost exclusively using Python and our two largest apps are built in Django. Why should I exclude that framework from our search parameters?
"what's going on behind the ORM curtains" - these questions are pretty simple if someone at least cares a bit about how a database works and what the ORM abstracts for them. IMHO it's not possible to write performant applications when you don't know what the framework hides from you.
Thanks for the wishes - they already worked out.
This week we hired a developer from Colombia - and he's the happiest man on earth right now. And so are we.
Besides the problem, as an entry-level Python back-end dev tasting Django, I can't talk much about this.
Either way, I have experience with other languages and I don't find this extremely hard. I think what complicated the scenario was trying to get beyond requirements with front-end.
Sharing the private conversation was not right though I beneficiated from the feedback provided by the CTO.
I wish the best of luck for you in future applications, but I also understand the company due to the reason why they are so cautious when recruiting.
// , “It is not so important to be serious as it is to be serious about the important things. The monkey wears an expression of seriousness... but the monkey is serious because he itches."(No/No)
Alright. It's me. The "bad" man on the other side of the email conversation.
I was struggling with myself if I should reply to the post at all because
To find a way for myself, I don't want to get into any of the details of the posting itself.
But I'd like to talk about motivation.
In my reply, I will focus on our way to evaluate and handle applications and why we are doing so.
Why are we doing this at all?
We're advertising our job offering world wide. Therefore we receive hundreds of applications a month.
As you can imagine, we need some kind of differentiation/filter. Is a candidate good or not? How can you tell?
We decided to standardize our application process and try to be as transparent as possible right from the beginning.
Our job description already states the main technologies required to fulfill the position. Python, Django, RDBS, HTML/CSS/JS are hard requirements. Celery, RabbitMQ, Sentry etc. are a huge plus.
However everyone can claim knowledge of these fields. CVs usually are full of fake details. People listing technologies they just slightly got in contact with.
Our approach are multiple steps:
Moving for a job is a huge change. We believe that both sides need enough time and enough insight to make a proper decision. We don't want to make anyone move from a foreign country to Germany when we're not 99% sure that it will work out.
After each of these steps, we have a commitee of people making the decision if we should continue.
The test task is evaluated and judged by the senior staff, after the workshop the whole team decides. The decision to continue must always be unanimous. If only one involved person has doubts, we stop the recruiting process.
Why exactly such a test case?
Let me start with an open question to everyone reading the text: What would be the alternative?
How can you get to know what someone's really able to do?
This is our biggest question during the recruiting process.
Most of our applications are coming from outside of Europe. Thousands of kilometers/miles away. Even if that would not be the case. A long interview or an onsite workshop at this point would cost the candidate as much time as the test case does.
We're doing the same test case with slight variations over the last few years. It changed from virtualbox to Docker, from Python 2 to Python 3, the API was added etc.
We never got any bad feedback until this posting came out..
Please ping me if you know a better and faster way to tell apart people who can fulfill the job and ones that don't.
What feedback to give?
Ryan already pointed it out in his reply. We're trying to be as open and give as much feedback as possible.
It's always people involved. Humans made of flesh and blood. With hearts and souls.
Even if we reject someone, we want to treat them with respect, give feedback on why we made our decision and what someone could change and learn in the future to compensate. Give them a chance to grow.
Treat everyone the same way you would like to be treated yourself!
I know of US companies that don't give any feedback at all because they fear to be sued or will be confronted with any other kind of resistance. This is not how we want to be remembered.
Why not just try?
Imagine living in south america. Moving to Europe will be a huge change and huge challenge.
We're not happy with the idea of relocating someone here with serious doubts if it will work out.
What if it doesn't? Depends on the visa your embassy will assign.
Usual working visa -> they would basically have to leave Germany right when the contract ends
EU blue card -> better but still only six weeks to find a new job or leave the EU
I would not be able to arrange that with myself.
We fortunately only had to terminate one contract during the probation yet - this was one of the worst days in my life. Not because it wasn't justified, but because we were ending the dream of someone!
Every story has two sides. This was ours.
Connect the dots. Let me know your feedback!
Best, Jens
This.
You literally filter for most desperate people.
I'm glad everyone can hear the other side of the story. Your reasoning and process make complete sense, especially for international candidates.
I'm not sure why everyone is jumping to unwarranted employer-bashing. The assignment does not seem out of the realm of possibility, especially for an experienced candidate. It isn't doing a full project for the company that you are not being paid for, the value of this project is assessing a candidate, not putting it into production. I'm sure their developers are more than capable of building this, they do not need to outsource it to interviewees. I do not know too much about Django, but breaking down the project seems like:
If you are experienced in the language and framework and starting a brand new project, does that take days?
I'm not sure why there are so many dismissive attitudes on performing coding challenges or a demand to be paid for doing them. I find this method to be much better than white-board coding or trivia questions that aren't representative of a good candidate. This method is a better representation of what you will be doing every day (plus you can use any resources you like and are encouraged to do so), so why not interview candidates that way? If the project is massive, I would understand, but I don't feel that this one is.
Thanks, that's quite precise.
(4) In Django you don't even have to implement a frontend. There is a builtin admin interface which can be easily configured and would fulfill the CRUD requirement.
Exactly, talking about stuff we don't know is just BAD!
Their "senior" did the task in 6 days:
github.com/vpotter/RHTest/commits/...
What's your take on that?
I will only answer on these claims because you're talking about a non-involved third party:
This task had an additional requirement to implement an Angular frontend for someone who never used Angular.
The candidate was a personal reference and we had some extra agreements with him on that part.
Also commits spread over multiple days don't mean that this time has been spent. Most applicants have at least one job and a family. We don't expect them to finish the task within a day just because we ask for max. 5 hours of their time.
Please don't assume anything you cannot know for sure.
I can't comment on processes I'm directly involved in. But just to give you some hope, I'll just say that it is possible to apply DevOps / kanban styles of reasoning to this, to the point of a single day process from initial contact to structured interview to hire with very, very minimal cost of time to the candidate within that day.
Haven't personally seen ways to deal with the time zone thing, but I've heard rumors of good things in that area too.
Would love to hear details about streamlined application processes.
As this post is quite old yet, we've since heavily revamped and automated our process and test.
The application test is now using a scaffold and is hard limited to 2 1/2 hours.
Sorry to resurrect a dormant post, but I liked seeing the other side to this.
I won’t comment on whether the test was onerous or not. I’ve spent a week on programming tests before. I did when I really wanted the job and didn’t when... well, I didn’t. I’ve spent multiple weeks navigating through multi-stage interview processes only to not get an offer. It sucks, and it hurts, and it really sucks. But you could have reapplied at a later date... until you posted this.
After a decade as a hiring manager I understand both sides of the resume better than anyone that hasn’t done the same. I’ve seen it all; unacceptable people get hired for unacceptable reasons, and acceptable people not get hired for unacceptable reasons.
But whatever you do, don’t post it online for potential employers to find, and learn to move on.
Yeah this is the most reasonable part of the thought process where a lot of the hiring anti-patterns originate. Beyond hiring, to any market selection process.
Aside from antagonistic people like me (or at least like I was a few years ago), people aren't going to respond "No." to a job post.
So you don't see all the people who pre-reject you.
Just keep in mind who's filtering you, and that you will often not see the negative results. Even if some change to the hiring process bumped the rejection rate by qualified candidates, how would you know?
Did you know that there's often an inverse correlation between available time and the factors that create demand on it (competence, grit, hard working attitude, customers first)?
Sorry but I don't get your proposal.
Oh, no proposal in that one, just useless grousing.
Thank you for posting your side of the story. I would have sided with the author from just the article, but he lost my respect by posting private conversations on the comments. Also for continuing to argue in the comments. I think a nice tall glass of humility is overdue on Yaser's part. Sucks that he wasted so many days on a project like this - maybe there could have been more timely feedback, pair programming etc to avoid this.
I came to this post from the newsletter expecting a totally different vibe. I thought this was going to be a post about being humble because we're all mediocre, and that there's always someone better than us. On the contrary, the author seemed to get really bitter about being rejected...
No worries - we learned our part on it.
For future tests, we will let the applicant know that we expect them to stop after a maximum of five hours - no matter how far they've got. After that we should have a look at the implementation together. Maybe a video call to discuss it.
And we will be more clear on what we don't expect.
As long as we don't specifically ask for it, we don't expect a single page application or a deployment on some cloud provider.
Thanks for the feedback.
Firstly, thank you for stepping forward & joining the discussion - and for keeping it professional.
I have no stake in the "game" but since you asked for alternatives...
You say each step has to have a unanimous decision, yet no-one had concerns when the email to the CTO had "gotta" and emoji etc? You missed an opportunity for early rejection there, and with hundreds of applications per month, I'd be taking everything I could to reject early.
Now, with hundreds of applications per month, and the whole team discussing each stage of each applicant, how do any of you get any work done? I know I'm deliberately exaggerating the point, but surely a select few can make the decision at each stage?
We also hire internationally, but I think we have a radically different approach (even though we use resume, phone call, tech test and Skype call before a flight). Successful candidates also get 6 months accomodation & food paid for by us, and we pay the costs of relocating in the first place...
Our tech test is significantly simpler than yours (basic CRUD application with maybe 7 requirements). Senior Devs can complete it in an hour & change, and it's done that way, because sometimes we choose to do the test at our office, and we can lend the candidate a laptop of they like. Juniors are allowed longer, or we simply skip the tech test.
When we receive the test answer, I don't look at the code, at all. I do look at the test coverage report, any comments in the code, and the commit history (one big commit at the end equals a rejection just the same as 400 commits an hour).
The point I'm making here, is that the tech test is looking for aptitude... If they already know the answer & hammer it out, good for them, they'll be highly productive. If they struggle & try things and back track a few times - I get to see how they think, if they're capable of learning etc.
A good developer should, in my view, know when it's ok to Google & read stack overflow. They don't need to know the way we work, or the depths of any frameworks we use - that'll come in time with the right attitude.
To each their own, though I don't envy you.
Thanks for your reply.
No one involved in our recruitment process is an English native. It's our second or even third language.
We'd like to start with a feelgood settings for our applicants. If that means using shortened words and emojis, that's fine - we will use them later in Slack too.
Not all of the team is involved in every stage of the recruitment.
We can already reject a big share of the applications based on letter of intention and CV.
Since most of our positions are on-site, we expect applicants to think about what it means to make such a move. E.g. expected salary in Indian Rupies for a German position is a direct rejection. I'd guess that only 20% get to the three ORM questions and 5% will get to the test.
The senior staff comes in at the test implementation and the whole team during the on-site workshop which happens at most 2-3 times a year.
Your approach sounds great. But also costy. We're still a relatively small company overall with a dev team of around 10 people. We just cannot afford getting people on-site for a workshop and then reject more than half of them. Most of the workshops have to work out or I'm running out of budget :-)
Same for the learning part - I cannot hire someone on a regular or senior position because they know the language but then have to learn the framework for half a year.
I'd really love that to change over the next few years.
But if you hadn't replied, we'd have no idea who you are, so it would make no difference whatsoever that he published a private conversation. That said, you make some fair points about the coding challenge.
It's unfortunate that this conversation seemed to escalate the severity of what was a pretty tame post. The emphasis of Yaser's post was essentially for one to accept one's mediocrity/less-than-greatness (if one feels mediocre/less-than-great). His only actual criticism of you and your company was that your bar seems unrealistic; it's certainly a fair assertion given that such a judgment is highly subjective (i.e., there's no right or wrong about how realistic your bar is -- it's just opinion). But as the comments started flowing, some of Yaser's comments showed that he was, in fact, more bothered by your rejection than he claimed in his post... and there's nothing wrong with him feeling that way, though, again, we'd never know if you hadn't replied.
I certainly don't fault you for your interview process -- you have to do what you think is right for you, and it appears you and your team put a lot of thought into it. But I still don't get why you replied and put so much effort into this comment section when none of us could possibly know who you or your company were.
Best of luck with your new hire (I'm not being sarcastic; I mean it).
Sounds like the whole reply is to justify:
Why we tell people to work for us a whole week, then we tell them: "tl;dr no"
Wrong is wrong... regardless how much justified.
Be realistic, Jens!
No one would like to work in a place and treatment like that.
You can see what people are saying in the comments here, it's not just me.
Ah, in case you wanna see some better hiring ways here is a good article.
I don't wanna go back and forth on this with you... nor do you.
I think did my best; unfortunately, you did not.
This is a really good point Jens I am ashamed I didn't think of that sooner.
dev.to has come to resemble long-form Twitter enough already without pushing it further toward that abyss, without egging on their "publish screenshots of my side of an extremely private conversation get internet sympathy" pattern here.
Thanks for posting your side. The test does seem a bit much. Being that you expect most candidates to change countries, I understand some of the consideration there.
I do want to point out: if properly configuring the Django admin interface was necessary to pass the test, it should have been mentioned in the requirements. Especially when considering workers from a different culture, such an important requirement being unstated seems like a landmine.
Side note: Requiring deep knowledge of a specific framework seems like a trap for your company long term and limiting on your candidate pool. The time that you saved using a framework now has to be paid by new employees knowing "what's going on behind the ORM curtains" (plus product knowledge) in order to work on your product. As well as probably restricting your design choices. The fact that it so thoroughly influences your hiring practices should be concerning, IMO.
In any case, this seems like a bad fit for Yaser and your company, so it probably worked out for the best.
Best wishes to everyone.
Using the Django admin is not a requirement but it could fulfill most other requirements without the candidate needing to code their own frontend and views. Why do more than requested. As some other comments already pointed out: this is also something you would expect later on. If the task is to cross the ocean, you don't need a QE2. A Comanche or whatever other transatlantic vessel is fine.
Please excuse if that sounds harsh - I just don't know any better words in English: I don't get the second part about the framework.
We're almost exclusively using Python and our two largest apps are built in Django. Why should I exclude that framework from our search parameters?
"what's going on behind the ORM curtains" - these questions are pretty simple if someone at least cares a bit about how a database works and what the ORM abstracts for them. IMHO it's not possible to write performant applications when you don't know what the framework hides from you.
Thanks for the wishes - they already worked out.
This week we hired a developer from Colombia - and he's the happiest man on earth right now. And so are we.
Besides the problem, as an entry-level Python back-end dev tasting Django, I can't talk much about this.
Either way, I have experience with other languages and I don't find this extremely hard. I think what complicated the scenario was trying to get beyond requirements with front-end.
Sharing the private conversation was not right though I beneficiated from the feedback provided by the CTO.
I wish the best of luck for you in future applications, but I also understand the company due to the reason why they are so cautious when recruiting.
South American and Eastern European devs are seriously underrated. Glad to hear you're taking part in changing that.