PROJECT: HireLah!

Overview

HireLah! is an app that helps interviewers manage their interviewees, the attributes you look out for in these interviewees, and the questions to ask during the interviews. As a complete solution for interviewers, HireLah! also helps interviewers conduct interviews on the app and identify the best interviewees.

Summary of contributions

  • Major enhancement: Added the ability to conduct interviews from within the app itself.

    • What it does: Allows the user to give the command interview <interviewee> to turn HireLah! into a note-taking app to take down comments and remarks while interviewing the candidate. Also allows the user to score candidates on the created attributes, and indicate when questions were asked for easy retrieval later.

    • Justification: This is a critical feature for the app as it allows users to be more productive using our app as compared to maintaining their lists of candidates, questions and interview rubrics (attributes) separately. When conducting the interview within the app, it is easy to check the questions, the app reminds you to assign scores to all attributes and makes it easy to track who is interviewed.

    • Credits: Team mate Agnes Natasya for creating the Transcript class and providing a clear API for the interview commands to consume, thus making the implementation of the commands simpler.

  • Major enhancement: Added the ability to manage multiple interview sessions from within the app.

    • What it does: When the app starts, rather than loading a default session, the app shows the user his/her available sessions, and allows them to choose to open a previous session or start a new one.

    • Justification: This feature significantly improves the user experience of the app as previously, to change sessions, one would have to manually modify the preferences.json file before starting the app, a feature which some users would not be able to discover while using the app.

    • Highlights: This enhancement was challenging to implement as we had to retrofit it after feedback in v1.3. It involved planning when and how to perform the initializing of the session-specific Storage, UI and Model components after the app has already started, without affecting the implementation of these classes, which had been written under the assumption that they would be initialized at app startup.

  • Code contributed: Both test code and functional code here

  • Other contributions:

    • Project Management:

      • Managed release of v1.3 milestone

      • Planned division of work at the beginning of each milestone v1.2-1.4

      • Regularly checked on team mates progress to ensure each milestone’s goals could be met

    • Review/mentoring contributions:

      • Some PRs reviewed: #103, #90, #81, #203, #190, #187, #186, #66

      • Helped team mate Wei Cheng with design and implementation of Storage component, to allow saving of individual components (AttributeList, IntervieweeList, etc), and saving each interviewee’s transcript into a separate json file. The design allowed HireLah! to take a fine-grained approach to saving each component when changed, improving performance, and also validated the stored data when loading, to ensure the Model is always in a valid state. Coauthored #103 which implemented this design.

      • Bug reports filed: #60, #79

    • Documentation:

      • Updated use cases and user stories #212

    • Team-based tasks:

      • Updated the team website

      • Renamed the project and package name

    • Tools:

      • Setup AppVeyor when Travis-CI was undergoing maintenance

      • Setup Coveralls to check our code coverage

Contributions to the User Guide

Features

Generally, in an interview session (for example, an interview for a role in a company), there are 3 phases:

  1. Initialization phase (or preparation phase) - where the interviewer prepares his/her questions, manages candidates, receives their resumes, etc.

  2. Interview phase - where the interviewer actually conducts interviews, asking questions and making notes about each candidate

  3. Decision phase - after interviewing all candidates, the interviewer summarises his/her opinions, refers to the remarks he/she made of each interviewee and decides who to select

These 3 phases are clearly defined in HireLah!. What you can do in each phase is listed below.

Viewing help

Command

You never know when you need to refer to this guide. For that reason, the helpful help command is available always within the app, except during an interview, where "help" may be a remark you want to make about the current candidate being interviewed! Still, the help command is always accessible via the F1 key, or by clicking the "Help" button on the top of the menu.

help

Action: This user guide is opened as a PDF with your system’s default PDF viewer.

Exiting the App

Similar to help, exit is always available to close the app, except during an interview (Why would you want to close the app during an interview?).

Command

exit

Action: The app exits.

Managing Sessions

HireLah! allows you to clearly separate your interview sessions. After all, it would be disastrous to mix up your candidates for one job with the candidates for a totally different role, or ask the wrong questions to the wrong person!

New Session

When you first start the app, there will be no existing sessions. You can create a new session to get started via the new command.

Sessions are stored as directories in a /data directory HireLah! creates in the same location as the app. To make sure session names are valid, we only allow Alphanumeric characters (a, b, c or 1, 2, 3) and spaces (but not all spaces!).
Do not accidentally delete this folder! HireLah! will not be able to restore your data if you delete it!

Command

new <session name>

Execution Example

> new ceo interview

Action: Creates a new session called "ceo interview" and opens the session.

NewSession

Open and Close Sessions

On subsequent uses of HireLah!, you will be greeted at the starting screen with all the sessions you have created. You can choose to start a new session again, or open a previous session to continue working in it using the open command. After you are done for the day, or need to switch to another session, simply close the session with the close session command. Closing a session will naturally return you to the starting screen where you can open or create new sessions.

Commands

open <session name>
close session

Delete Session

After a long time, old sessions may not be relevant anymore. To clear space for new interviews, use the delete command.

Command

delete <session name>

Execution Example

> delete ceo interview

Action: Deletes the ceo interview session and all its data.

Output:

Successfully deleted the session: ceo interview

Finalise Interview Attributes and Questions

After the interviewer is satisfied with the list of questions and attributes created for an interview session, the interviewer must finalise changes in attributes and questions. This is to ensure that the interviewers will evaluate all interviewees fairly and equally using the same set of questions and attributes.

Finalise is irreversible! Make sure you are sure of the attributes and questions you have, since HireLah! will not allow you to make changes to them after giving this command. This may seem restrictive, but this consistency will give you guarantees that make HireLah! really useful. For example, later on, if you open someone’s interview report and find his/her answer to a question, then go to another report and view the same question, you are guaranteed that both interviewees were asked the same thing!

Command

finalise

Output:

Attributes and questions of this interview session has been finalised. You cannot change them anymore.
Finalise


Contributions to the Developer Guide

Session Feature

HireLah! differs from AddressBook significantly in that a single user will likely have many sessions, as compared to just owning a single address book. The app thus provides means of managing multiple sessions from within the app itself, instead of having to change preferences.json to create a new session or switch between sessions.

Proposed Implementation

Having multiple sessions and changing between them from within the app means that HireLah! cannot load data from storage on app startup.

Instead, when the app starts, the ModelManager does not have its components (IntervieweeList, AttributeList, etc.) loaded, only UserPrefs, and the AppPhase is set to PRE_SESSION.

UI displays the SessionPanel which shows the available sessions in the "sessionsDirectory" folder.

In PRE_SESSION phase, logic uses the PreSessionParser which accepts commands to open an existing session or create a new one.

Once a session is chosen, the command calls Storage#loadSession which creates new Storage components for the new session (IntervieweeStorage, AttributeStorage etc.) that save to the correct session directory. loadSession then calls Storage#initModelManager, which loads new Model components (IntervieweeList, AttributeList etc.), then replaces the current ModelManager components. AppPhase is then set to NORMAL at which the app starts its usual behavior (adding interviewees etc.).

Finally after refreshing the ModelManager, then a new UI InterviewPanel is created that observes the new Model components. Since the Model’s components have been replaced (a different set of ObservableLists), the UI can only be created at this point else the UI would be data binding to the wrong lists.

The following activity diagram shows the sequence of initialization of components when a session is opened.

SessionActivityDiagram

From the NORMAL phase, the close session command can be given, which simply un-sets the current session in Model and returns the AppPhase to PRE_SESSION. Thus the app is ready to open a new session, by resetting the storage components and the Model components, then creating a new UI InterviewPanel again.

Design Considerations

Aspect: How sessions are stored in the app

  • Alternative 1 (current choice): Do not store information about sessions in Model. Directly read available sessions from the /data directory (or whatever the user set the "sessionsDirectory" to in preferences.json). Scan the directory again every time the SessionPanel is displayed.

    • Pros: Information about the available directories is always synchronized with the filesystem. It is possible to copy a session from somewhere else into the "sessionsDirectory" and the app will detect it.

    • Cons: Simplistic - app naively treats all directories in the "sessionsDirectory" directory as sessions and displays them as available sessions to the user. If a folder is created externally with invalid data, it will also be treated as a session, only failing when the user tries to load it.

  • Alternative 2: Model contains a SessionList which tracks what sessions have been created or deleted.

    • Pros: User cannot create/delete sessions outside the app, changes to the sessions (new session/delete session) can be tracked within the app itself rather than repeatedly making IO calls to the filesystem.

    • Cons: There is no "single source of truth" as both the file system and the app have a list of sessions, and it is not straightforward to ensure both are synchronized, eg. if a session data directory is deleted on the file system, the app will not be aware of it.

Aspect: How session data is loaded and saved

  • Alternative 1 (current choice): Load session only when a command is given to open a session from a directory.

    • Pros: Most user friendly, managing sessions is performed through the same CLI. Memory efficient - data is loaded only exactly when needed.

    • Cons: Complex to implement

  • Alternative 2: Load all data for all sessions into memory when the app starts, open session merely selects the current session in focus and displays UI with current session data.

    • Pros: Straightforward to implement (All data can be loaded on app starting, need not change implementation from AddressBook). Switching between sessions is very straightforward.

    • Cons: Will be memory intensive as all data even from non-active sessions and past sessions will be loaded. As HireLah! may include large amounts of data in interview Transcripts, loading all the Transcripts from previous sessions will likely negatively impact startup timing. Furthermore, it is unlikely that an interviewer needs to access previous interview sessions data in a current interview, making a lot of the memory consumption wasteful.

    • Relevance consideration: It is not often that an interviewer would need to switch between sessions while interviewing for a specific thing, for example a role in the company.

  • Alternative 3: Require the user to configure the session to load before app starts up, in preferences.json

    • Pros: Simplest to implement, yet memory efficient as only the relevant data is loaded

    • Cons: Not user friendly - functionality cannot be performed within the app. User cannot discover the functionality on how to start a new session without consulting the user guide.