A newbie's first notebook: searching for jobs (academic and industry)

Hi everyone, I’ve just gotten my first “real” tinderbox notebook to a point in which I’m satisfied with it, so I thought I’d share the general gist. I’m a scientist searching for a new job, and considering both industry and academic positions.
I’ve created a general prototype for positions I wish to apply to, but also two derived prototypes, Academic Position and Industry Position, which change only the tone of the note’s colour. I also created the Item prototype, which I use to outline position requirements and other notes, and the Cover letter prototype. (Fig 1)

Position prototypes are containers with an instance of the Cover letter and Item prototypes (Fig. 2). They also have three boolean attributes: Applied, Shortlisted and Interviewed.

I keep the actual notes in a separate container (Fig. 3) with adornments for each stage of a job application. Each adornment has an agent query that keeps each note in the right stage depending on the values of the three boolean attributes. E.g. the query for the “To apply” adornment is “$Applied==false & $Shortlisted==false & Interviewed==false”.

In daily use, when I find a job I want to apply to, I create a new position (Academic or Industry) instance and change into the outliner view, where I add notes. The “Item” instance has a keyword attribute, which is shown in the position container’s table (Fig. 4).

I often also copy over the job description, quickly edit it into having each major point in a separate paragraph, and explode the note. I either turn the exploded notes into items with keywords, or use them to check what skills I have or don’t have, using badges (Fig. 5)

I keep track of any correspondence in notes inside each position container, and finally use all this information to tailor the cover letter. I have a generic cover letter for each type of position that each position inherits from its prototype, and I then partially rewrite it. I also tailor my CV outside Tinderbox. I’m also using Hookmark to crosslink each note to a summary on Agenda (agenda.com) any emails or documents I’ve decided to save in DT Pro, papers by the group that I keep in Bookends, etc.

I hope this is useful, and I’d be grateful for any suggestions!

EDIT(04 Aug 2023) Following Mark Anderson’s advice, I replaced the boolean state attributes for position notes with the “Step” string attribute using a suggested list for the various values (1-Prepping, 2-Applied, 3-Shortlisted, 4-Interviewed) and a default value of “1-Prepping”. This is easily done in the root prototype I mentioned. It was then easy to use Quickstamps to apply the right state to multiple notes, and the last step was to replace the queries for adornments with “$Step==…” as appropriate for each.
I can now easily select the appropriate state from a dropdown list!
It’s also easy to change the prototype names - the changes propagate, making the system much more robust.


What a great use case! Nice going. :slight_smile:

1 Like

Thanks! I’m really enjoying Tinderbox. I wish it could call external code. The things I could do with R, Julia and Clojure prototypes.

Check out the new Posters feature in 9.6, youc an call external javascript into TBX now.

1 Like

Great. Thanks for sharing this.

You could simplify the querying by using, as well as or instead, a String-type user attribute (perhaps ‘Status’?) pre-populated with suggested values, e.g. “Applied;Shortlisted;Interviewed”. A string attribute can only hold one value, so its value can’t—for instance—be both ‘Applied’ and ‘Interviewed’; it mist be one or the other. By using suggested values and setting the attribute’s value either by the Displayed Attributes value pop-up list or directly via action (i.e. no error-prone manual typing) you don’t need to maintain 3 (4?) boolean values and ensure one of the set is true at any time.

Or if you want to know the steps completed (perhaps for a dashboard/report) you could set true each boolean step completed whilst $Status holds the current stage of progress.

The good think is such suggestion can be adopted without massive effort. You early use of prototypes will repay you in this regard. Remember prototypes can do more than set visual features. Think of a prototype as an easy way to configure and/or find a group of notes with a common purpose. It’s easy to overlook the find (query) aspect. Being able to query just by the single term $Prototype=="Position" might thus find notes all over the outline (i.e. in different maps) and not obviously associated.

Tip: give prototypes a name you’ll never use for a note. ‘Position’ might easily crop up as a note. The most common method used is to use a prefix character (e.g. an asterisk, a lowercase ‘p’). That way, the actual prototype won’t use the same $name value as actual ‘content’ in your document. As
when you see it or type it in code the intent/meaning is much clearer.

What if you made an existing note into a prototype early on, e.g. in the actual map? No problem:

  • duplicate the item and un-set the $IsPrototype for one of the two notes, e.g. via the Properties Inspector’s Prototype tab.
  • move the prototype note to your prototypes folder and remove any customisations particular to only the note you just copied. Give the prototype a distinctive name.
  • now back in the original location, set the originally copied not to use the new prototype. For any values you want to inherit, reset those attribute’s values

Doing the above is quicker/simpler than all that text makes it sound.

1 Like

But you can! See the action code runCommand() which allows action code to communicate with the macOS Unix shell’s command line. That gives you access to most languages. that said, you aren’t running R (etc.) inside Tinderbox but simply communicating with an R process via the command line.

runCommand() is best for, say, calling a complex computational function you have in R (insert whatever favourite language) that either can’t be done in action code or is too time-consuming to re-build in Tinderbox. But I’d advise against using runCommand() as a prop for not learning Tinderbox action code, not least because it’s not optimised for such a purpose.

Tip: A meta-point arises. One of the biggest unforced errors I’ve seen consistently over the years helping (new) users is people holding onto a sense of “Why isn’t Tinderbox like my favourite other app/language?”. Truthfully, it doesn’t matter. If the other app/language can do the task you’re doing in Tinderbox you don’t need Tinderbox. But, if it can’t the time /energy invested in complaining is wasted and could be applied to grokking how Tinderbox actually works. Users getting past being stuck in ‘comparison mode’ is a step I observe where people’s effective use of Tinderbox then moves ahead more quickly.

1 Like

This is an excellent writeup of a very useful document (“notebook”).

Thank you for sharing – and, most importantly, I hope your job search comes to a happy conclusion soon!


Many thanks for sharing this! It is a very clear description of your project, and examples like this are often asked for by people who are interested in Tinderbox. Since Tinderbox is more a toolbox that can create the specific tool you need, beginners often ask what they can do with it. Your example is a possible answer, and others are hopefully inspired by it!


Oh %$&£ yeah.
Finally an excuse to get good with JS!

1 Like

Pure gold, Mark, thanks for these!

Thanks! Being able to organise in this way is not only useful, but I find it decreases the inherent anxiety of the job search.

1 Like

Thanks, Andreas!
I hope it will help!

1 Like