Following up on some recent (and less recent) discussions on Twitter, I decided to share a few of my applications for academic positions. Although the tips here are specifically about the cover letters, for context I am also adding the CVs that I applied with at the time. Depending on the application, other documents may have been required as well.
I am sharing three applications from different periods of time:
2010 when applying for my PhD
2014 when applying for a postdoc
2016 when applying for a faculty position
These led to me at least getting an interview (see CV of Failures) and/or also getting the position. You can find them all in a single zip file here.
A bit of a disclaimer – I do NOT think these are the best examples out there at all, but I’m sharing these for transparency, as realistic examples. I also have to note that I have likely benefitted from applying to places “close by” in my network.
Cover letter structure
When I write letters – and I have tried these with the letters above, I try to use the following structure:
General introduction of the letter – who am I, why am I applying
My research background and how it fits the position
Another thing that is special about me
Summarize why it’s a good fit & plans for the future
Often this translates into a paragraph per bullet point, but as the examples show there is some flexibility there.
As much as possible, I try to address the person who is going to read the application, using their correct title. If you are not sure, I would go with “Dear committee” since that is the most inclusive version.
Above I have highlighted which parts I think are the most important. All of it is about personalizing your letter to the position. Researching the website of the lab, the long-term vision document of the university, etc., can give you a lot of information on what to write.
It is also important not to write too much – although I highlight a few things from my CV, I do not repeat everything in detail. And, I think it is good to write in a way that sounds natural to you. Although I think these are not the best letters at all, I do still find that I sound like myself, even though one of these is from 10 years ago! Note that I do NOT have an in-depth story of how motivated I am to solve a major scientific problem, because that is just not me.
Although I do not know it for a fact, I think my “another thing that is special about me” has helped my applications a lot. The exact contents have evolved over the years, but overall I think I tried to focus on activities that can be seen in a leadership context – from organizing student events to outreach on social media.
That’s all I have to say about my cover letters! I hope these documents are helpful – if you have any questions please leave a comment or get in touch on Twitter!
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!
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.
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
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
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!
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!
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:
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/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.
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.
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.
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.
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!
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:
Inheriting a poor project setup
Failing to plan
Not enough redundancy
Changing the scope
Underestimating the complexity
No data available
Collaborating for the wrong reasons
Starting too many projects
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!
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.
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.
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!
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.
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!
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.
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.
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.
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.
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.
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.
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!
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.
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.
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.
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!
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.
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!