How to succeed at Developer technical tests
This is not an article about cheating or gaming online technical tests but how to approach them to give you the best chance at demonstrating your true ability.
When it comes to technical tests, you should not even consider cheating by copying something in from elsewhere just because, "If I get to the interview I will amaze them by my personality". The employer knows that the tests are not perfect and are usually interested in how you approach a problem rather than getting 100%. If they are looking for 100% then they might not be the best employer. Some sites can also detect cheating so be warned!
You usually have an overall time limit and might be able to view all questions before deciding which to spend time on.
You might be watched by the recruiter/employer and might have constraints like, "you aren't allowed to use Google". You can determine for yourself or ask whether it is a test e.g. so I could use Bing? since this might be part of the evaluation process.
For example, a test might include parsing a string for the length of words and finding the longest/shortest/one with the most vowels. This string might have noise in the form of spaces, punctuation etc. So the solution might be (in pseudo code):
1) Remove noise from input
2) Separate words with the space character
3) Find the longest/shortest/one with the most vowels
You might be given 3 tests (longest word example):
1) TestMethod("Hello goodbye").ShouldBe("goodbye");
2) TestMethod("What good is love?").ShouldBe("What");
3) TestMethod("Another with, punctuation added").ShouldBe("punctuation");
You could create a relatively easy test method to make these tests go green but there are many other edge cases that you should consider. Leading space? Multiple punctuation? Non-ascii character set? Punctuation in middle of word? etc. It is critical that you consider and add your own test cases before submitting the answer. Imagine the conversation with an Employer (if you get that far) saying that you missed an obvious edge case just because you didn't write unit tests - and you are trying to tell them you know what you are doing. Having a test fail that uses a non-ascii space would be OK if you added a comment that states you assume the space character is the only valid space character.
There are a number of reasons that these tests do actually work.
Firstly, they ascertain a broad level of ability. If you finish a hard example and get it correct, this broadly means you are more proficient than someone who only got one test submitted and ran out of time. Someone who is broadly more able than another is likely to be a better employee with everything else being equal, it also speaks to an attitude that someone is learning how to do their job well.
Secondly, there is no point testing you on something as pointless as adding an (already designed) stored proc to a database, which is what you might be doing day-to-day. Adding columns to database tables etc. is easy so unless you are applying for a junior role, those question won't separate good from better Developers. These types of low-level tests are generic enough to work for most jobs and to uncover mindset and ability without becoming too complex.
Thirdly, they demonstrate someones approach and mindset. Use of unit tests is considered a must-have in most decent software companies so if you are not adding them, it doesn't mean you couldn't learn how to, it means you do not currently think along the lines of TDD and some companies can't take that risk with a new hire. You don't agree with TDD? Fine, this might not be the company for you.
Fourthly, your solution itself will show how asbtractly you can analyse a problem and whether you have novel solutions when you think abstractly. Anyone can loop through a string looking for the next word but someone might see it as a type of problem that can be resolved with one line of clever maths; might think of a shortcut to avoid processing the entire input or might see a recursion which would reduce the overall amount of code. How do you learn this? Experience and formal learning. I have coded for 20+ years and there simple solutions to common problems that I have never come-across because I never learned them and don't have a Comp Sci degree.
Lastly, it shows coding style including use of comments (or not). This speaks a lot about mindset, attitude, willingness to disagree with the new employer. If the Employer sees something small they don't like, you might get to discuss it, if overall it looks messy and doesn't show that you care about others maintaining it, you might not even be called back.
You can find plenty of testing sites online that you can use for these types of tests but otherwise, you could get a friend or colleague to invent something for you to get your teeth into. You could have a regex cheat-sheet on your screen ready but this will only slow you down - learn how to do them properly and watch out for catastrophic backtracking.
Understanding that a prime number is only divisible by 1 and itself, is easy but understanding how to determine that mathematically in an efficient way is not. How might you create a prime generator that isn't O(n) in performance? Little tricks like not computing for even numbers etc. might give you some small gains but without understanding a prime sieve or even a lookup table, your code might lose points for its performance.
This again you can play with yourself before you need to do any real tests. Get used to number tricks in programming, in .Net, you might learn the Linq methods that can project a simple idea into a more efficient operation. Understand edge cases, what happens when you use signed numbers and they overflow? Write unit tests to check the edge cases.
These questions are things like: "How much would you charge to wash all of the windows in Seattle?"
The first point to make is that you should know that there is no correct answer! You should also know that if the question is small, it is likely that you must ask questions of the interview: Is there a time limit to wash them all? Can I employ as many people as I want? Do I need to consider the available labour market or can I assume I can employ as many people as I want? Do I need to include the cost of the equipment including depreciation or should I only account for wages? What should my profit margin be? etc. All of these are before I even consider how many windows exist - which is where most Developers would go straight to!
Hopefully you can understand that if you didn't ask any questions and instead started with the number of windows and a rought time calculation etc. the employer might not be very impressed with your problem solving? They also wouldn't want 200 questions and no action so you would need to balance it!
You might not have the right mindset to solve the problem, that's fine. It probably means you wouldn't enjoy your job because you would be expected to do something that you cannot. Could you learn to do it? Maybe, but why should an employer risk that? If you want to get better, get better in your own time. If you want to reapply later then do it. There are tonnes of jobs out there that aren't at the Big 5 and are just as rewarding if not more so.
Unfortunately, there is little regulation in the development world compared to, say, Medicine and Law, which are much harder to qualify in. It is therefore on us to keep our skills current, to learn the basic elements of our craft, even if we don't use them day-to-day. It is this effort which rewards itself in more Career opportunities by passing the technical tests.
Introduction
Technical testing has become more popular as a way to pre-screen candidates for Developer positions to avoid the many cases where a CV or recruiter inflates the true ability or experience of someone and ends up wasting people's time.The right-fit job
The first thing to know is that although you might only care about you getting the job that you want, you should instead think that the employer wants someone who fits the company and the role. The point of the tests and also the interview is not to do whatever you need to in order to get the job but instead ask if you are the right fit. If they really need someone who is PhD clever in Computer Science and you are not, don't try to pretend you are just because it is a cool job. You waste your time and theirs and even cause them to fail because you don't have the right skills - especially if you "nearly do" and are harder to get rid of for that reason.When it comes to technical tests, you should not even consider cheating by copying something in from elsewhere just because, "If I get to the interview I will amaze them by my personality". The employer knows that the tests are not perfect and are usually interested in how you approach a problem rather than getting 100%. If they are looking for 100% then they might not be the best employer. Some sites can also detect cheating so be warned!
What the tests are like
In most cases, the technical tests are a relatively simple to understand problem but one which has various levels of difficulty to actually implement. They are usually evaluated using unit tests and often give you a subset of tests to run your code against. What they don't do is give you 100% coverage of your code so passing the 3 or so helper tests does not guarantee you will pass all of the tests that get run after submitting!You usually have an overall time limit and might be able to view all questions before deciding which to spend time on.
You might be watched by the recruiter/employer and might have constraints like, "you aren't allowed to use Google". You can determine for yourself or ask whether it is a test e.g. so I could use Bing? since this might be part of the evaluation process.
For example, a test might include parsing a string for the length of words and finding the longest/shortest/one with the most vowels. This string might have noise in the form of spaces, punctuation etc. So the solution might be (in pseudo code):
1) Remove noise from input
2) Separate words with the space character
3) Find the longest/shortest/one with the most vowels
You might be given 3 tests (longest word example):
1) TestMethod("Hello goodbye").ShouldBe("goodbye");
2) TestMethod("What good is love?").ShouldBe("What");
3) TestMethod("Another with, punctuation added").ShouldBe("punctuation");
You could create a relatively easy test method to make these tests go green but there are many other edge cases that you should consider. Leading space? Multiple punctuation? Non-ascii character set? Punctuation in middle of word? etc. It is critical that you consider and add your own test cases before submitting the answer. Imagine the conversation with an Employer (if you get that far) saying that you missed an obvious edge case just because you didn't write unit tests - and you are trying to tell them you know what you are doing. Having a test fail that uses a non-ascii space would be OK if you added a comment that states you assume the space character is the only valid space character.
Why the tests?
One of the most common complaints about these tests is that they are irrelevant to what most people do as a Developer. When was the last time you had to find the longest sequence of numbers in an array of numbers? If they are irrelevant, I might do badly at the tests even though I can still do the job.There are a number of reasons that these tests do actually work.
Firstly, they ascertain a broad level of ability. If you finish a hard example and get it correct, this broadly means you are more proficient than someone who only got one test submitted and ran out of time. Someone who is broadly more able than another is likely to be a better employee with everything else being equal, it also speaks to an attitude that someone is learning how to do their job well.
Secondly, there is no point testing you on something as pointless as adding an (already designed) stored proc to a database, which is what you might be doing day-to-day. Adding columns to database tables etc. is easy so unless you are applying for a junior role, those question won't separate good from better Developers. These types of low-level tests are generic enough to work for most jobs and to uncover mindset and ability without becoming too complex.
Thirdly, they demonstrate someones approach and mindset. Use of unit tests is considered a must-have in most decent software companies so if you are not adding them, it doesn't mean you couldn't learn how to, it means you do not currently think along the lines of TDD and some companies can't take that risk with a new hire. You don't agree with TDD? Fine, this might not be the company for you.
Fourthly, your solution itself will show how asbtractly you can analyse a problem and whether you have novel solutions when you think abstractly. Anyone can loop through a string looking for the next word but someone might see it as a type of problem that can be resolved with one line of clever maths; might think of a shortcut to avoid processing the entire input or might see a recursion which would reduce the overall amount of code. How do you learn this? Experience and formal learning. I have coded for 20+ years and there simple solutions to common problems that I have never come-across because I never learned them and don't have a Comp Sci degree.
Lastly, it shows coding style including use of comments (or not). This speaks a lot about mindset, attitude, willingness to disagree with the new employer. If the Employer sees something small they don't like, you might get to discuss it, if overall it looks messy and doesn't show that you care about others maintaining it, you might not even be called back.
The two things to learn
Most of the testing platforms allow you to choose your favourite language but there are two topics that will occur in many tests: string parsing and number-crunching.String parsing
If you want to do well in these tests, you must be proficient parsing strings and as well as the simple methods like Split, Contains, Substring etc. it is almost certain that you will need to use Regex. This might be easy in your chosen framework but in .net, for example, remembering how to use IsMatch, Match, Replace etc. can be confusing without an IDE to help you. In some tests you are not allowed to use an external IDE and this is detected in a number of ways. I failed a test once because I couldn't work out how to use Regex.Replace in C# without the docs!You can find plenty of testing sites online that you can use for these types of tests but otherwise, you could get a friend or colleague to invent something for you to get your teeth into. You could have a regex cheat-sheet on your screen ready but this will only slow you down - learn how to do them properly and watch out for catastrophic backtracking.
Number Crunching
Another very common technical test involves being passed an array of numbers and performing certain operations: what is the largest prime number; what is longest decreasing sequence; how many of these numbers are Perfect?Understanding that a prime number is only divisible by 1 and itself, is easy but understanding how to determine that mathematically in an efficient way is not. How might you create a prime generator that isn't O(n) in performance? Little tricks like not computing for even numbers etc. might give you some small gains but without understanding a prime sieve or even a lookup table, your code might lose points for its performance.
This again you can play with yourself before you need to do any real tests. Get used to number tricks in programming, in .Net, you might learn the Linq methods that can project a simple idea into a more efficient operation. Understand edge cases, what happens when you use signed numbers and they overflow? Write unit tests to check the edge cases.
The Google Tests
You might have heard of what happens when you technical test at somewhere like Google. These tests put fear into people's minds but they should not. In most cases they are not pass/fail, they are instead looking for mindset.These questions are things like: "How much would you charge to wash all of the windows in Seattle?"
The first point to make is that you should know that there is no correct answer! You should also know that if the question is small, it is likely that you must ask questions of the interview: Is there a time limit to wash them all? Can I employ as many people as I want? Do I need to consider the available labour market or can I assume I can employ as many people as I want? Do I need to include the cost of the equipment including depreciation or should I only account for wages? What should my profit margin be? etc. All of these are before I even consider how many windows exist - which is where most Developers would go straight to!
Hopefully you can understand that if you didn't ask any questions and instead started with the number of windows and a rought time calculation etc. the employer might not be very impressed with your problem solving? They also wouldn't want 200 questions and no action so you would need to balance it!
You might not have the right mindset to solve the problem, that's fine. It probably means you wouldn't enjoy your job because you would be expected to do something that you cannot. Could you learn to do it? Maybe, but why should an employer risk that? If you want to get better, get better in your own time. If you want to reapply later then do it. There are tonnes of jobs out there that aren't at the Big 5 and are just as rewarding if not more so.
Conclusion
Ultimately, with all objections aside, these technical tests do generally separate good Developers from really good Developers. The most galling thing is when egos are hurt since we assume that we are good developers so with 20+ years, if I fail the tests, it must be the tests problem right?Unfortunately, there is little regulation in the development world compared to, say, Medicine and Law, which are much harder to qualify in. It is therefore on us to keep our skills current, to learn the basic elements of our craft, even if we don't use them day-to-day. It is this effort which rewards itself in more Career opportunities by passing the technical tests.