Final Interview Exam
The final interview exam will take at most for 30 minutes and comprise of two parts: live coding (20 minutes) and discussion (10 minutes). In the first five minutes of the live coding, the exam taker should describe the new feature that they want to build from their group project. The proctor will decide whether the exam taker can proceed with the proposed new feature or make adjustment to the new feature if similar feature has been implemented by previous exam takers.
The next 15 minutes shall be used for implementing the new feature. The exam taker must activate their camera and share their desktop screen throughout the live coding session. Looking for references on search engine, API documents, or any available source code are allowed. However, be advised that the proctor also take account on the development workflow and the best practices conducted by the exam taker during the live coding. Copy-pasting code from a search result on Google or Stack Overflow without knowing its purpose is frowned upon than reusing code with similar functionality from another module within the project's source code. Even when reusing code, please be aware of readability and maintainbility issues. Strive to have a clean source code at the end of the live coding session.
After the live coding session ends, the exam taker shall proceed to the discussion part. The structure will be similar to the one conducted during the midterm interview exam. The proctor will ask series of questions and the exam taker must answer each question. The questions will cover mainly about the subjects from the midterm exam until the final exam. However, there are chances for the subjects prior to the midterm exam will be asked during the discussion.
Live Coding Specifications
Develop a simple and small enough new feature based on your group project. The criteria for the new feature is as follows:
- It can be implemented by adding and/or modifying at least one Java source code file each from the model- and controller-related modules. You may also want to modify any supporting Java source code files if the new feature needs it, e.g., security-related configuration for RBAC (Role-Based Access Control) or allowable domains in CORS (Cross-Origin Resource Sharing).
- It can be observed and usable when the application is running, hence requiring a new view-related source code file or modifying the existing views.
- It has a test suite that verifies the correctness of the new feature.
- It does not break any of the existing features.
If your group project comprises of two repositories, e.g., Spring Boot as as backend and React as frontend, then the criteria applies only to a component. For example, if you choose to implement the new feature on React frontend, then ensure the addition/modification cover the .JSX/.TSX files that render the component and handle the logic.
Mandatory Tasks
Note: All of the programming tasks must be conducted during the interview exam session.
- Fork the group project's repository into your own GitLab CS subgroup in
KKI 2021 group and assign a descriptive name for the fork repo, e.g.,
fork-interview-final-exam. - Clone the fork into your development environment.
- Work on the new feature.
- Create the test suite for the new feature.
- Demonstrate the new feature locally and show that the existing features are still working.
- Push the latest state of your work to GitLab CS at the end of the live coding part.
Optional Tasks
- Clean up one or more code smells that are present in the fork repository.
- Ensure the pipeline is working and return pass/"green" status in the fork repository. If the pipeline is not working from the upstream repository, then fix it.
- Deploy the fork repository along with the new feature to your own Heroku account, preferably automated using GitLab CI/CD.
- Run SonarScanner analysis and send the results to SonarQube AdvProg, preferably automated using GitLab CI/CD.
Created: 2022-03-24 15:13:08