Skip to content

Midterm Interview Exam - Case 2: Kuda (Runner) Reporting System

Kuda is an alias of the GitLab Runner server that provides shared CI runner for projects hosted on GitLab CSUI. Due to heavy utilisation and limited resources, the server sometimes experienced issues such as timed out CI jobs. To allow faster response by the administrator in handling issues on CI server, the users can write a report, or issue description, detailing the problem they encounter with the CI server.

For the interview exam, the scope of the requirements is simplified. The Web service does not need to use relational database to store the issues. It can be handled by an instance of java.util.List.

Requirements

Estimated reading time: 5 minutes

The Web service shall provide 4 (four) API endpoints:

  • HTTP GET /issue Return 5 (five) most recent issues submitted to the reporting system.

    Does not need any parameters in the request payload.

  • HTTP GET /issue?index={index} Return the issue stored at position index in the list.

    There is one parameter named index as part of the query string in the URL. index is an integer with possible valid values from 0 to size of list - 1.

  • HTTP POST /issue Save a new issue into the list.

    Does not need any parameters in the request payload. Require the data regarding the issue to be submitted as form data.

  • HTTP DELETE /issue?index={index} Remove the issue stored at position index in the list with the submitted issue.

    There is one parameter named index as part of the query string in the URL. index is an integer with possible valid values from 0 to size of list - 1.

The form data used in delivering data to HTTP POST endpoint shall comprise of 2 (two) attributes: description and pipelineUrl. The request body only require description to be present and pipelineUrl may be empty/unset. The description contains the user's description about the CI issue and pipelineUrl is the URL to the corresponding GitLab pipeline where the CI issue was observed.

The response must contain a body of JSON data regardless the status of request handling. The JSON data, at minimum, must contain:

  • A status attribute that describes whether the request was succcessfully handled or not. The possible value is either OK or FAIL string.
  • A data attribute that contains the JSON string representation of the returned data. It may be empty/null if the backend did not find any relevant data or failed to process the request. In the case of handling HTTP DELETE request, the data must be empty.

During the interview exam, you will be asked to implement one of the feature above. To give you an idea how the Web service works and behaves, you can access the reference implementation on Heroku.

Programming Tasks

Estimated working time: 10 - 15 minutes

Turn on your camera and share your desktop screen. Ensure that the proctor (in most cases, the lecturer and sometimes the TAs) can monitor your activities during the interview exam. Imagine you are conducting a remote pair programming where the partner needs to observe your work.

Do the tasks in the Mandatory Tasks subsection. If there is some time left after you completed the Mandatory Tasks subsection, you can do the tasks in the Optional Tasks subsection.

Mandatory Tasks

We recommend you to do the mandatory tasks according to the given order. The tasks are sorted based on the required effort and the logical order to complete them.

  1. Get a designated feature to implement from the proctor.
  2. Fork the codebase template into your personal subgroup in AdvProg/kki-2022/student namespace.
  3. Clone the fork into your local development machine.
  4. Implement the designated feature along with the tests code, preferably by following test-driven development methodology.
  5. Ensure your tests verify the correctness of the main/success flow and at least one possible alternative flow (e.g. input validation error, incomplete input) of the designated feature implementation.
  6. Update the GitLab CI/CD configuration in the code template to make your repository on GitLab CSUI:
    1. Run the test suite for each new commits pushed to the repository on GitLab CSUI.
  7. Save your changes as Git commit(s) and push the commit(s) to the fork repository on GitLab CSUI.

Optional Tasks

Feel free to do the tasks in any order. It is alright if some of the tasks are not completed. The discussion session may ask you to complete the unfinished tasks.

  • Implement a simple, HTTP header-based authentication mechanism. For example, all HTTP requests sent to the endpoint must contain an HTTP header named X-AdvProg-Auth with a designated value, e.g. TopSecretKey. If the HTTP request contain the said header and the value match, then the request can be handled by the handler method. Otherwise, immediately return an appropriate error response.
    • If time permitting and you would like an extra challenge, create or refactor the tests to verify the authentication mechanism.
  • Identify and clean up code smells as many as possible in the codebase.
  • Update the GitLab CI/CD configuration in the code template and the project page on GitLab CSUI to make the codebase automatically deployed to Heroku.
  • Update Gradle configuration, and GitLab CI/CD configuration in the code template and the project page on GitLab CSUI to make the codebase automatically scanned by SonarScanner and sent the analysis result to SonarQube CSUI.

Discussion

Estimated discussion time: 5 - 10 minutes

The list of possible topics during the discussion is as follows:

  • Development workflow (Git, IDE)

    Examples: How do you use Git when working on your course work?; How to merge a branch into another branch?; How do you resolve a merge conflict?

  • Writing and running test

    Examples: How do you design the test cases to test a piece of code?; How to measure line coverage?

  • Concurrency

    Examples: How to prevent a race condition in implementation level or architectural level?; Describe one example of serialisation technique employed in a programming language/framework of your choice

  • Deployment workflow (GitLab CI/CD, Heroku)

    Examples: Describe one or more elements commonly found in a .gitlab-ci.yml file; Show how to deploy a codebase to Heroku using Heroku CLI

  • Code quality (SonarQube, SonarScanner)

    Examples: Mention some code smells that you have encountered throughout this course; What is the responsibility of SonarQube and SonarScanner?

It is also possible that the proctor will ask questions that are not listed above.

Hints

  • As mentioned in the requirements, you do not have to set up a database. The most straightforward approach is to use a class from the collection package in Java standard library.
  • If you are using Spring Boot, you only need Spring Web in the project dependencies. Do not make the project more complex by adding other dependencies such as Spring Data REST or database connection drivers.
  • You already have a collection of code examples that you can adapt to solve this problem. Hence, we do not recommend you to search for tutorials or code snippets through a search engine. You may do so, but we think it is better to spend your time in coding and reuse the available resources. In addition, it is easier to describe and to reason with the code that you wrote by yourself.
Last update: 2022-06-30 00:25:11
Created: 2022-06-30 00:25:11
Back to top