Many companies ask perspective Software Engineers to complete a programming challenge as part of the hiring process. I am not a big fan of timed / in-person challenges for 2 reasons; First, they are a little too artificial and don’t reflect what would happen on the actual job. Second, and most importantly, they don’t offer the chance for the candidate to shine / go above and beyond.

Being a technical person I am often asked by some manager to review an applicants submission even if they aren’t joining my team, almost all applicants make “simple” mistakes. So here are 10 tip tips to help you get that job!


Tip 1: Do what is asked!

First and foremost, do what is asked of you!! In the last 5 days I have reviewed 2 potential candidates submissions for Senior Software Engineering positions. However, both of them failed to follow the instructions! Pretty much if you can’t follow basic instructions you are finished.

This is the 2nd question, it’s easy to make them feel comfortable and has multiple right answers,

Q2. Create a function that can take any number of parameters and returns a String that is a comma separated string
e.g. myFunction(“car”, “bus”, “airplane”); // returns “car, bus, airplane”

However, both applicants failed to answer this correctly! One of the them used alert() to print out “carbusairplane” and the other looped through, alerting for each iteration! Heck, if they had created a function to statically return “car, bus, airplane” I would have given them full points for being ballsie! The question clearly says to return a string, no mention of alert(). Neither got the job.

Moral of the story, follow the instructions!


Tip 2: Be expressive, add comments

As it is written, the reviewer will not know what you are thinking unless you write it down. If you are asked to rewrite an inefficient function, don’t just rewrite it, tell me why it was inefficient! How many issues did you see? Is there any inbuilt functionality of the language that provides the same functionality?


Tip 3: It is an opportunity to show off!

Go above and beyond, when appropriate.  If a question asks you to create a small application, do everything that is asked of you (most important requirement), then add additional functionality  It doesn’t have to be extensive, but show some enthusiasm and passion.  If you are asked to implement a REST API that would allow the Listing (GET) and Adding (POST) of products, then go a step further and add Edit (PUT) and Delete (DELETE) functionality.  Just remember, on simple questions, keep your answers simple, this tip only applies to the larger/longer questions.


Tip 4: Read between the lines, of the job description.

At least in my examinations I never ask candidates to write Unit Tests, this is intentional. While I won’t fail you for not doing something I haven’t specifically asked for, every person who went above and beyond and included unit tests in their work I’ve given the thumbs up to. If the original job posting made multiple references to TDD, BDD, Unit testing etc… it is a good idea to include them (at least for the larger/longer questions). While I won’t fail you, I know some of my colleagues would.


Tip 5: Include the question with your answer!

I don’t know how many times I’ve had to open zip files with folders, that contain numbered text files which in-turn only have the solution text. We have multiple tests for different jobs/positions, I don’t always have the test text in front of me. Make my life easier, include the question text as well. It will give a great first impression.


Tip 6: It is perfectly ok to ask for coding standards/rules before you start.

Idiomatic code is important for large projects, it is always a good sign if a candidate asks for this. If you don’t feel comfortable asking, then why not use an existing standard and mention it in your comments.


Tip 7: Demo, if possible.

If one of the questions was to build a small Web application, then host it somewhere! Let me see it in action. One candidate I reviewed got the job solely on this point, as it clearly separated him from the others. If you are building a Windows application it is also a good idea to include screen shots, just in-case the reviewers computer does not have some dependence needed to run your app.


Tip 8: GitHub.

I always like getting GitHub links, it shows you are active and participate. Just remember, if the Repo is public, do not host the questions, only the answers, otherwise you could upset the company (it takes a lot of effort to make a good test).


Tip 9: Get your code reviewed before submitting.

Unless your exam explicitly states otherwise, ask a colleague or college buddy to review your code before you submit it. In a real job all your code would be reviewed, so why should this be any different? It shows maturity and openness, which are critical for members of a high performing team. Just don’t be foolish enough to ask someone else to do the test for you, you’ll easily be found out and have burnt a bridge.


Tip 10: Reviews are people as well!

The people who are reviewing your code/submission are people as well. It is ok to use to some light humor, but keep this restricted to the data rather than the code. It will probably put a smile on the reviewer and make you stand out more, just don’t go over board.


var inputData = ["Han Solo", "Luke Skywalker", "Chewbacca", "Lando"]; // Data set is nerdy 
var result = sort(inputData); // The function name and variable names are relevant and well named, excellent!

If you start messing with the code, you’ll be dumped on the spot:

var rebelScum = ["Han Solo", "Luke Skywalker", "Chewbacca", "Lando"];
var result = starWarsSort(rebelScum); // This is unacceptable!

Leave a Reply

Your email address will not be published. Required fields are marked *