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?
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
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.
Hi, I am currently in the process of applying to front end developer jobs focused on React. How do you suggest I prepare for the interviews from your experience? Thank you!
I'm currently interviewing frontend developers for React jobs. There are a few things I look for:
HTH!
Maybe a typo, but you can't use hooks in class components. Or maybe you mean making lifecycle methods with hooks in functional components?
I love your second test, that's great.
Indeed, that wasn't clear - what I look for is for candidates to be able to take stateless functional components and implement functionality using hooks. Many immediately convert to class components in order to use lifecycle methods.
I'd say it's good to practice some questions about libraries that are usually used, for example React Router, Redux, redux-saga. Also prepare yourself to answer the more popular questions like: What is the difference between the Virtual DOM and the DOM; What common patterns are used and why (HOC is one of them).
Maybe they'll also ask about the lifecycle methods of a component, so they might ask "Can I make an HTTP request inside a component's constructor"?
Some questions to keep in mind:
render()method fromReact.Componentreturn? (this shows that you know the difference between a React component and a React element)I'd advise that you look up React Hooks if you haven't yet. That might be a topic they want you to know.
Here are some resources you might find useful:
Thank you for taking the time to reply to my comment! I will definitely check these resources out and make sure I know the questions mentioned for my next interview. Thank you!
Agreed. It is kind of silly that companies struggle to find personnel, and at the same time still expect developers to do these kinds of tests. It is an employees market, the employee/developer has more leverage these days. So either offer to pay them an hourly rate for making a test, or don't ask them to make one.
Best answer ever!! Not to comment on the topic itself (that would be a big post), but I really hate programming for free (unless when I am in the mood for it, which is not often). So I get really anoyed when they ask me to code something for an interview. And when they ask for software you wrote, its like "I cant send you software I wrote in another company, major breach of contract!" Plus, almost all the software I developed professionaly was in a team, so the code isnt really mine, but also from others and its not nice to take credit for others work, nor it really shows that you did a good job, only your team did a good job.
I agree, I dont do Puzzles nor Tests(?).
Really sometimes are so time consuming you are better using that time to interview with others that wont require such things plus the redundancy of that increases.
I normally do not like them.
They are stressful, unpredictable and sometimes plain silly (like playing with words).
But they offer a good insight in the company itself.
Let's imagine a company requires you to do a small assignment.
The level of difficulty is a 9/10, the code has no real life value, and the tech asked you to use is outdated.
This would help you a lot raise some green, or red flags about the company.
Also, even tho I don't like to admit it you will encounter coding puzzles a lot during development, so studying them early will help you in the long run. Last but not least if the company is a really good one and this was their only drawback I would sacrifice my time, once, just to be part of that company.
The problem resides when the job application is for a senior position.
If I would be in a recruitment process for a senior position with a lot of experience behind my back and they ask me coding puzzles compared to advanced, high level overview of things I would immediately stop the process.
For me, it all has to do with how much time I need to spend on it versus how much I want to work for that specific company, and the challenge of the puzzle itself.
I can appreciate how difficult it can be for management to assess the level of a dev. But having other devs in an interview room will often be a lot more helpful than reading code that may or may not have been written by the applicant.
Starting to feel more and more like this. At first I felt like crap when I failed my first coding interview, immediately went to studying more. I thought maybe if I perfect my knowledge of coding puzzles I'll unlock some next level of coding mastery. Now it just feels like being petty good at solving 5000 piece puzzles or doing Sudoku. Pretty cool but not very useful.
Pro tip: "I was not aware I was interviewing for the linked list development team" is not a recommended response to these sorts of questions. 🤪
Worst case of this: prospective employer sends link to test. The position is for .net/c# work. The multiple choice questions are all Java. The coding "problem" is: reverse a string.
The environment they provide takes full screen exclusive mode and is utter garbage. You cannot use reference materials. Tabbing away exits the site. The coding question is literally one line of code. But since the garbage ide didn't provide a stub you need to type all the surrounding console app goo rather than just tabbing over to VS and doing it there. On tyo of all that the multiple choice questions conflated various CS concepts.
The best case? A doc with an assignment. Exercise 1: implement FOO, exercise 2: describe how to test FOO. Get bonus points: implement and test all of it, provide solution package to hiring manager. Followed by practical questions on a white board. Iterative and conversational. Why did you do X? How would you test Y? What happens if you do Z?
I consider it hazing at this point. It's far from an accurate representation of what we do on a daily basis for most jobs. If you're sitting there writing algos all day, maybe... In most cases that isn't the case.
I also noticed those types of puzzles are usually supported by people who learned that way, again not fair for those with a different background.
I spend a lot of my time helping people get into freelance and I often need to tell them don't allow people to vet you like they would an employee. Defeats some of the best reasons of being a freelancer.
Hhhmmm.
As senior web dev and sometimes project manager, i would say it depends on the test but i can for sure tell you accurately that this tests doesn't represent real life problems, at least not at all.
The companies that use this tests systematically are getting people that know the theory very well, people immersed on algorithms that will rarely fit on a real project, this is not the same profile that those who fit in well structured logic for real purposes.
For example if i want to hire people to develop an e-commerce, the test-aware profiles will tend to perform over-engineering on it, making it less maintainable, adding complexity, just because they wasted their time looking at those pretty complex algorithms just because they think it makes them better devs (hey, google exists and there's tones of places where to find this approaches).
If i ask devs to write with their own words how to deal with order-invoice cycle and why, it would be more accurate and I'm getting answers on a real project, then i can figure out which dev fits more (simple but effective logic etc). They are answering things that makes sense like the model and logic behind the specs i set in a paper, which can be prettily a simplified approach i have on the project for what i need to hire people.
In the past i found myself on interviews that was based on a logic test, others that made me deal with a CRUD cycle consuming an API with companies own framework (WTF), others that made me literally an exam on DB queries and algorithms that obviously i never used since i was a student...
Curiously those interviews where on the same companies that are crying on linkedin to hire people and aren't capable to figure out why devs aren't knocking on their door. This was my experience of the last 10-12 years. Get your own conclusions.
Couldn't agree more. For every job that does this there's one that doesn't. The time I waste on one of these tests could be better spent with my family or on side work that pays.
As mentioned elsewhere in the thread, it's a worker's market in software development and these employers are bemoaning lack of talent. Employment law is written in companies' favor. It's easy to fire someone for no reason, let alone incompetence. Paper trails and 3 strike rules aren't law. It doesn't help software teams when HR rules out candidates because they never considered writing an algorithm to calculate prime numbers. I find an interview with a software team member generally can determine if a candidate is qualified quicker and more accurately for both parties anyway. Tests are just a way to keep dev's from spending time in interviews.
It's like making a surgeon do a test on the Operation game from 80s. He could be excelling at that or fail, in both cases it won't be the actual working conditions.
I think it's better to ask main feature of the targeted language. I once interviewed a programmer and he didn't know really what was Javascript promises. If he already did know that then I would have asked question of internals (event loop, garbage collection, etc.) That's way more accurate than asking him to do an algo question.
Not every developers do need to produce very performant code and it's not making them less good.
Nowadays also if performance matters, the solution might be outside of micro optimizing a few lines to maybe use like Rust or maybe the solution is to use gRPC for a faster network throughput, etc.
A good dev learns quick.
I'll do tests, if I have to, but the problem I see, is that the tests may be more interesting than the job :P
Test: do algorithms and puzzles!
Job: do CRUD on MySQL...?
It depends on the type of 'test'.
If it's an automated test scored by a machine that can't tell maintainable code from spaghetti, testing knowledge of algorithms with no relevance to the job or project you are going to be working on then yes, I can see your point.
But if the challenge is well constructed, involves solving a problem you might encounter during your day job, is reviewed by a human (or humans) and assesses problem solving skills, code quality, maintainability, solution design and things such as whether the developer wrote tests - and most importantly the developer receives feedback after the review (as opposed to a binary pass / fail) the I think they have a place in the hiring process.
The reality is you are never going to hire someone without assessing their skills, code challenges offer candidates the opportunity to show off their skills in the comfort of their home, without the need to attend hours of interviews, scribbling all over shite boards and being grilled by a room full of engineers who would rather be working on shipping their current project.
Yes - I am biased :) But I do think they have a place, IF they are well constructed.
Except programmers get hired without a degree all the time. That's why there's these tests
The online tests are naff but we needed something to filter candidates as we got burned, badly!
We interviewed a chap and he was great, we put him on site and he was horrific. He was declaring variables outside of the class and checking that (with build errors) into master - he broke the build 5 times in one day, and even didn't get the problem when confronted.
That was so embarrassing in front of the client.
So we introduced a tech test. It's in a real ide of their choice and it takes (in c#) 45 mins. And I get folks forget stuff under pressure so we give a steer early on, help with little code bits (as Google would) and we ask questions on design choices at the end. Those design choices reveal so much more than any theory.
This is the unpopular bit: because of this test We have caught the chancers - two folks claimed to be architects but we abandoned their tests after 10 mins.... Think : new project, first thing you do is get the packages or even create some folders or a class for anything... They were reading the menus. They wanted £85k salaries and clearly never used VS.
My point - I'm hands on technical and I recruit and I'm busy. I need something to remove the chancers from my process. Hands on is the only way to know for sure.
I'd say dismissing them wholesale is probably shortsighted, there's a type of them that are bad (aka can you look up an algorithm and implement the pseudocode, which is also something you don't tend to do often), but there are plenty of good problem sites out there that will give you a lot of good practice at the basics. Being able to think about a problem and how you want to solve it and implement it without hesitation or running into basic issues is both valuable on the job and in interviews.
Coding puzzles would be important if the work you're doing is creating coding puzzles. We don't rise to our expectations, but fall to our training and I don't train to complete idiot puzzles.
Yep. Bullet nicely dodged.
I jump through hoops for no-one's entertainment.
This happens when HR has no clue about what the term "software engineer" means.
I fucking love code puzzles! But they totally doesn't correlate with code quality. It feels more like solving a Rubik's cube.
Do you care if the surgeon cheated to get that degree?
Puzzles and other programming tests are annoying and typically useless. If you have been programming more than 5 years they are also insulting.
I would probably record some twitch session to show that I can actually code. Meanwhile I could say that I’m learning with Jesse Liberty on Udemy ;)
Degrees are an entirely different conversation.
What we talk about is that people show sufficient qualifications to perform a job but they are required to do tests.
The needs of content have grown with/ahead of the hardware! Performance is still important.