Event Delegation in a Pomodoro App

We will now build a simple Pomodoro App. If you don’t know what the Pomodoro technique is, you can read about it here.

Exercise

Create a client-side application that displays a table of tasks with the following columns:

• Task name (string);
• Status: number of pomodori done, a slash, the number of pomodori planned, then a space, then the word pomodori;
• Controls: contains three buttons for each row, Done, Increase Pomodoro Count, and Delete.

When pressing the Done button, the Done and the Increase Pomodoro Count buttons are replaced by the static text Finished.

When pressing Increase Pomodoro Count, the number of pomodori done is increased by 1 in the Status column. The initial value of the number of pomodori done is zero.

When pressing Delete, the corresponding row is removed from the table.

Create a form that allows you to add a new task. The task name can be any string, and the number of pomodori planned can be an integer between 1 and 4.

Unblock Yourself

This task may be an exercise that you can either solve during an interview, or as a homework exercise.

Always respect the requirements, and never invent anything on your own. It is fine to clarify questions on the spot if you have time to ask them. If you solve this task as a homework assignment, it is also okay to send your questions to your contacts via email.

Pointing out the flaws in the specification is a great asset to have as long as you demonstrate that you can cooperate with your interviewers.

My usual way of cooperation is that I ask my questions along with the first submitted version of my task. This means I implement everything I can, without getting blocked, and then I enumerate my assumptions and improvement suggestions attached to the first version.

This sends the message that you are aware of a flaw in the specification, and you are willing to fix it, in case it is needed. You also signal that you were proactive in implementing everything you could, based on the information available to you.

Most of the time your interviewers will accept your solution. Sometimes they may ask you to go ahead and make changes to your application based on their feedback.

Remember, don’t block yourself just because the task is underspecified. You can implement only what’s needed, and tackle the improvement suggestions later.

What is not specified?

In this example, there are quite a few unusual elements.

First, the task name may be an empty string. There is no validation specified in the task description. You may point this out as an improvement suggestion. Implementing validation on your own would mean that you don’t respect the specification.

Second, different rows may contain the same task.

Third, there is no way to undo pressing the Done button. When a task is finished, it will stay finished.

Fourth, the Pomodoro counter may increase above the planned number of pomodori.

Fifth, pomodoro is singular, pomodori is plural, but we always display pomodori in the status column.

You can point all these anomalies out as improvement suggestions. Improvising and implementing these features without asking for permission would imply that you don’t respect the specification. Some hiring crews will not care about it, while others may even reward you for improvising. However, chances are, if you continuously improvise, your interviewers will ask themselves the question if they can cooperate with you smoothly.

This is why I suggest putting all your improvement suggestions in the documentation attached to your solution. You even save yourself time.

Solution

Let’s start with the markup: