Unsurprisingly, when discussing take-home assignments for coding interviews, much of the focus is put on code. Can you code? Are you using “best practices?” What tools are you using?. There’s lots of code-related things that people think about, or even stress about.
Unfortunately, non-coding tips for coding interview assignments don’t get talked about nearly as much. And, in my experience, there are a lot of non-coding things we can do to put our best foot forward and impress a hiring committee with our take-home assignment.
Telling Your Story
What are these non-coding tips? If we’re completing a programming assignment, what else should we pay attention to?
Put yourself in the mindset of a reviewing engineer.
- How will they experience your project?
- How can you guide their experience?
How can you tell your story?
- What do you want a reviewer to know about you after they review your code?
- What interests, skillsets, workflows, or values do you want to highlight?
We want to help a reviewer get to know us – to understand what we can do. We want to think about giving reviewers reasons to be impressed by our projects and we want to do our best to limit head scratching moments.
Take-home assignments provide a unique opportunity to tell these stories because they are done asynchronously. During a take-home assignment, engineers are not typically under the watchful gaze of the hiring committee. We have a chance to be more natural; to think more clearly; and to take greater ownership of the impression we make.
Make a good first impression
Take-home assignments, as with many things, can really benefit from a positive first impression. If a reviewer starts exploring your assignment on a positive note, the rest of the review is likely to go better.
Using Project Metadata To Give Additional Context
If your project is using GitHub, git, or some other form of version control, then you have a great opportunity to showcase project information through various forms of “metadata” available to you.
If using git, your git history is a great way to highlight how you work.
If your project lives in GitHub, add relevant attribution. Give it a useful description. Add relevant topcis such as “android” or “kotlin” to give a quick overview of what the project is about. You might leverage GitHub Issues, PRs, and Milestones to give reviewers a sense of how you like to work and manage your tasks.
What can you add to your project to give helpful context to a reviewer? Don’t spend a lot of time here, but often a little bit of investment here can help give your project a more professional look.
Highlighting Information Using A Project README
Having a helpful project README in the root directory of your assignment submission is a terrific idea. A README the perfect place to document assumptions, outline your tasks, or add screenshots or video of the project.
Imagine yourself sitting down to present your project to a reviewer. Where would you start? What information would you want to highlight right away? Think of your README as this overview.
Use the README to guide the efforts of a reviewer. Call out interesting functionality. Call out tools and libraries that were used.
Use it to tell your story; whatever that may be.
Guiding Reviewers With Clear Project Organization
The last item to a great first impression is clear project organization. In most cases, I suggest you organize your project by “feature”, or by “layer”. You want your reviewer to be able to navigate your project easily.
You also want to demonstrate that your organization would scale to real-world, production projects. Putting all your files in a single directory might work for a small take-home assignment, but wouldn’t be a great choice for a large application.
Not sure if your project will be easy to navigate? Try navigating the project without your IDE. You might explore the project in GitHub or from your file browser. If it’s easy to navigate without an IDE’s search and class-lookup functions, then you should be good to go.
First Time User Experience
At some point, a reviewer is most likely going to run your code. What will that first-time-user experience be? A focus on two main things can really have a large impact on how a reviewer feels about your project.
Ensuring A Functional Experience
Make sure your app doesn’t crash when a reviewer installs it. You don’t want your app to crash at all, but it’s especially important that it doesn’t crash on startup. A crash on startup means a reviewer may not be able to evaluate the functionality – this does not usually lead to a great assignment review.
If you have the time, test your app startup across a few different device configurations. Maybe 2-3 different OS versions, and a couple of different screen sizes. If your app starts up, and is functional, across these configurations there’s a good chance your assignment reviewers will also be able to successfully start using your app.
Impressing With UI Polish
Once your app is started, what is the first thing a reviewer sees? If your main screen leaves a positive first impression, it can go a long way towards creating a positive feeling towards the project as a whole.
How can you leave a good impression? A little bit of design polish goes a long way. A few design items that are not time consuming, but really help the look/feel of your app:
- A unique, visually appealing, color palette.
- Consistent spacing
- Using the Material Design 8dp grid is a great way to go
- Define a couple of dimension resources and use them throughout your layouts for a more professional look
- Touch feedback
- Add a ripple effect when touching views is a nice UI addition
- This can be accomplished with very little effort and again goes a long way towards a more professional look
- Don’t reinvent the wheel
- If you’re not sure how to structure the UI/Navigation in your app, look to existing apps for inspiration
- If your “weather app” assignment behaves like an existing app, it’ll likely make it easier to use for a reviewer, and that can often lead to a better overview impression
- Adaptive design
- Ideally, your app’s UI would adapt to different screen sizes/configurations
- If your app doesn’t work well on small screens, or in horizontal layouts, call that out in your README or elsewhere.
What does your code say about you?
The way in which you write your code, whether it’s functional or not, can say a lot about how you operate as an engineer.
Leveraging Consistency To Improve The Review Experience
A big part of being a professional software developer is reviewing code. Code is easier to read and review if it uses consistent styling and conventions. This is true whether in a produciton codebase, or a take-home assignment.
Before you submit you project, run a code formatter on the code to ensure you are using a consistent style.
Building On A Solid Foundation
It’s great to highlight fancy libraries, or to build flashy features into your project. However, if they come at the expense of the fundamentals, they might actually hurt you more than help.
For example, if building an Android app, it’s considered best practice to define user-facing strings as String resources in a strings.xml file. Hardcoding all of your strings might be a red flag to reviewers.
If your project requires special permissions, and you don’t build a permissions workflow into the app, it could reflect poorly on your submission. Or if you place all of your code into a single, large class – it might reflect poorly on your submission.
The moral here is that well organize, well structured code that doesn’t miss on the basics is likely going to be better off than a project that uses the “new shiny” library but is built on a shaky foundation.
Documentation
Software developers often joke about their lack of documentation, or argue about whether good code even needs documentation. However, in an interview situation, good documentation is without a doubt a helpful tool.
Take home assignments are often about tradeoffs. You usually have a set number of tasks to complete with a limited amount of time in which to carry out the assignment. Tradeoffs must be made to balance completing the assignment with writing our ideal solutions.
Use documentation to detail those tradeoffs and to simulate the discussions that would come up during a typical work situation.
Documenting Your Decision Making
What assumptions did you make about the specified requirements? What questions did you have, and how did you answer them?
Why did you choose Library X over Library Y? Why did you choose Architecture A rather than Architecture B?
All of these types of decisions are opportunities do document and share your thinking.
You can go further than that as well. You could include more narrative documentation about areas you chose to focus on, and why? Why did you add unit tests? Why did you add a CI workflow? How did you come up with your custom color palette? These are all interesting notes that you can document and share with reviewer to give a sense of how you work.
And lastly, be sure to document anything that isn’t work – or isn’t working as specified.
Was your weather app supposed to show precipitation, but the api you chose only offers that data if you pay? Document that limitation so its absence doesn’t seem like an oversight.
Does your app crash when rotated? Call that out in the notes so it’s clear that you found and understand the issue. You might even get bonus points for including a suggested fix.
With most reviewers, you’re not going to lose points for transparency. Being upfront about what is, and isn’t, working builds trust – and trust is a very important part of choosing to work with someone.
Choosing Documentation Formats
Your documentation can come in a variety of forms. You might find that a mix of documentation formats is ideal for you, or you might focus on one above the rest. While I do highly suggest having a README, choose the documentation option(s) that work best for you.
A few documentation examples include:
- A README in your project’s root directory
- Code comments
- GitHub Issues, Pull Requests, Milestones
- A wiki in your repository
- Architectural Decision Records
- A recorded video of you walking through the project
Make It Your Own
Take-home assignments typically have a concrete set of requirements; usually a set of tasks to complete and specific functionally that must be present. That doesn’t mean that those tasks are the only things we can work on.
Telling Your Story By Customizing Your Submission
As mentioned earlier in this post, think about the story you want to tell to a reviewer. What do you enjoy working on? What is your “genius zone?” And how can you highlight those things in your submission?
Do you enjoy working with CI infrastructure? You could setup a simple CI workflow for your project and maybe include a small writeup on your preferred CI architecture.
Maybe you really enjoy bringing to life beautiful designs? You could add a unique animation or user interaction. A custom loading indicator or “empty state” screen are great opportunities for this.
Do you really believe in Test Driven Development? Write some tests for the project and include a summary of your testing philosophy.
These additions don’t have to be massive time investments, and honestly they probably shouldn’t be because we need to make sure the core functionality is there. But, an additional feature, test, or other custom element can be a really valuable way to highlight how you would be a uniquely valuable asset to any team.
Leveraging Non-Coding Tips For Your Next Coding Interview Assignment
Next time you have a coding interview assignment, don’t forget about these non-coding tips. Remember to put your best foot forward by:
- Making a positive first impression
- Ensuring a stable and pleasing first-time-user experience
- Writing consistent, readable code
- Documenting your code and decision making process
- Making the project your own
If you can do these things, and complete the required assignment tasks, you will have gone a long ways towards helping yourself get that next job!
Where To Learn More?
Watch on our YouTube channel.