Trouble maker and Problem solver ⚙️🔧
Loves simplicity, hates bullshit 💩.
Productivity obsessed, avid learner 🖥🚀
Sport and outdoor freak 🧗⛰
Metalhead 🎸🤘 Father of 2 👨👩👦👦
Opinions are my own
besides the fact that NO, SORRY, NOT EVERYBODY IS A GENIUS, (maybe different, maybe special but not genius) I always loved the quote:
"if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid."
and found arrogant and patronizing when people "judge" a person in all their complexity based on just few parameters.
But I love it only when applied in general or just to the education system.
A kid could be good at Math, and suck at art.
A kid could be good at Drawing and suck at Science.
Both are very intelligent and special kids, teachers should remember them, respect their different abilities and natures. Try to foster where they thrive and support them were they lack.
But.. If we are talking about a specific thing, a specific skill that we are assessing, this quote is meaningless.
If I visit a Music school, and I suck at anything musical, I cannot just say:
Ehi you are being mean, I can't play the piano, but I am special, I am a genius, I can run 100m in 10seconds, and... and.. I was very good at Math too!"
If the fish applied to a Tree Climbing competition, should we really take into account his ability to swim? Or should we, with good reason, consider him stupid for even applying?
I am sorry, but here we are talking about hiring someone to become a Software Engineer, so the ability of coding must be assessed.
We can discuss how, in which ways, with which tools, but a "coding assessment" is necessary.
It might be stressful, it might be timeconsuming, it might possibly weed out valid candidates, but it is necessary.
as everything in Software Engineering, and basically in life, IT DEPENDS, mainly
on the position you are applying for
on the type of coding test
If you apply for a Solutions Architect position, you can't just say: well... I am not good a drawing diagrams and not so good at naming System Design principles..."
If you apply for Frontend Engineer with React experience, you must be able to quickly jot down a component with a couple of hooks.
If you are a Javascript Engineer I expect you to know about Currying and Partial application.
Of course there are loads of stupid companies and interviewers that fail because the apply interviewing patterns that make no sense for their company and daily job. But it is not a flaw of the coding test.
If the job deals with algorithms, performance and really complex low level stuff, you must have a CS background. (be it self taught or official). If the job envolves solving problems with code ( and namely, building some components, and connecting apis and using services already built for the job - be it a library, or a Cloud provider service) way less.
I also had interviews where i was asked to reverse a string or sorting an array without using any native methods.. which is something that makes no freaking sense in a real world scenario. I failed them miserably, but I left without any sense of defeat - either I would not be a fit for their daily tasks, or the company mindset would not be a fit for me.
The point is, hiring is hard ( and being hired too).
No coding test? you might be hiring someone that is just bragging or is good at selling themselves.
CS / Algo-Datastructure Test? you might be hiring someone that is very skilled but has no idea how an avarage day at any gig works ( or simply, they are very good at solving quizzes)
Takehome real life coding test? you might discriminate people that have not so much time outside their working hours).
Just friendly chat about coding and technical questions? people gets stressed during interviews, might be shy, or have speaking difficulties, but still very good at programming.
There is no right way to do that. So in the end, it is really up to your gut feeling, and the company that you applied for.
Exactly my thoughts. No matter what companies will do, always will be someone complaining about the recruitment process. Currently is most visible as the project-based vs test-based check of experience.
This is for me, one of the best answers I have read. Personally, I agree, you cannot be a solution architect and don't know how to create diagrams. I am a "huge" fan of the C4 model.
Furthermore, I agree with the point that if you are applying for jobs working with metal or I don't know nuclear plants, I agree that you must have certain skills. However, the main issue I have experienced in Europe is that I used to have too theoretical code interviews for things you would never use. When I was searching for a job, I never applied for optimizing OSs or building Machine Learning Models positions, and I still had questions of topics I hadn't used in 10 years since I had graduated from CS.
In my first interviews I failed horribly, and I was forced to study things that I don't use, and I already forget again. I still have a crazy sticky note in my phone if I ever need it again with all potential questions that I got that I didn't remember in detail.
I can just add that I'm not against code interviews, in the only company I worked in Poland that was a large corporation, we had technical tests, but they were about a small business case that was related to your future job. We had some CRUDs and other stuff, and you could choose the .NET tech you wanted. After your solution was done in 1h more or less, you will have questions and based on that we proceed. I consider these tests fairer and with more sense.
We avoided extremely theoretical tests where people had no idea about .NET, LINQ, T-SQL, etc. but they knew all sorting algorithms ever, and we focused on the people that our business needs. Sadly, I had seen more comparably sized companies doing the same Quick Sort or related algorithms for unrelated positions that when the times come and you start your job, they tell you things like this one: "You must migrate an entire DB instance on your own for X date." This happened to me, and I succeeded, but not everyone is so lucky.
Disagree: Software Development is about applying Engineering principles and your experience of other projects. Its NOT about memorising code or acing code.
Most Development Work is driven from solving a set of Business problems.
The interview questions should be around “what business problems relevant to this role have you come across, and what did you personally do?”.
The interviewer can probe the technologies and the candidates experience there.
Also if the candidate has a Degree, lots of previous work experience and certifications then why have a code test.
The code test is there to cover recruiters and hiring managers because they don’t know what they want, they don’t understand the role and have failed to communicate to the candidate what the roles about. They end up hiring the wrong person anyway and when that person leaves or is fired the test is used to cover their backs.
I'm a Senior Advocate @ Unity, a Developer Advocate and Software Engineer with 9+ years of development and industry experience. Love just creating stuff and putting it out there!
I think it's interesting because the issue isn't the Coding Tests in their purest form, it may be an implementation problem.
At the end of the day, Recruiters, HR professional, and development teams NEED some way to judge if a candidate is competent. And sadly, just taking a person at their word is probably NOT the way to go 😅
I think you statement really rings true:
There is no right way to do that. So in the end, it is really up to your gut
feeling, and the company that you applied for.
I think it's INCREDIBLY important to trust yourself and know what is best for you and evaluating your skills. For me, it's not coding test but for others it may be.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
besides the fact that NO, SORRY, NOT EVERYBODY IS A GENIUS, (maybe different, maybe special but not genius) I always loved the quote:
and found arrogant and patronizing when people "judge" a person in all their complexity based on just few parameters.
But I love it only when applied in general or just to the education system.
A kid could be good at Math, and suck at art.
A kid could be good at Drawing and suck at Science.
Both are very intelligent and special kids, teachers should remember them, respect their different abilities and natures. Try to foster where they thrive and support them were they lack.
But.. If we are talking about a specific thing, a specific skill that we are assessing, this quote is meaningless.
If I visit a Music school, and I suck at anything musical, I cannot just say:
If the fish applied to a Tree Climbing competition, should we really take into account his ability to swim? Or should we, with good reason, consider him stupid for even applying?
I am sorry, but here we are talking about hiring someone to become a Software Engineer, so the ability of coding must be assessed.
We can discuss how, in which ways, with which tools, but a "coding assessment" is necessary.
It might be stressful, it might be timeconsuming, it might possibly weed out valid candidates, but it is necessary.
as everything in Software Engineering, and basically in life, IT DEPENDS, mainly
If you apply for a Solutions Architect position, you can't just say: well... I am not good a drawing diagrams and not so good at naming System Design principles..."
If you apply for Frontend Engineer with React experience, you must be able to quickly jot down a component with a couple of hooks.
If you are a Javascript Engineer I expect you to know about Currying and Partial application.
Of course there are loads of stupid companies and interviewers that fail because the apply interviewing patterns that make no sense for their company and daily job. But it is not a flaw of the coding test.
If the job deals with algorithms, performance and really complex low level stuff, you must have a CS background. (be it self taught or official). If the job envolves solving problems with code ( and namely, building some components, and connecting apis and using services already built for the job - be it a library, or a Cloud provider service) way less.
I also had interviews where i was asked to reverse a string or sorting an array without using any native methods.. which is something that makes no freaking sense in a real world scenario. I failed them miserably, but I left without any sense of defeat - either I would not be a fit for their daily tasks, or the company mindset would not be a fit for me.
The point is, hiring is hard ( and being hired too).
There is no right way to do that. So in the end, it is really up to your gut feeling, and the company that you applied for.
agreed 100% with you . best comment and answer
Exactly my thoughts. No matter what companies will do, always will be someone complaining about the recruitment process. Currently is most visible as the project-based vs test-based check of experience.
This is for me, one of the best answers I have read. Personally, I agree, you cannot be a solution architect and don't know how to create diagrams. I am a "huge" fan of the C4 model.
Furthermore, I agree with the point that if you are applying for jobs working with metal or I don't know nuclear plants, I agree that you must have certain skills. However, the main issue I have experienced in Europe is that I used to have too theoretical code interviews for things you would never use. When I was searching for a job, I never applied for optimizing OSs or building Machine Learning Models positions, and I still had questions of topics I hadn't used in 10 years since I had graduated from CS.
In my first interviews I failed horribly, and I was forced to study things that I don't use, and I already forget again. I still have a crazy sticky note in my phone if I ever need it again with all potential questions that I got that I didn't remember in detail.
I can just add that I'm not against code interviews, in the only company I worked in Poland that was a large corporation, we had technical tests, but they were about a small business case that was related to your future job. We had some CRUDs and other stuff, and you could choose the .NET tech you wanted. After your solution was done in 1h more or less, you will have questions and based on that we proceed. I consider these tests fairer and with more sense.
We avoided extremely theoretical tests where people had no idea about .NET, LINQ, T-SQL, etc. but they knew all sorting algorithms ever, and we focused on the people that our business needs. Sadly, I had seen more comparably sized companies doing the same Quick Sort or related algorithms for unrelated positions that when the times come and you start your job, they tell you things like this one: "You must migrate an entire DB instance on your own for X date." This happened to me, and I succeeded, but not everyone is so lucky.
Disagree: Software Development is about applying Engineering principles and your experience of other projects. Its NOT about memorising code or acing code.
Most Development Work is driven from solving a set of Business problems.
The interview questions should be around “what business problems relevant to this role have you come across, and what did you personally do?”.
The interviewer can probe the technologies and the candidates experience there.
Also if the candidate has a Degree, lots of previous work experience and certifications then why have a code test.
The code test is there to cover recruiters and hiring managers because they don’t know what they want, they don’t understand the role and have failed to communicate to the candidate what the roles about. They end up hiring the wrong person anyway and when that person leaves or is fired the test is used to cover their backs.
I really like your thoughts on this!
I think it's interesting because the issue isn't the Coding Tests in their purest form, it may be an implementation problem.
At the end of the day, Recruiters, HR professional, and development teams NEED some way to judge if a candidate is competent. And sadly, just taking a person at their word is probably NOT the way to go 😅
I think you statement really rings true:
I think it's INCREDIBLY important to trust yourself and know what is best for you and evaluating your skills. For me, it's not coding test but for others it may be.