Easy fixes for the take home part of your interview
Published: 2022-03-20 20:54:35

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/hioofqiswf6qvs2gibv5.jpeg)
Recently I've been interviewing a lot of people (still find it hard to believe as [it feels like it was yesterday that I was job hunting](https://dev.to/jennyjudova/how-to-find-a-job-as-a-bootcamp-grad-4fg8)). Being on the other side of the interview table has taught me a lot I wish I knew when I was interviewing for dev jobs especially the take home part of the interview.

Take home part of the interview is a common part of the interview process for software engineers. The task usually goes something like: ‘Please build X. X must be able to do a,b,c,d,e’. 

I remember when I did take home exercises my thinking was along the lines of ‘Just do the thing they ask for, as long as it works who cares’. This is true the homework has to run without errors and work. However there are things you can do to make your work stand out. And honestly most of these bonus points are really easy to get.  

## Readme
Most Readme's I see are the generic auto generated ones. Which always makes me sad as a readme is arguably the most valuable real estate that most candidates ignore.

This is the place where you can explain what you did and why. And where you can explain what you would do with the project if you had more time to work on it. 

#### Things you should add to your readme:
1. manual test plan (we will come back to this)
2. why you chose to do what you did, no matter how detailed the exercise there will always be creative wiggle room - so this is a great place to explain your reasoning. 
3. how can this project be improved, what would you have done if you had more time - go crazy, or go rational say you did not test it with voice over accessibility technology and if you had more time you would do that. 
4. was there something you did not do
5. call out bugs - if there is a bug that you have no idea how to solve or don't have the time to solve this is the place to call it out. 

## Tests
If you are applying for a junior role tests are rarely expected. If for a more senior role - you must have tests. If you are a junior and don't know how to write tests then in the read me add a manual test section where you explain how you manually tested your app - what pages you visited what buttons you clicked etc. 

## Semantic HTML
Just because something CAN be a div does not mean it should be a div. The bonus of using semantic HTML is that usually its keyboard accessible. Even if you know nothing about accessibility - semantic html will do most of the heavy lifting for you. 

## Accessibility
In most companies your homework will undergo basic accessibility testing and accessibility is an unspoken requirement.

The basic test is to make sure that the thing you built is keyboard accessible (can you focus on everything using tab, and click using space). If you have access to screen readers like VoiceOver & Jaws also use those. Write about accessibility testing you did in the ReadMe. 

## Small touches that show care and character
I am a UI engineer, I help hire front end engineers and honestly there is nothing that makes me as happy as a front end engineer who shows that they care about the user. It might be tiny little things that are added to the feature that might have not been part of the assignment that show that the candidate did not just follow a list of 'todos' but thought about the user. A recent example I came across was an error screen and message that where in line with the exercise. 

You can teach anyone to be a software developer, you can turn an okay ui engineer into a great one with enough mentoring and resources. But it's a lot lot harder to teach people to care. 

## Comments that are not meant for anyone who is not the author of the code
Just as a reminder - when you submit your homework make sure it is readable to strangers. 

## Git history
We all write commit messages such as 'chore: fix the thing' followed by 'stupid lint errors', 'committing while it's not broken'. While we are on the topic of git. One big commit for the whole exercise is also not a great look. 

## If its not used it should not be there 
In the code if it's not used - delete it. 

## Add comments in the style sheet
If all of your styling is in a long CSS file do add comments that help users navigate the file.

These peace’s of advice are definitely not guarantees to land you a job but these are all tiny ways how you can definitely make your application stand out. 

## Careful with copy pasting
Let's face it a big chunk of the job is  searching  for examples and copy pasting. Sometimes you copy paste your colleagues work, sometimes your own, sometimes a stranger's on the internet. Thats all kosher we all do it and then we go and clean it up so its not an in-your-face-copy-paste job. If you did copy paste - rename things, alter it make it yours. If your homework exercise asks you to create a weather app and you did something similar for a project for a movie app make sure the copy pasted stuff is renamed from BestMovieOfTheDay to WeatherToday. 

## Consistency aka use prettier
Random spacing and a mixture of single and double quotes for strings just makes the code look messy. 

## Avoid !important
Thats it, thats the advice.

If you have any advice from 'marking' homework assignments do let me know in the comments.

-----
This is all from my personal experience