This is the second post of a series I’m writing about dialogues from my company’s internal Slack group. You can check out the first one here.
If you’re joining us now, we run a private Slack group that’s half experienced data scientists, and half aspiring data scientists. The aspiring half tends to ask great questions, and the experienced half tends to give great answers.
The question we’ll look at today is: When you’re actively job hunting, how should you divide your time between the job hunt itself— applying, interviewing, networking — and keeping your technical skills sharp?
This question comes up a lot. It’s very hard to balance both! Luckily, there are great tactics to make this easier which you’ll find in today’s conversation.
Jiri Stodulka asks:
I’ve been focusing on the job hunt for about two months — and as a result, I haven’t done a lot of coding in that time.
I was doing some EDA yesterday and I was shocked to discover that I had to Google everything to get it done — I’d forgotten a lot of the syntax.
How do you deal with this issue? How much do you code these days — assuming you’re actively job hunting?
Jeremie Harris’s answer:
I usually recommend separating your week into something like 2 days’ skill maintenance and 5 days’ applications and projects when they’re hunting actively. But it varies from person to person.
One common way to divide it is to do project work on weekends, and job applications and interviews on weekdays.
Yes, the solution is to explicitly schedule time to code. The right schedule for everyone will vary.
If the weekday / weekend split doesn’t work for you, one great approach is to do a minimum amount of coding every day — like 15 minutes — and scheduling it at a specific time. This is a kind of personal habit trigger called an implementation intention.
Karthik Subramanian’s answer:
I actually spent quite a bit of my time in this state before I got hired. I was juggling a full time course load, personal projects, and job search.
Along with semi-regular practicing, what helps a lot is documentation. Anything you practice, you need to document.
It’s not enough to practice to code. You should document your work well enough that you can look back and immediately go, “Yeah, I sort of have an idea how to go about this.” I remember doing a ton of problems on LeetCode for example — and a lot of the work went to waste when I wanted to revise it for an upcoming interview, because I hadn’t bothered to document my solutions.
Documenting stuff also gives you an easy way to look things up without relying on Google Search in that moment, as you’ve already done the hard legwork. I like to add the best link or two that helped me move quickly to the solution, so it’s much faster the next time around.
I thought I was the only one who suffered from this! I always keep in mind the “forgetting curve” — so I spend more time coding than applying to jobs:
Of all the tasks you have to complete — job applications, coding projects, etc. — some of these tasks give you energy, and some drain your energy. You can use the energy-giving task as your reward for completing the energy-draining tasks. This is like eating your vegetables before your dessert: Small, consistent rewards create and maintain good habits.
For example, you might enjoy writing software and analyzing data, more than you enjoy sending out job applications.
Then you can set yourself a minimum target for job applications (e.g., one per day) and a specific time slot during the day when you work on job applications (e.g., 6–6:30 pm). After you send your day’s job application, you’re allowed to work on your coding project.
Find a job in data science on this site. You can work fully-remote
I’ll probably be posting more of these conversations in the future — if there’s a topic you’re especially interested in, ping me on Twitter!
“How to keep your skills sharp while data science job hunting”– Edouard Harris Tweet