I got a new job. I'll be starting in a few weeks. I want to talk about the job search process since it's been a while since I job hunted (I was at Optoro for almost five years).
Some stats
- Platforms I used to find opportunities: Glassdoor, LinkedIn, Hired. the
#jobschannel on PyLadies Slack, a couple friends - Applications I submitted "cold": 48
- Applications I made via responding to recruiters: 10
Almost every position I applied to was titled Senior Data Scientist, though there were a few (Senior) Machine Learning Engineers in there too.
The "average" interview process
The most common interview process was:
- Recruiter screen (30 min). The questions here were almost always: what's your background? What are you looking for in a next role? What do you work on currently?
- Tech screen (30 min - 1 hour). The majority of these were live coding screens on Coderpad.
- Hiring manager call (30-45 min). Meeting the potential boss, or boss's boss.
- Take-home assignment (many many hours). Sometimes instead of the code screen. Sometimes in addition!
- Final round (1+ days). These often included an additional tech screen/live coding, one or more case study/technical deep dive interviews, and at least one behavioral/culture interview.
Cracking the coding interview... for data science
tldr: Listen to the question. Plan out your code using pseudocode/a bulleted TODO list that your interviewer can see. Execute on that TODO list. Practicing for performance anxiety was more worthwhile than grinding Leetcode.
The dreaded live coding interview!
I dreaded this step when I started applying, since I had had bad experiences previously: namely, having incredible performance anxiety, writing code that would run but still being rejected. Once I "cracked" this part of the interview (and disclaimer: ymmv), I then started passing these interviews... even when my code had errors or I got stuck. I've been through about a dozen of these, so my experience may not representative.
The live coding screens varied widely. I went through the following:
- "Do Python and SQL stuff, either 'whiteboarding' on Coderpad or 'open book' (i.e. you can Google syntax)." (most frequent)
- "Do data with Python but pretend you have no
pandas. Closed book." - "Use Google Colab, while screensharing, while I watch you use
pandas." - Big-O notation/algorithms and data structures.
When I started the job hunt, I was a bit frantic about how to prepare for these. I was at a loss. Should I spend an hour a day working my way up through LeetCode/HackerRank difficulty? Would I have to take an Algorithms & Data Structures online course? And so on.
What I've concluded, having now gone through this round successfully several times, is:
No, Data Scientist applicants were not expected to know big-O notation
Only one code screen (out of ~15) asked me about this, and I flatly said I didn't have a CS undergrad background, had never taken Algorithms and Data Structures, but was willing to take a crack at it. I basically mused aloud about memory stuff (thanks, CS50!), the interviewer nudged me forward, and it was fine. I ended up getting an offer from this place!
Performance anxiety prep is as important - or maybe more important - than code prep
In my case, the nerves were real. I went through a few code screens where I was extremely nervous. I would jump in, frantically write spaghetti code, hit small syntax errors, get flustered, and then have a brain shut-down.
They always advise you to "show your work" and "think out loud"; and my code and thoughts were a jumbled-up, gibbering mess. I would invariably get rejected after these screens, which hurt. I felt indignant. "I've been deploying Python to production for 5+ years! Of course I know how to zip two lists!" I'd think, annoyed with them and angry at myself the next day. But the anxiety crept into my practice as well. When I would sit down to do some Leetcode problems, I'd be hit with it: a faint voice in my head, screaming, You're too stupid for this!
It took me a few more failures before I realized: gosh, maybe I'm not stupid, I'm just nervous? And maybe I could try to be less nervous? In college and grad school, I used to have awful performance anxiety; I've had panic attacks before and during (!) exams. It sucked. Thankfully, after grad school, I learned a technique that really helped: visualization.
Basically, before the Big Day, I make a bulleted list of all the activities of that day: waking up, getting breakfast, shower, commute, etc. I then have two columns: "pre" and "post" anxiety, out of a scale of 1 (not anxious) to 10 (full-blown panic). I sit down with the list and force myself to really, deeply visualize each part of the day - each item of the list. I mark how anxious that specific image makes me: eating breakfast JUST HOURS BEFORE THE CODING INTERVIEW. Opening the Coderpad link. Saying "hi" to the interviewer. And so on. If my "pre" anxiety exceeds 5, I stop the visualization and do some calming breaths. I then record my "post" anxiety - "post" meaning "after I tried to calm down a bit". If I get back under 5, that's fine. If not, that's fine too.
I do this repeatedly before the Big, Scary Event, maybe 2-3x on average... and it's worked wonders! It was the way I got over panic attacks before public speaking. It was the way I "cured" my fear of flying. And I realized - belatedly - that it would help me during this interview process! While I never properly panicked, I did realize that nerves were getting in the way of showing my skills. The visualization exercise helped tremendously. To the point that, by about halfway through my job hunt, I no longer felt anxious before code screens... or any of the other interviews! 😱
This was such a strange experience - interviewing while totally relaxed - that I was suspicious of it. Surely nerves also help? But in the end, I think it was a good thing, to be so relaxed. It helped me think much more clearly on the spot, especially when interviewers tossed tricky questions at me during the case study interviews. And I ended up really living the growth mindset: suddenly, I hungered for those hard questions and was disappointed when an interviewer didn't challenge me! I felt like overqualified drummer. And I think this intellectual restlessness - challenge me! - reflected well; more than one interviewer seemed pleasantly surprised that I said I enjoyed getting stuck (I did!). It also gave me a much better sense of what working with that person would be like (since I normally don't have performance anxiety while in some random meeting with a work colleague I've known for a while).
So, yeah. Anxiety + visualization = relaxation. And relaxation = growth mindset!
Another tip: slow and steady beats fast and "clever"
I was once invited to attend a conference (at Harvard!) and then - surprise! - ended up being told "my panel was next". Cue horror.
I sat myself at the end of the quite-long panel table and waited while the other panelists introduced themselves. While they did - and my mind was spinning - I noticed that (a) I couldn't follow their introductions easily, whether because they spoke softly or in a roundabout way or whatever, and (b) audience members had similar looks of confusion or glassy-eyed distraction. I resolved that, since I had no idea what to say on this panel, I could at least speak very loudly and clearly and simply, just introducing the research org I worked for (and was, apparently, now representing) and the work we did. This went over swimmingly.
It was a lesson I forgot. But I re-learned it during these coding screens. Just speaking slowly, clearly, and simply goes a long, LONG way. Your interviewer is human. They can't read your mind. They likely know very little about you - maybe they've looked at your resume. Even then, likely only briefly. So just introducing yourself clearly, repeating your understanding of the question prompt back to them, and writing down - in Coderpad - the list of what you're going to do... oh man. That seemed to go a LONG way. I sometimes just wrote SLOW DOWN on my whiteboard (out of sight).
Before this realization, I would feel nervous as heck while the interviewer introduced themselves and talked in a leisurely way about the interview's structure. I remember thinking, "Hurry, I need all the time I can get! Oh man!!" After my "go slow, be obvious" realization, I would intentionally take it slow - I would not rush through my intro, I would not try to scan through the entire question prompt as soon as they pasted it in Coderpad. I would sometimes just take a moment to make a joke that felt funny. Basically, I was not in a rush. And then, once I got around to actually answering the question, I would do something like:
# Q: [some easy-level Leetcode Python question]
def my_answer(some_input: some_type) -> some_other_type:
"""
TODO:
- create an empty array
- apply machine learning to the elements
- return some data type
- do other things
"""
Meaning: I very methodically (1) defined some function and type-hinted the heck out of it (look, interviewer, I know typing!), (2) made some docstring, (3) filled that docstring with my overkill thoughts. When I was learning how to code in Python, I remember I had to write out my plan in plain English or pseudocode. As I got more comfortable, I stopped needing to plan. WELL, NOW I AM BACK TO PLANNING. And it has made me much more effective. Again, my sample size is small, but once I started doing Angela the Sloth Candidate Who Loves Checklists, I passed all my code screens.
Cracking the knowledge interview (case study, tech deep dive)
tldr: Anki! OMG, Anki.
Actually, my math above is wrong. It should be: relaxation + Anki = growth mindset. I, like a lot of other people, read Carol Dweck's book and was like, yes. That sounds great. Of course. I should be growth mindset. But while the book made me aware of "fixed mindset" thoughts, it didn't necessarily give me a sense of how to actually, ahem, ~live the growth mindset lifestyle~.
At the same time, a year or so ago, I discovered Michael Nielsen's amazing post, Augmenting Long-term Memory, where I learned about spaced repetition and the evidence-based way to build memory (aka knowledge). After reading that post, I had messed around with the Anki app for a few weeks, but it didn't stick. I made the classic beginner's mistake of importing other people's flashcard decks and using those. This year, early in my job hunt (thank goodness!), I decided to ditch the imported decks and start making my own Anki cards: specifically, I started working through the lecture slides from Harvard's CS109A and CS109B courses - which I took in 2016 and 2017, respectively. Doing this was a game changer. In so many ways!
First, instead of vaguely remembering that, oh yeah, regularization is a thing... oh, right... Now I was like a robot that could recite the specific loss function that Lasso and Ridge regressions use.
Second, as I started "putting things in my head" (which is what Anki feels like; "memory is a choice"), I started to get what Nielsen promised: I started seeing connections where I hadn't previously. I developed a deeper intuition. I saw the patterns!
Third, as I started to "know" (remember) more and feel more confident and creative with that knowledge, the fixed mindset image of a "smart person" started to crumble. I've often been deeply impressed when someone rattles off some random, exotic-to-me mathematical formula. A work colleague saying "Jacobian!". Someone else integrating e on the fly. Whenever this happened, I would think "wow" and be both impressed and crushed. I'd think, I'll never be that smart.
What I didn't realize was: I was defining "intelligence" as "knowledge" - as memory - of things I didn't know. No one impressed me if they said something I also remembered; they impressed me when they said something I thought I should know, but didn't remember in that moment. And when I started using Anki, and memory became a choice, I realized: I could now choose to remember that as well. And anything else I thought was useful! And Anki is... a flashcard app! There's no special magic to it. It just leverages how your brain works: flashcards on a schedule to fight against the forgetting curve .
The realization that, with "one weird trick", I could suddenly know all of these things... well, the ceiling of possibilities just went way up. And my life has gotten so much richer. And now I really am, deeply, growth mindset. I think this directly impacted my desire to get hard interviews. I had a few interviews that were lightweight and easygoing, for roles that nonetheless seemed amazing. Past Angela would have counted her good luck. Current Angela was immensely disappointed, to the point that I worried those roles - even though the teams and projects seemed great - would be "too easy". I started telling interviewers this, and really meaning it: I want hard problems. Even the overall "basic data science domain" - once I completed the Ankification of CS109A and CS109B - seemed... small? I was like Marlin: "3 stripes? that's all I have?"
Fourth, I am finally going to put linear algebra in my head. FINALLY. And I purely mean an engineer's/craftsperson's toolkit knowledge of linear algebra, not the proofs. Maybe this is foolish. But I'm excited.
To take-home or not to take-home
Before I became a parent, I loved take-home assignments in hiring processes. I had ample leisure time to work on them! They removed performance anxiety. They felt more "honest" since, after all, they're a more accurate representation of what working with a person would be like: it is rare for my colleagues to stand over my shoulder, give me a riddle on Coderpad, and then watch me code. It is much more common for us to discuss some problem, often via Slack or standup, and then for me to come back with some Jupyter notebook.
I still think there's a benefit to take-home assignments - due to that last point above - but I think keen candidates will spend 2x the recommended time on them. I had three take-home assignments during this job hunt and I spent 7, 3 and 4 hours on them, respectively. I was rejected from the ones I spent more time on. At the time, I thought, well, okay, I probably spend about 7 hours prepping for a code screen. But that's not true anymore. Once I cracked that screen, I basically didn't prep for it. Once I cracked the performance anxiety, I just needed to leverage my existing Python muscle memory. And while a job hunt is, by definition, an enormous amount of energy spent on things that don't materialize, the 7 hours I spent on that one assignment still stand out as... particularly wasteful of my time. Specifically, I hadn't met anyone on the team yet, had no idea if me and the potential boss would gel well, had no idea what the specific projects I would work on would be. In other words, I was investing a lot of my time on something that might have ended up not even being a good fit.
That information asymmetry, coupled with the opportunity cost of my time as a parent, means I've cooled down a bit on take-home assignments. I still like them when I'm the one doing the hiring: they give you good insight into a lot of things - the candidate's enthusiasm for the position, their knowledge, their creativity in applying that knowledge. Even stuff like code style, written communication (I'm a big fan of well-written Jupyter notebook Markdown cells.) Also, take-home assignments are standardized (everyone answers the same prompt) and much less subject to the random variation of a bad interviewer, bad day, etc. The whole hiring team can look over and discuss a candidate's assignment at their leisure too.
Hmm. Okay, well now I've convinced myself again that take-home assignments are a better option. But maybe a code screen + a case study accomplish much the same differentiation, sacrificing a bit to variance/luck? Either way, I did appreciate when hiring managers stressed, repeatedly, not to take more than X hours on an assignment.
Final rounds, interviewing them
The only thing I'll say about the final rounds - which were almost uniformly grueling, given the time investment (usually they were 4-7 hours, spread out over one or two days) - is that this was often the only opportunity I had to meet more of the people I'd be working with. And, thus, to interview them. I do take this seriously, since job offers need to be about a good fit on both sides. As one friend noted, a job hunt is 6 weeks of pain - but being in a "wrong fit" job can be much more painful and for much longer. So, as much as the emotional rollercoaster ("do they like me? they like me! they like me!") sometimes clouded my ability to put the brakes on and ask harder questions, I did try. I had to consciously make an effort. It's worth it!