This assessment is designed to emulate a day in the life of a Valocity Software Engineer. You will be assessed on how well you follow instructions and express the intent of your changes using the tools at hand. Its purpose is not to trick you or catch you out but to get an understanding of how you think about solving problems using software and capturing learnings and intent using nothing but files within a version control system.
Take as much or as little time as you like, however we suggest around 90 minutes to get through as much as you can. Feel free to search for solutions, read documentation, and ask for help. Just make sure that you try to understand the code and attribute its source before copy-pasting it.
It is up to you to manage your time. The answers will be assessed against the role you have applied for so ensure you demonstrate the key objectives expected by the role.
Commit to the local git repo often to show progress and workflow. Ensure the commit comments explain why you made the change.
Don't forget to check out the appendix](#appendix) for some great tools, hints and tips.
You will need git and a code editor of your choice. We recommend Visual Studio Code with Remote development in Containers, this project contains a development container definition. Once this workspace has re-opened in the remote container run the following commands to ensure you are set up and ready to go.
- Open the terminal.
- Run:
dotnet test
To submit your solution:
- Ensure you have committed all your changes
- Run
git clean -xdfto clear out any build artifacts-
⚠ Binary files in the submission will be blocked by spam filters
-
- Compress the solution source into a single archive
-
⚠ Ensure the .git folder and other hidden files are included in the archive
-
- Send on through to [email protected]!
If using the development container:
- Open the terminal.
- Run:
git clean -xdf mkdir Pickup -p zip -r Pickup/CodingAssessment.zip . - Send on through to [email protected]!
This will assess your knowledge of Code Smells, clean code and the ability to comment on or critique code. The code in CodeToReview.cs has been submitted by an intern from another team to a code base you depend on. Using inline comments, review the code with either questions for clarification or feedback with enough context for the author to learn and enhance the code.
This will assess your TDD skills and your ability to work safely with existing code. Use tests to gain an understanding of the existing behaviours and ensure your changes are safe. Your task is to refactor CodeToRefactor.cs. Use comments, commit messages and automated tests to express your reasoning, assumptions and issues encountered.
This will assess your
- Ability to design solutions
- Ability to decompose problems
- Knowledge of clean architecture
- Knowledge of continuous delivery and DevOps
- Ability to identify constraints and assumptions
- Awareness of cognitive biases
- Test-driven development skills
As an enthusiastic card player and developer
I want to create a program to play cards against the computer
So that when I am bored I can play against an intelligent opponent.
Unsure of what UI to build for, or what card game I should code for. We will figure that out later. At this stage, I know I need a concept of a Deck, Cards and a Shuffle function.
How would you set up your new solution and why?
- Show me your initial to-do list with some reasoning, for example:
- Development environment setup
- Scaffold/structure of your solution
- What would your delivery pipeline look like
- Scaffold your solution
- See how much you can scaffold out to hand to another team member to continue with
- Bonus points if you have something working
Below you will find some resources to help you understand our engineering culture. These are categorised into the three main pillars of every change we make.
- The Why ( Values, Documentation, Commit messages, Comments )
- The What ( Principles, Documentation, Tests )
- The How ( Process, Architecture, Code, Tools )
- Documentation
- Test Driven Development (TDD)
- Test first: Red, Green, Refactor
- Test naming: Given_When_Then
- Structure: Arrange, Act, Assert
- Process:
- Start with degenerate test cases first.
- As the tests get more specific, the code becomes more generic.
- Katas:
- Two TDD styles, London vs Chicago more concretely covered by Sandro Mancuso below
- Uncle bobs response to TDD Harms Architecture
- Interesting debate
- Why TDD sometimes feels hard
- TDD for those who don't need it
- Agile manifesto
- The values and principles are key to understanding no matter what agile methodology is used.
- Clean Architecture
- Architecture 101
- Jason Taylors - Clean Architecture repo and here it is Explained
- Here is Steve Smiths version for a comparison
- Clean Architecture and Design by Robert C. Martin (Uncle Bob)
- Linking TDD and Clean Architecture by Sandro Mancuso. Does TDD Really Lead to Good Design?
- Clean Code
- Christin Gorman “Gordon Ramsay Doesn’t Use Cake Mixes” ➡️ https://vimeo.com/28885655
- Bryan Liles “Test all the f*^&ing time” ➡️ https://youtu.be/iwUR0kOVNs8
- Gojko Adzic “Make Impacts, not Software” ➡️ https://youtu.be/GnK_n9Udhhs
- Jeff Patton “User Story Mapping” ➡️ https://youtu.be/AzBuohuOU6g
- Michael Nygard "Uncoupling" ➡️ https://youtu.be/mAw4ygX1c-4
- Gregor Hohpe “Enterprise Architecture = Architecting the Enterprise?” ➡️ https://youtu.be/DdJNLeYldUs
- Eric Evans "Tackling the complexity at the heart of software" ➡️ https://youtu.be/dnUFEg68ESM
- Jim Webber, "The Present and Future of Native Graph Technology" ➡️ https://youtu.be/_CQehnb6A6o
- Jez Humble, “CD sounds great, but can’t work here” ➡️ https://youtu.be/IvWr29afDF8
- Anita Sengupta, “The future of Mars exploration" ➡️ https://youtu.be/iuzZYzns-Yg
- Hanna Fry, “How to be human in the age of the machine” ➡️ https://youtu.be/Rzhpf1Ai7Z4
- Better Coding playlist