So, today, as part of a screening process for a freelancers agency, they sent me a puzzle coding test. I respectfully declined and said that probably I'm not a good fit.
What is your position?
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (62)
In my opinion these tests are not an accurate representation of a coder's abilities, however I think coders should learn this, and get good at it.
As a developer I started running into these tests and not doing well on them. So I started practicing them and getting good at them so I didn't fall on my face in an interview. I learned a few things about algorithms that helped me be a better developer.
From a manager standpoint, sometimes I would give these out as well, however I found good programmers who did poorly on tests and vice versa. So I didn't base my hiring on how they did, but rather just looked at how they think. How they solve problems.
I think every developer should at least practice and try to get good at these kinds of tests. There are things you'll learn in the process that will help you as a developer.
What's perplexing is when companies have you do multiple timed coding exercises, remotely. (I'm looking at you, Uber.) This is grade-school-style regurgitation of algorithms, not a window into process.
I agree with you that they're great for stretching your abilities, learning new patterns, and becoming a better coder. I've gotten better from them for sure, and have a long ways to go yet. But whether they're a good assessment depends on how they're administered.
Exactly, I shy away from the "they failed the test they suck" way of thinking. I've worked with many developers who under pressure with a whiteboard can't produce squat, but sitting in front of their machine coding can work miracles. It simply isn't a great go/no go indicator for someone's true skills.
Yeah, I have thought that probably would be a good idea to learn a little bit about it, but then, I have like a million more exciting things to learn and practice that I could use in the real world
I wouldn't avoid it completely. To this day I will still take some of the tests for fun, and there have been "aha" moments for me when I realized a better way of doing things while doing one of those tests.
I understand not prioritizing it, but I wouldn't avoid it altogether, they can be quite fun.
Tell me how to memorize algorithms will make you a better developer please.
You became a better developer when you know a single language and framework very well as you can translate it to every programming language in seconds, for example i know that PHP explode function is split in Java and in javaScript, but if i have to work with C# i could visit google and ask "explode C#" or "split C#" and I'll get rid on it in less than a minute.
You become a better developer when you have to deal with complex business logic so you need to figure out the most simple way to reach the specs and ending with a dynamic, changes-aware and maintainable piece of code.
In my experience algorithms doesn't fit on this, and will rarely fit on a real life project, at least for the major working places. It could be different if you attempt to work on Google, Amazon, Microsoft, Apple, IBM or similar, but there are tones of companies with IT department that will never use complex algorithms to deal with predefined tasks.
You use algorithms every single day, whether you know it or not. Understanding them and practicing problem solving makes you better. Just like going to the batting cages makes you a better batter, even though it's is a human pitcher at a baseball field.
Knowing the principles of algorithms and how different algorithms for the same problem compare to each other is one thing, and expecting you to fully flesh out the details of an algorithm on a whiteboard or a piece of paper under a timed exercise is a completely different thing.
Some apparently very simple algorithms may prove tricky to implement.(Have you ever tried implementing binary search? :)) Another point is that we can't expect someone who's seeing a problem for the first time to easily map it to commonly known problem that has one or more specific algorithms to solve it. We as developers all know that even in our daily job sometimes it might take us several hours(sometimes even when we think as teams and not only individuals) to come up with a solution for a certain problem; this's happening even with problems and domains that we're very accustomed to during our daily work. We shouldn't expect better with problems unknown to interviewees.
Interesting thought on the origin of these tests. It may also be a leftover from a bygone era. Nowadays software development is mostly a matter of gluing preexisting software / pieces of code together. If it's difficult somebody probably did in in OSS for fun. I expect things were different 20+ years ago.
Perhaps it's not about how you answer the question but how you approach answering the question. If you know the answer, great! If you can figure it out, cool! If you can't figure it out but you conduct yourself with probing questions and discussion, that might be what being looked for.
Oftentimes we are faced with problems we don't know the answer to and have to figure it out.
Same goes with me. I don't understand why competitive programming is being used as a measure to check programming skills in screening processes.
It doesn't seem to test what we need in industry/real world applications.
Because HR departments and non-tech managers are bad at understanding dev work.
This is the real answer. The prevalence of the badly broken tech interview is gatekeeping power play. It exploits the developers original sin of 'imposter syndrome'.
We ask for examples of code that show a candidate's ability to write work quality code. If they have none, we provide a coding challenge. Our challenge is a small project with a primary function of interest. We provide guidance that our company writes automated tests and uses incremental commits with meaningful comments.
We understand that this is a barrier to entry, but asking us to hire a candidate without some proof of ability creates too much risk of misunderstanding one another.
Getting good at that sort of test helps with interviews at Google and likely other large software companies. Personally though, I ask candidates to either:
As a freelancer, I also declined such requests. I once asked to come in and work with their team, they accepted and we had a great time.
Imagine if these tests were applied to other engineering positions. Why stop there, imagine this kind of tests for any role.
Yes! It doesn't make sense right?
I kind of disagree. Because there are lots of programmers looking for a job without a degree. How would that company know someone without a degree is good enough? I don't know how they would fix this issue
Truth be told, I'd hire a mid to senior level dev with no degree over the same with a degree anytime. Getting a degree doesn't make you a good dev. Having to prove yourself daily for the first few years of your carrier does.
I agree. But how would the company do this without these obviously annoying tests? How would they know which programmer is good enough. That's the point I'm trying to make
The same way every other industry does! Interviews and then if you fake it, you are fired. What is the problem with that?
I kind of disagaree because there are a lot of programmers with a college degree that doesnt know how to program. How would that company know someone with a degree is good enough? I don't know how they would fix this issue
I don't know how they would fix this issue. But I understand why they have the tests. It's too easy to claim you're a programmer
Also electrician, plumber, chiropractor, real state investor, and so on and on. The problem is there is no problem, pretenders are caught and fired. False positives are caugth and fired. Know something? Do you realize you are trying to defend software companies? Why does companies need you as their defensor? Focus on the real problem, not in illusion of fairness.
Nah just wait a few more decades and we'll be "test working a year".
Dont wait a few more decades, just stop by my country Portugal and you'll see people "test working" and "internshipping" for 3, 4 or 5 years (with equivalent salary every year)
Hahaha, yes i forgot about that. seems like slavery repeats itself in every few thousand years.
I am the kind of guy that panic and get nervous easily. Once I took a very simple coding problem for an internship, but failed miserably. I panicked in front of 2 engineers that were watching me trying so hard on a simple problem.
A friend of mine got through the internship screening while I did not.
I told him I had failed and he genuinely thought I would pass the tests easily.
Long story short, I got an internship in another company as a mobile developer with flutter. He worked as a quality assurance making test cases, automation tests, etc with java. He told me work was hard and frustrating. For me, work was quite enjoyable as I really like learning new things. I handled problems that have nothing in common with coding problem tests. He handled stuffs that had nothing to do with the tests he took.
I guess some people just cannot stand those kind of tests, even though they can be just as capable as those who can.
In my opinion, learning competitive programming can be a big lesson for any developer. It may help you to think in a different perspective, while also helping you make optimized codes.
All i can say...
Do you ask your contractor to do a test roofing for you?
I see your point in the 'unpaid' work but I'd be more than happy to prove myself by helping out in real tickets. It would also be a good opportunity for the applicant to find out if (s)he is actually interested in the job.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.