feat(pages): add pages on environments, testing, the tech test

guides/environments.md

@@ -3,9 +3,56 @@
 When not dictated to by a client the following environment definitions should be
 applied:
 
-## TODO
-
 - `local` - your local machine
 - `dev`
 - `staging`
 - `production`
+
+The environment can be controlled through environmental variables and loaded in
+respect to the product that needs them. They can be listed in Github Actions,
+Dockerfiles, or even can be loaded within the code (which is very common).
+
+An example of how one may do this in python for example:
+
+```python
+import os
+
+ENV = os.environ.get("ENV") # Load the environment variable from the machine it's on
+```
+
+Because the code above is referencing the variable `ENV`, this variable will
+need to be set on the machine that the code is running on. This can be stored in
+a `.envrc` variable if you are using `direnv` on your local machine. Or added to
+the Databricks cluster that you are deploying (For example). Environment
+variables are used in all of our projects, and they should be used to ensure
+that the code running pertains to the correct environment that it is suited for.
+
+## Development Stages/Environments
+
+The four different environments are generally self explanatory and splitting out
+dev and staging may be overkill for certain projects but in general:
+
+### Dev
+
+A safe deployment that allows for experimentation and should be used for
+testing, debugging and ensuring that code is ready for deployments. Initial
+feature development will be easiest in this environment.
+
+### Testing
+
+A deployment that is to run ahead of the production release by x amount of
+days/weeks to ensure that UAT testing by QA (Quality Assurance) engineers on new
+features can be accepted before deployment to production.
+
+### Pre-Production/Staging
+
+The battle tested and thoroughly safeguarded deployment that is the one that can
+be treated as a beta environment to do any final checks and testing. It is an
+exact mirror of production apart from the incremental change that will be going
+forward. The focus is to test the application from start to finish and ensure
+behaviour of the entire product.
+
+### Production
+
+The battle tested and thoroughly safeguarded deployment that is the one that is
+used by the client/customers.

guides/interview/preparatory-explanation.md

@@ -17,7 +17,7 @@ least a passing familiarity with the format of the technical assessment.
 
 The below must be shared with the candidate prior to the interview itself:
 
-- the technical assessment will take place using
+- The technical assessment will take place using
   [GitPod](https://www.gitpod.io/), a web-based IDE similar in appearance and
   functionality to [Visual Studio Code](https://code.visualstudio.com/). If they
   are familiar with GitHub's
@@ -27,3 +27,37 @@ The below must be shared with the candidate prior to the interview itself:
   implemented in a language agreed with the candidate.
 - the tests will initially be failing and the aim of the assessment is to add or
   update the existing code such that the tests pass.
+
+## Tech Test Example
+
+The first question on our tech-test is the following (if taking the test in
+`python`):
+
+If you choose to research our company and read through our guides on the
+handbook we think that you should be allowed to see what kind of questions to
+expect on the test. There are four more questions beyond this one (with a bonus
+one if you get that far) and they get more challenging as they go along.
+
+```python
+def test_01_can_count_number_of_males():
+    """
+    Count of the number of males in the rows of data from
+    the provided records object below by changing the logic in the function
+    get_count() found in app.py
+
+    Hint: Make sure the function gets something to count!
+    """
+
+    records: Records = [
+        Record(first_name="mitchell", surname="clausson", dob="21/01/1980", sex="m"),
+        Record(first_name="thomas", surname="skindstad", dob="18/06/1988", sex="m"),
+        Record(first_name="susan", surname="boyle", dob="01/04/1961", sex="f"),
+    ]
+
+    actual_value_1 = get_count()
+
+    assert actual_value_1 == 2
+```
+
+In this test we are looking to test your knowledge of classes and their
+attributes, as well as the ability to search a list by some criteria.

guides/testing.md

@@ -0,0 +1,16 @@
+# Testing
+
+Make sure that the tests in the codebase are correct, sensible, and useful.
+Tests do not test themselves, and we rarely write tests for our tests—a human
+must ensure that tests are valid.
+
+Will the tests actually fail when the code is broken? If the code changes
+beneath them, will they start producing false positives? Does each test make
+simple and useful assertions? Are the tests separated appropriately between
+different test methods?
+
+Remember that tests are also code that has to be maintained. Don’t accept
+complexity in tests just because they are not part of the main product/binary.
+If there are ways to compartmentalise behaviour into smaller and more
+predictable chunks, it is advised to do so as it makes it easier for product
+maintainers to understand expected behaviour.