re: Unpopular opinion? I don't do puzzle coding tests. VIEW POST


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.

code of conduct - report abuse