Repository to share my airG assesment responses with the hiring team
All tests are written in Python under Docker infrastructure. All tests contains unit tests written in pytest, but those tests are only for demonstration purposes and should not be reviewed as final TDD development, since further context is missing. Scripts with user actions are provided with help arguments using the flag -h. If you dont wanna to use the Docker infrastructure (which is highly recommended to ensure your local environment is compatible with what I planned), the Python version used was 3.8, so you can run from there.
Test 1 is simply a script which will make one or more requests to the provided API until it reaches at least 5 unique manufacturers names. The final display will be a list containing the manufacturers names.
Test 2 contains an user interface via CLI which can be used to pass arguments to the script. You can use either -f or --filename to set the output .csv name and -r or --rows to set the resulting number of rows. Now, lets answer the asked questions:
If you had to generate a large number of rows (millions or more), is there anything you would do differently to handle this? Modify your script to handle this requirement.
So since each line has no relation with other, the main perfomance improvement would be to parallelize the computation during the row generation. I did so by using Python's native multiprocessing module, which allows to split computations between tasks based on the running count of cpus.
If this script had to run in a production environment, what tests would you include to ensure it's running correctly? Add the tests.
As said in General Info section, all tests were developed with unit tests, so those are the very minimum I would include to ensure the core of code is working as expected.
If you were having this code reviewed, what else would you do with your code to ensure the code is clean and well-formatted?
I would make sure to setup a precommit hook including Python main modules for code static analysis, such as pep8, black, isort, etc. This would add another layer of confidence that the code is under the clean code specs.
Test 3 is based upon two files, one input file provided by the user (can be modified and then rebuild Docker to change it) and one output file generated by the code itself. As stated in the test description, both arguments are optional and if not provided, the script will try to guess the CSV format, which may lead to unexpected behaviour.