How to share papers with your students in Evernote

Although I have only supervised a couple of students during my tenure track, I already found often saying the same thing during each meeting – in particular, what are good papers to start reading about a particular topic. Since I was already an avid Evernote (get 1 month premium for free here) user, I decided to see if shared Evernote notebooks could be the solution to share papers with students. This might be also an option if you are organizing a journal club. Read on for the solution!

Initial setup 

I was already keeping track of the papers I read in Evernote – see this post on organizing my bibliography with Evernote and Jabref, but I will recap some things here. 

Remember that Evernote is not a reference manager, but it is where I store the paper PDFs and notes about the papers. Jabref is where I store the references. The only link between the two is the Bibtex key, which is how I name the note in Evernote. 

This is my paper collection i Evernote – 864 in total – and each note is a paper (or report, etc).

Each note is at least the PDF I saved (below), and perhaps some notes I made about the paper, like this: 

And this is how it looks like in Jabref:

Since there is no direct link, I might have a paper in one place but not the other, but papers that I cited in my own research in the last few years, are definitely in both.

Sharing your paper collection with others

Since Evernote allows sharing notebooks, to have a shared collection of papers all you need is to share the notebook with the people involved. For the students I was supervising, I used the “can edit” as permissions so they could also add new notes, annotate papers etc. But you could also choose “can view” option if you prefer.

Sharing a collection of 800+ papers is probably not effective 🙂 But what helps here a lot, is the tagging system of Evernote. When I add a paper to this notebook, I add several types of tags:

  • Type (paper, thesis, etc)
  • Topics (specific types of machine learning, applications etc)
  • Projects (a specific project where I might want to cite this paper)
  • “Priority” (p1, p2, p3 or p4)

I have been using the type, topics and projects for a while, but the priority was an addition after I shared the notebook. Roughly, the priorities translate as:

  • p1 – everybody in the lab should read this
  • p2 – important paper for many projects in the lab
  • p3 – relevant to some projects
  • p4 – not related to our research but more “general interest”

With these tags, you can then do queries on topic & priority. So for example if your project is on transfer learning and you want to find all papers I might suggest, the query “tag:ml-transfer & tag:p2” gets you 43 results. Still a lot, but now it’s doable to screen the results and narrow them down. 

It’s good to mention that since the notebook is originally mine, only my tags can be used within the notebook. So somebody with edit permissions would be able to add more of the tags that I use, but not add entirely new tags. 

Pros

  • The system is easy to use, paid account only needed if you want a lot of storage
  • Saves time both for me and for students
  • Less chance to miss a relevant paper
  • Everybody can use their own reference manager if they want

Cons

  • Could limit the way students explore literature
  • Limited commenting possibilities (notes from everyone appear the same by default) 
  • No true integration with a reference manager

Conclusion

This system has been quite helpful for me with several student projects. However, there are many things I am still missing, such as creating your own fields for each paper, and interacting with the annotations through a spreadsheet. (This is possible in Notion, but that is something for another post…)

However, an important quality of any system is that you actually use it. Since I already use Evernote on a daily basis, it works for me. But I’d love to know what everybody else is using for sharing literature with others – please leave a comment below or let me know on Twitter!

Organizing student projects with scrum

Project supervision is one of the many things you do during a tenure track. Since I was already interested in project organization, I did some research, which inspired my own lab scrum setup. I discuss why and how I used scrum to organize student projects, and my take-aways from the experience. To find out more, read on!  

Inspiration

At the start of my tenure track I did a bit of research about what others had recommended, and came across several interesting papers about project organization. This is a whole post in itself, but for today’s topic, here are a few papers that I found helpful: 

Patterns for Supervising Thesis Projects

Adapting Scrum to Managing a Research Group 

LabScrum: A Case Study For Agility in Academic Research Labs

The last two papers are about a technique called scrum, which is a type of process frequently used in software development (more background here). Traditionally in this process, a team is working on the same project. This is different with several students working on different projects. Another difference is the timing, which might be slower in a research setting. Nevertheless I was inspired by the ideas in these papers and decided to try it out.  

Setup with Kanban board

Although I was excited by the idea of trying a different type of organization, I had no previous experience with scrum, and didn’t want to introduce too many things that would be overwhelming for everyone.  What follows is the setup we (myself, 4 MSc students and 2 PhD researchers) used for 6+ months, where some things are loosely based on scrum, papers I read, etc. This setup has advantages and disadvantages, which I discuss later in this post.  

The main idea was to keep track of all projects jointly, via a shared Kanban board and two weekly meetings with everyone there. Typically we did the following meetings:

  • Tuesday – group update round, planning tasks (30 – 60 min)
  • Thursday – group update round  (< 30 min)
  • Tuesday/Thursday – individual meetings in time slots as needed (30 min each)

When planning tasks, we added “post-its” (I bought these reusable magnetic ones which are pretty awesome) to the shared scrum board. We initially used different colors for different types of tasks, but using different colors for different people might be more logical.  

 For me it was important that everybody created actionable, finite tasks. So, “literature research” is not OK, but “summarize 10 papers on topic X” is. When students had exams, they included studying as a task. We didn’t have guidelines for how small or big a task could be, although in practice they were probably things that could be done in days, rather than hours or weeks.  

New tasks always started in the backlog section of the board. On Tuesdays, tasks can be moved to the “in progress” section. The idea is not too have too many “in progress” tasks at the same time. 

Every group meeting was essentially a longer “stand-up”. Each person (including me!) would briefly say something about their “in progress” tasks. This involved saying something about what was done since last time (and if the task was completed, still in progress, or deprioritized), and any problems that came up. Suggestions from others about things to try usually followed. When it was clear that I needed to spend more time with the student, or some students could help each other, additional meetings were planned. This way this meeting was an hour at most, but usually closer to half an hour.

Everyone could plan an individual meeting with me via a shared calendar with 30 minute time slots. In practice, about 4 slots would be filled each week, so I would see each person at least once in two weeks (next to the group meetings). 

Alternative with Google Slides

While the initial setup had many positive points, there were two main things missing. The first was more of an overview of what has happened / is happening in the period of a few weeks. The second was the ability to show something, such as results (bugs, etc). 

For these reasons, we switched from the Kanban board to a Google Slides presentation, where each person had two slides, one for results, and one for a 6-8 week task planning and progress. The slides had to be prepared before the Tuesday meeting. Otherwise the meeting setup was mostly the same.  

This setup provided more overview, but I also missed the structure the Kanban board provided. In the end, I was thinking about a system that would have both features, but I didn’t get the chance.  

Here is an example of how one of my Google Slides looked like, with on the left the plan as I imagined it, and on the right an illustration of progress.

Pros

I’ve already mentioned a few advantages that this system had, but here is a recap. 

First, I think this is a great way to have a “lab feeling” if you are in a similar situation to me, and do not have funded projects with multiple students or physical lab space. Although the students all did distinct projects, it did feel like a team. Getting coffee, bringing cake etc also helped of course 🙂 

Second, I saved time by not having unnecessary meetings, but without compromising my availability. Further time is saved by less repetition when explaining something, and by identifying similarities across projects, where students might be in a better position to help each other. 

Third, I think this setup improved everybody’s planning skills, but also their awareness of how planning is hard. I also participated with my own projects, and I typically got the least done because of other responsibilities. I think this is important for students to see. Students seeing each other’s project plans likely gave them more examples to learn from, and perhaps a bit of accountability.  

Cons

The disadvantages of this system, from my point of view, mostly have to do with implementation. First, it takes a while to figure out how to do everything, if you try to adapt a system to fit a different situation. There is also time involved in figuring out how/where to meet (if you don’t have a dedicated space) and/or selecting which apps you want to use. 

Second, your adaptation may miss parts that you want to have. We did not have a clear separation of meetings (such as planning only, retrospective only) or project roles (such as scrum master). Perhaps these things might have felt silly at first, but I do think they would have been beneficial.  

It’s possible that this setup might not be the preferred setup for some students, who want to keep everything about their project private. I do not have specific advice for this situation. But ultimately different labs are organized in different ways, and it’s OK that this might not be for everybody.

Verdict

Overall I would say that doing this is a worthwhile experience! Do spend more time thinking about the exact implementation beforehand, particularly what meetings there will be, who will do what, and where all the plans/tasks/results will “live”. Once you have this in place, help people stay with the process for a least a month or two to evaluate if it’s a good idea. 

Acknowledgments

This post is inspired by a discussion on Twitter, started by Antony Caravaggi and continued by Christian Baumgartner, who also sent me several follow-up questions – thanks! I’d also like to thank everyone had first-hand experience of my lab organization ideas 🙂 – Ralf Raumanns, Ishaan Bhat, Tom van Sonsbeek, Rumjana Romanova, Colin Nieuwlaat and Britt Michels. Thanks a lot! 

9 ways to fail a project in grad school and beyond

This post is a collaboration between myself, and a guest author who wishes to stay anonymous. They are a researcher and PhD candidate in neuroscience, based in Europe, and in the post they are referred to as Alice

When people talk about failures, often rejections are the first things that come to mind. But what about other things in science, that did not work out? Today’s post is all about those – projects that don’t work out, and that do not end up either on your CV and probably even your “CV of Failures” (here is mine).

Read on to find out about the ways our projects have failed, during the PhD or after, AND the lessons from these experiences.  In short, here are the 9 ways to fail a project: 

  1. Inheriting a poor project setup
  2. Failing to plan
  3. Not enough redundancy
  4. Changing the scope 
  5. Underestimating the complexity
  6. No data available
  7. Collaborating for the wrong reasons 
  8. Starting too many projects 
  9. Forgetting to advertise your successful project

1) Inheriting a poor project setup   

Alice: My first project failed in a bad way. In retrospect the idea was not thought through and vague and the methodology was not sound. In fact this is what got me into trouble – as I tried to discuss these issues with my supervisor, he got angry and said that I am at no place to challenge his authority… After two years when he left the project was evaluated by a panel of group leaders at the department and found to be crap from the very bottom. The project was killed. 

Veronika: Of course a lot here depends on the supervisor. But from the researcher’s perspective there are still a few lessons here: 

  • If you inherit an existing project, verify that the objectives and methodology are clear
  • Ask questions early on, consult with others 
  • Remember that quitting a poor project early is not your failure, but might save time and stress

2) Failing to plan

“Failing to plan is planning to fail” – no post about failed projects is complete without this quote attributed to Benjamin Franklin. If you are responsible for the project setup from the beginning, definitely do not skip this step. 

This is particularly important for side projects that you might initiate next to your main research, that “shouldn’t take a lot of time”. While that may be true, in my experience things can go wrong is it is not clear who is going to be responsible for what. Or, all content-related tasks might be divided, but nobody is taking the lead on the project. Lesson:

  • Spend time defining the project timeline and contributions of all team members, including a leadership role

3) Not enough redundancy in the project

Alice: My second project failed for two main reasons. One was founded around a collaboration which was tied to one person who left. The lesson being that being dependent on certain people for connections or data is a weak spot. 

Veronika: I recognize this! I’ve experienced problems when parts of the project depended on specific data, code or tools that were not available / accessible to others. Again a lot about this depends on the PI, but for me the lesson from the researcher’s perspective:

  • Be your own best collaborator by using open science principles, sharing data/code where possible. Consider using public data or artificial data in addition to the main data, if the main data cannot be shared. 

4) Changing the scope during the project 

Alice: […] But there was more. In the course of the project, as I processed the data, the PI got ambitious and teamed up with his colleague who did similar things and was interested. He then wanted to do a much bigger comparative study and requested me to process large amounts of public data which slowed me down significantly. By then my PI left. The lesson is getting too ambitious can drown the project.  

Veronika: I’ve had similar experiences too and see it all around me – a PI invents things to try until there are “state of the art” results (similar to HARKing). I’m getting repetitive here but again you are quite dependent on the PI. What you might be able to do: 

  • Clarify project objectives and timeline in the beginning in writing (for example, type up meeting notes, and send them around after to confirm) 
  • Open science principles like preregistration might be worth a try, although this depends on your field and will also require the PI’s approval

5) Underestimating the complexity of the project

Alice: My third project did not fail as such but rather faded away., which is a failure of a kind. It was a collaboration with a postdoc who was an expert in the field and had a nice idea. The problem was that the implementation and most importantly interpretation of the data turned out to be much more difficult than she had anticipated and it required more input from both of us than we pledged for. A mistake here I’d say – wrong estimate of the complexity and resources available.

Veronika: Agreed – I’ve had several nice ideas that sounded great when brainstorming, but in the end did not receive enough attention to progress. I have a lot of thoughts about these which would warrant an entire blog post. Still, I wish I would have been better at planning my time. My lessons would be:

  • When agreeing on a new (side) project, agree on how much time you can put into it. I think this is hard to do, but if you did have this agreement in the past, the future you will have an easier time letting go of the project. 

6) No data available

Alice: The fourth project failed when I learned that I can not get the phenotype data on the cohort I worked on and at this point there was nothing I could do. The data was blocked due to disagreement and issues between my PI and the competitors with whom initially it was supposed to be a collaboration. I don’t really have a recipe how to help that, it is one of the things that I have little control over. 

The fifth project failed for a similar reason. But this time it was because we were not allowed to collaborate with the boss of our PI (who has a cohort with the exact phenotype we need) who did not want to publish with the previous boss in view of the career. We were thus pushed to prey on the public data repositories which a) did not have such precise phenotype we needed b) required downloading and low-level processing of large amounts of data which was very straining and hard for a single person and given resources. We managed with the published subset of the data and we found nothing. I spent almost a year working on it. 

Veronika: This overlaps a bit with my previous ideas about open science, but in this case there’s not a lot somebody in your position could do other than use public data. Lesson: don’t blame yourself for decisions of your PI!  

7) Collaborating for the wrong reasons

Alice: A friend of mine went to a prestigious university to collaborate with a research group there for a few months. He worked very hard, but faced open racism and bullying. The conflict escalated and the project was tabled. Instead of support, my friend’s supervisor was unhappy with him. This is also a situation which is hard to foresee. But perhaps trying out collaborating remotely first and building relationships slowly would be a safer bet.

Veronika: Sounds like a terrible experience for your friend! Agreed it is a good idea to try out collaborations first but perhaps that was not possible. There needs to be not only a research fit, but also a safe environment.

 But on the other hand, the environment alone is also not enough – even with people who really want to collaborate, sometimes it just doesn’t work. Getting along well with somebody doesn’t mean your research project will be complementary as well. My lesson would be:

  • Know who you will collaborate with, and aim for a combination of research fit & good environment

8) Starting too many projects

Veronika: A “favorite” reason why some of my projects failed, is starting too many projects and then not getting back to them. Often this would happen if I was waiting for reviews on a paper, and already planning the next project. But when a major revision would come in, I would drop new ideas to revise the paper, and once done, fail to get back to the new_idea.txt. Side projects could also end up in this category. 

In a way, this is a combination of “failing to plan” and “underestimating the complexity”, but on a larger scale. My lesson from this:

  • Keep track of how many projects you’ve agreed to do, and what stage the are in (for example with a Kanban board)

9) Failing to advertise your successful project

Veronika: Congratulations, you finished the project! What now? While this is not technically a failure, there’s still ways to increase the success of your project.

Once you do finish a project, you might not give the project output enough attention. It’s easy to become focused on getting a paper for the thesis, especially if your PI is pushing you to. So a natural response might be to just move on to the next project, leaving the published paper as is.

But maybe it’s good to pause, and give that effort more justice by sharing the paper with your colleagues, submitting a poster about it to a local conference, or writing a thread about it on Twitter. I know I am guilty of this – despite my rather active Twitter presence, I haven’t tweeted about my research this year. The lesson is: 

  • Give your finished projects (and your hard work!) the attention they deserve! 

******

These were the 9 ways to fail a project during your PhD and beyond! These are based on Alice’s and my experiences, but there are probably more reasons there.

Let us know which ones are recognizable, or if you are missing any failures that can happen along the way. The best way is to leave a comment below so they reach both of us, otherwise as usual you can reach me (@DrVeronikaCH) on Twitter!  

Tenure track in the Netherlands

By popular demand, today’s post is about my tenure track position which I started 3 years ago. Although I intended to give an update of how my tenure track is going, there’s a bit of background that’s relevant to share, so this post is only about my experiences when I started. Also, recently I’ve had a few questions from future tenure trackers, so I’m sharing my answers in case it is useful to others.

Starting conditions

As I’ve also explained in my “student or employee during your PhD” post, all academic positions in the Netherlands work with fixed pay scales. You can find these here, below I also added a screenshot of some of the scales.

These numbers are all before tax and per month. Various secondary benefits also apply.

Assistant professor positions are in scale 11 or 12. Typically a starting assistant professor would be in scale 11, and in scale 12 after tenure. The Dutch Network of Women Professors (LNVH) reports that 50.8% of women assistant professors are in scale 11, versus 40.8% of men.  

When I started at TUe, I was initially offered scale 11.0. However, I had already been in scale 11 as a postdoc, and my institution was a medical center, with slightly higher pay scales. Due to this I was offered 11.3, which just matched my previous salary, and which I accepted.   

There was no start-up package – I think this in general isn’t a thing in the Netherlands, although I do see this being offered more frequently now.

Contract & tenure conditions

The tenure track contract is a temporary contract for 5 years. After 4 years there is an evaluation which decides whether you get tenure or not. If yes, you get permanent contract, if not, you are still employed for a year. There is also a (less formal) midway evaluation after about 2 years, to prepare for the real thing.

The criteria for evaluation are described in various documents. I received some general criteria on what is important for the university (for example “supervising students”), and a department-specific interpretation of these criteria. In the context of creating a personal development plan for the tenure track period, I did receive some quantifiable criteria too, of what you should aim for within 4 years:

  • Significant progress in obtaining the teaching qualification certificate
  • Responsible instructor for 1-2 courses
  • Good teaching evaluations
  • Supervision of at least 2 MSc and 4 BSc students
  • Co-author of at least 5 peer-reviewed publications in high impact, relevant journals
  • Written statement from chair about contribution to getting funding
  • Significant progress in increasing external visibility
  • Collaborations with other departments, hospitals or industry
  • Successful (co-) supervision of multiple PhD researchers
  • Examples of strong leadership
  • Examples of strong communication skills
  • Examples of independence and responsibility

A bit more quantifiable, but still open to interpretation. In my own personal development plan I translated these as follows:

  • Get teaching certificate
  • Setup and teach a first year course, co-teach in a third year course, later start developing course closer to my research
  • Supervise at least 2 MSc and 4 BSc students
  • Co-author of at least 5 peer-reviewed publications in high impact, relevant journals
  • Apply for 2 medium-sized (1 PhD or postdoc) grants per year
  • Apply to small grants, for example for workshops, when possible
  • Give talks at (local) conferences, or invited talks if possible
  • Setup collaborations with other departments 
  • Co-supervise a PhD researcher (if funding)
  • Outreach about academia through blog and Twitter 

Also not entirely quantifiable, but I also left out a few specific details here (examples of papers, collaborations, numbers of blog/Twitter followers etc).

The (midway) tenure evaluation moments consist of submitting an update of this plan and a recent CV, and then giving a presentation about your achievements to a committee of 3-4 professors.  

This is all I wanted to share for the first part of this topic – next time I’ll talk about how things are going so far. If you have any questions about this post, or anything I can address next time, please comment below!

Firsts: publishing a preprint before submitting the paper

Although I’ve been using preprints since 2013, recently I had a new kind of experience with preprints. Whereas before I would post the preprint upon submitting it to a journal, for the first time I decoupled the two events, and submitted the preprint several months ahead. In this post I reflect on this experience. 

Why

My choice was initially practically motivated. The idea for the paper was born in 2016, but since moving to a new position, I’ve been too overwhelmed to do any writing, so at the start of 2018 the paper – a survey of a magnitude I haven’t attempted before – was far from finished. I wanted a deadline, but I still wanted to be able to update the paper if needed. So a preprint seemed exactly what I needed! 

Timeline

I set the deadline to April 2018 and for the next weeks, worked towards getting the draft to a readable shape.  In April I submitted the preprint to arXiV. Differently from submitting journal-ready preprints, this time I put a piece of text inside the preprint, saying it is not the final version and I was happy to receive suggestions. At the same time, I emailed a few people with the URL asking for comments, and I asked for feedback on Twitter. This felt scary to do – I don’t think I felt as nervous with any of my other papers.

Response

Despite my fears, the experience was positive – I got a lot of constructive feedback which helped me to improve the paper. So in September 2018, I submitted the updated preprint to a journal. In the cover letter, I mentioned the Altmetric statistics of the preprint (I later discovered this is sometimes frowned upon).

Next to the traditional list of suggested reviewers, I also provided several names of people who I had no conflict of interest with, but who had commented on the preprint on their own. I figured that, since they had already read the preprint, they might be willing reviewers. Of course I disclosed this in the letter. 

Publication

The reviews came in about 8 weeks later – an absolute record for me, as during my PhD, regularly waited 6 to 9 months for reviews. The reviewers were constructive, and suggested a coufple of revisions. After revising, the paper was accepted in January 2019 – by that time already gathering a few citations and benefitting from the preprint bump

Verdict

Given this experience, I would definitely post a preprint online without submitting it to a journal first, and not necessarily because of more citations. I realized that me feeling worried about it is a good thing. I could be sure the paper would be seen by a larger group of people, who had an incentive to comment, since they could still influence the paper. This is different from convincing a few reviewers, and then maybe not having the paper noticed afterwards.

Since this paper, I have also been part of another paper that used the same strategy (and is currently under review), and I noticed other preprints putting similar “please email us” messages on the front page. It seems there is a need for interacting with preprints differently – I’m looking forward to what different initiatives like overlay journals will bring.

CV of Failures vs Shadow CV

If you’ve been following me for a while, you know that the “CV of Failures” or “Shadow CV” are a recurrent theme on my blog and on my Twitter timeline. In this post I discuss why I think the two concepts are actually quite different, and why this difference is important. 

CV of Failures

The CV of Failures, originally proposed by Dr. Melanie Stefan, is mostly that – a list of things that didn’t work out. Most often I see failures interpreted as “things I tried to do but didn’t succeed”. This category includes rejections of jobs, grants and papers. Although these failures are hard, I think they are not very personal because they depend on both everybody else who applies, as well as everybody who evaluates you. 

Much less common is to include things that are more personal – something you just didn’t do (but should have). It’s often not your fault, because of how academia is structured – but in retrospect, you would have done these differently. This category includes focusing on the quantity over quality, not taking opportunities out of fear and being a bad mentor to others. Even more personal, it’s neglecting your health or people around you – although I haven’t seen many examples of people sharing this. 

Shadow CV

What is a shadow CV then? To me it is larger than the CV of Failures. While the CV of Failures focuses on things you have done (or didn’t do), there are many more things that influence where your CV or CV of Failures are today. It’s all the additional challenges faced by one person, and all the privilege enjoyed by another. 

There are efforts to take parts of the shadow CV when evaluating people. For example, in the Netherlands time off due to parental leave or illness can be listed on a grant application. But this is limited in scope and does not include, for example, chronic illness, financial insecurity or family problems. Even if you are lucky to work in a place where people are supportive – and I have been – these things are invisible to somebody deciding whether you belong to the top 10% of researchers who deserve funding.  

But the shadow CV is not only the challenges. It is also all the things you are proud of but that are not on any CV, like finishing a paper despite having a difficult year or a thank you email from somebody who’s read it. Regardless of what your reviewers say, don’t forget that these are the true successes.

 

My biggest mistake and what it taught me about the academy

One of the most read posts on this blog is “7 things I wish I would have done during my PhD“. Although none of the advice there is surprising, it seems important to hear stories about mistakes, without “how to” one-size-fits-all rules attached to it. So when Times Higher Education invited me to write about “My biggest mistake & what it taught me about the academy”, I didn’t have to think twice.

In this piece I talk about not realising the importance of mentors early on in my academic career. I can view this mistake as something that led to a CV that is suboptimal, at least in the eyes of my reviewers. But now I also realize it’s made my journey much more interesting, and I wouldn’t trade what I was able to learn in this process for a few more high impact factor publications.

I haven’t yet decided on what the best trade-off is, but would love to hear from you! Should your mentors prepare you for everything? Or do you need to experience some mistakes yourself? Let me know after you read the article, in a comment here or on Twitter!

My tenure track job search

This topic has come up several times on Twitter, in particular with #TotalToTT. I always participate in these conversations because I remember finding it so important to read stories of others when I was applying for a job. This is a more detailed summary of what I usually try to say regarding my search for a tenure track position. Note that since I was applying in Europe, positions are advertised continuously, so there is not really a “job season” like in the US.

Summary

I applied to a total of four jobs, interviewed for three, and got offered one – the position I have now. This sounds easy especially if you see the stories of people applying to 50, sometimes more than 100 positions.

It didn’t feel easy at the time. I already had problems with my mental health and spent some time on sick leave because of this. At the same time, I was also (unsuccessfully) applying for grants. Although I was not too worried about job security in general, academia already felt as an important part of my identity and I dreaded leaving.

Applying

The first tenure track job I applied for was the Delft Technology fellowship, a fellowship only for women I would compete with other women from all disciplines. I realized this application was a long shot, but since the fellowship only was given every two years, I thought I had to try. I discussed my applications with several full professors in Delft, who encouraged my to apply. But long story short, I quickly got rejected.

I then applied to two jobs in the UK. Although in my field there are quite a few jobs, I was quite selective with where I tried to apply. For example, I chose only universities that were neither too low nor too high on university rankings, only cities where I could see myself living, and only groups where I was getting a good impression about the lab culture. For both jobs, I emailed ahead to ask if it made sense for me to apply, since I wasn’t sure about the fit of my research. The responses were enthusiastic! These lead to informal Skype calls, and then invitations to interviews. This was so important for my self esteem since I felt like I was on the right track.

Interviews

I did a lot of research on each place before the interview – next to general “how to interview for academic positions in the UK” advice, I researched what other people in the lab did, looked at course syllabi and even read the strategic visions of the universities. What I felt was helpful for me, was to write down some answers to questions I was expecting. I felt that overall the interviews went well, however, since Brexit happened, I was myself unsure about willing to move to the UK. I wasn’t offered either job, but I received good feedback so overall I was happy with the process.

My deadline to start applying for non-academic positions was getting closer, when I somewhat by a combination of lucky circumstances heard about my current job. To prepare I did similar things as for the other interviews, but since the position was in the Netherlands I felt like I had an advantage. A day before my deadline I got the phone call that I had the job!

Verdict

I felt excited and relieved, but also scared and guilty about getting the offer. It’s strange for me to think that this is already almost two years ago, because I still do largely feel the same way. I am aware that luck and privilege played a big part in this process.

On the other hand, I do think that the way I prepared my CV and contacted the groups in advance were also helpful. In the end, perhaps having only a few applications was an advantage. I do think this is individual and will vary a lot per field and country. If I could give any advice, I would still encourage people to apply, but talk to others more about how much time and energy you should invest.

Reader Q&A: choosing your advisor and topic

In today’s post I’m answering some questions from readers of this blog, on choosing an advisor and research topics. As a caveat, for me both things just “happened” so I am not the best person to give advice, but I did think of some tips that could be useful.

1. How to choose your advisor?

I think the lab where you will do your PhD is the most important factor for choosing a particular position. A large part of this is the advisor, but also the general atmosphere in the lab. That being said, it can be difficult to figure these things out in advance, if you are not already familiar with the lab. Nevertheless, there are a couple of things you can do:

  • Do people in the lab have social media accounts? The absense of social media probably doesn’t tell you much, but if one or more people have accounts perhaps you can learn a bit about the lab culture.
  • Look at publications lists – do the students get a chance to publish? Are there publications with multiple students, indicating more collaborations in the lab? Do students publish on their own topics, or only extend the work of the advisor?
  • Look at videos or slides from the advisor’s talks, if you can find any – do they credit their trainees for the work?
  • Get in touch with current or former trainees of the advisor – how is/was their experience in the lab?
  • Ask questions during the interview – what are the expectations of students in the lab? Are there any group meetings (such as a journal club) or other lab activities?

2. How to choose a research topic?

In the Netherlands (and several other countries in Europe) the topic will already be somewhat defined when you start a project. However, within that topic you should still have freedom to explore different questions. Here are some things that worked for me:

  • Just start somewhere. Read papers and implement them, and be critical about what you see. Are there some limitations, for example datasets that would not be suitable for the method?
  • Start writing as soon as possible, for example your thoughts about the papers you read. Are there any trends you start noticing?
  • Talk to others, both within and outside your field. Explaining research to others can often bring you to new thoughts
  • Ask yourself, “Am I building another hammer instead of investigating whether the problem is a nail?”
  • Ask yourself, “If my work was going to change a sentence in a textbook, what would that textbook/sentence be?” (Paraphrased from talk by Robert Williamson)

As with everything on this blog, my final piece of advice is – don’t stop here, but search for more different people giving different types of advice. If you know of a great blog post, or have your own advice to share, please comment below!

Quick and easy posters in LateX

Going to a conference and have to print a poster? Here is my tip for doing this as efficiently as possible.

Since my first conference, I have made quite a lot of posters (and printed them all on fabric) The first time this was very time-consuming, but the time I spend per poster has decreased over time. My new record is from the last conference. I had scheduled the task of creating the poster on my calendar – by default all events are one hour long. But by the end of the hour, I had not only made the poster, I had also already ordered it from my favorite vendor. All I had to do was wait for the poster to arrive.

As a disclaimer, I do not have the best posters, so if you want to win the best poster award, this is probably not the advice for you. But my posters do the job. So far my experience is that it’s more important how I talk about my research while I’m at the poster. That’s 20% of the work that achieves 80% of the result. The poster can fill up the 80% of work that achieves the other 20% – with all the other things we need to be doing (writing?) the decision on not spending too much time on it is not so difficult.

My “secret” is to use the same LaTeX template and the same structure for every poster. The template takes care of the layout and doesn’t let the poster get too crowded, and the structure guides me in what content I need to add.

I’m sharing two zip files with source files for my posters – one with a TU Delft, one with a TU Eindhoven template. When I was at Erasmus Medical Center, I could not find a LateX template, so I modified the TU Delft one to use different logos and colors. These templates were not originally made by me but allow modifying/sharing as long as the copyright notice is included. Please do the same if using the templates.

Cheplygina et al – Characterizing Multiple Instance Datasets (Poster, TU Delft template)
Cheplygina et al – Exploring Similarity of Medical Image Datasets (Poster, TU Eindhoven template)

%d bloggers like this: