Realities of a Data Science Job Search
I’ve been waiting for some time to publish this, but I wanted to write about my experiences interviewing for data science jobs. Here’s my story, I worked at Booz Allen for nearly seven years but I felt it was time for a change. I very much like Booz Allen as a company and if anyone is interested in working there, please don’t hesitate to contact me. But I felt I was ready for different challenges and started looking for work elsewhere.
Now that I started a new position, I thought I’d share some observations about what I learned from interviewing at numerous companies. I wasn’t tracking how many companies I interviewed with, but it was a lot. I have a lot of government experience and got a number of offers from government contracting firms. However, I came to the conclusion that in terms of career progression, joining another government contracting firm was not what I was looking for.
So here’s what I learned…
Before you start putting yourself out there, really put a lot of thought into what you’re looking for in a position. Really think about all the factors such as company culture, location, responsibilities, title etc. Obviously, no job will be perfect, but really compare the offer with your list of needs and wants to make sure that the position will be a good fit for you. Above all else, don’t let a recruiter or someone talk you into a position that isn’t right for you. If you have a bad feeling about a company, go with your gut and walk away.
I found that applying for data science jobs was a waste of time. When I first started my job search, I applied to 10 or 15 jobs a night that I thought I was qualified for. I think of the 50 or 60 jobs I applied for, I maybe got 3 or 4 callbacks. I had much better luck networking on LinkedIn. Honestly, this is my best advice to anyone looking for work, especially in tech. Network with people on LinkedIn and anywhere else that you know of. You will do much better than blindly applying for positions.
The interview process is a window into the company. If a company takes forever to respond to you, or to give you an offer, or whatever, this is how the company is going to operate when you work there. They will be sluggish and unresponsive. I will say this is something that I am working on at Deutsche Bank. At the time of writing, I was looking to hire several Splunk engineers. I worked with our HR team and we got candidates in the door, interviewed and presented with an offer in 2–3 days. That tells the candidates that we really want them and shows that we can get things done. In stark contrast, I had one company string me along for months, before presenting me with an offer, which by that point, I had already accepted the position with Deutsche Bank.
For me, I don’t want to work for companies that engage in unethical behavior, or have sleazy managers etc. One of the things which impressed me when I was interviewing at Deutsche Bank was how up front people were about the company culture and challenges that they face. Nobody tried to portray everything as being perfect and amazing. (FYI, every company has its BS) Banks, as most people know, are heavily regulated and international banks have to deal with incredibly complex regulatory regimes. This is for a good reason. When I was interviewing at Deutsche Bank, it impressed me that every interviewer had a discussion with me about what it is like to work in a bank where you can’t just do whatever you want with data.
In principle, I do like the idea of a take home coding exam, however as a candidate, I found them to be quite frustrating and a major turn off. If you are trying to assess a candidate’s ability to code, there are many ways to do that, and I think companies should offer a coding challenge, but many of us have portfolios of code which we have written and are publicly available. Whenever anyone asks me now, I just refer them to my github page, or offer to send sample code from projects that I can share.
I interviewed at a company and when through several rounds of phone interviews at which point the recruiter informed me that before they brought me in for the final in-person interview, they wanted me to do two coding exams, a one hour exam and then a three hour exam. These exams were timed. I passed both the exams, but this was mid-December and the recruiter told me that he couldn’t schedule the in person interview until January. I never heard from him or that company again. At that point, I decided that if a coding exam was longer than one hour, I was not going to do it.
I did another coding exam for another company. The exam itself was straightforward, and since they didn’t ask for an NDA, the questions were something like:
1. Write a function to convert decimal to roman numerals
2. Write code that counts the number of occurrences of items in a list.
3. Write a function that determines whether a string is a palindrome
I submitted code that uses python modules and also code without modules. I wrote extensive comments, etc. The code worked to spec and was well documented. I thought it demonstrated that I could both use pre-existing modules and write functional code from scratch. A week later the recruiter told me that I didn’t pass the coding exam.
After that, I decided that I wasn’t going to waste time with coding challenges any more. One company I spoke with sent me a coding challenge which they said would take at least 8 hours to complete. Sorry guys… I work for a living, have kids and have better things to do.
If I was hiring and decided to use a coding exam, I would try to first set clear objectives for the exam and make these objectives known to the candidate. Are you just looking for code that works? or are you wanting code that is beautifully documented and uses correct design patterns?
In my opinion, a coding exam should be designed to take no more than one hour. The candidate doesn’t work for you, so making them do lengthy coding exams will only discourage candidates who are busy and sought after. Basically, I would ask a question or two simply to ascertain that the candidate can code and can write reasonably good quality code.
Oh… and let’s talk about HackerRank. This site sucks. SUCKS!!! There is no other way to put it. It is absolutely awful. If you haven’t tried it, DON’T! HackerRank presents you with a coding challenge. You can write code in their environment, in any one of many preselected languages, and then your code will be tested against use cases that you can’t see. Why does this suck? Simply because you have no way of debugging your code. I did this for two potential employers and while I passed these tests, I found them to be really annoying and unnecessarily time consuming. I spent probably 30 minutes debugging some code that if I had been able to see the test case and the output, would have taken 30 seconds. The other issue that I had with HackerRank is the artificial environment. Most of the work I do now, I do in Python 3. There are collection of modules which I use which are pretty much standard such as Pandas, Seaborn, Scikit-learn, etc. When you do a HackerRank challenge, you may be forced to use an unfamiliar version of Python without your standard modules. While I can code in Python 2.7, I’m not as fast as with Py 3 and likewise I’m perfectly capable of coding without the standard modules, but it will take more time. Bottom line, if you’re hiring, please don’t use HackerRank.
While we are on the subject of coding challenges, I am not a fan of BS challenges. Don’t ask me to write a non-recursive binary tree traversal because I can google that and you learn nothing about my coding ability. IMHO it’s also a really jerky thing to do to someone in a live interview. So if I’m interviewing you and I ask you to write code that implements the cube root function, you know you are annoying me.
Finally, if you are going to ask someone to code for a data science position, you should remember that coding challenges are not hazing. They are a means to evaluate a candidate’s ability to code. Therefore, coding challenges should reflect the kinds of things you’d actually want them to do. If I were to implement a coding challenge for data scientists at DB-CSO, I would give them some sample security data and have them do some ETL and exploratory data analysis using whatever tools they like. Depending on the length of time, I might ask them to build a model and evaluate its performance, again, using whatever tools they like.
Another approach is simply to give the candidate some relatively simple challenge just to verify that they can code and I think this is also a perfectly acceptable approach.
Let me say that some point in your career, I would highly recommend that you spend time doing interviews, as in doing them for your company. I think it really helps prepare you for interviewing yourself in that you have a solid idea of what interviewers are looking for.
If you ever have the misfortune of being interviewed by me, I will tell you right now, that I look for people who are: smart, know how to get things done, and are passionate about what they do. No amount of prep will prepare you for that. When I interview candidates I try to drill down into the candidate’s strengths. If those strengths align with what we’re looking for at the time, then congrats! Usually I won’t bring someone in for an interview unless I’m convinced I’d hire that person, so if you get an interview from me at all, that’s a good sign. I like open ended questions that let the candidate show their thought process. Here are some questions I have been known to ask:
- If you were a terrorist or criminal, what techniques would you use to obfuscate your communications to surveillance agencies? (Totally open ended, and lets the candidate demonstrate their understanding of networking and telecommunications technology) (This was for cyber analyst positions)
- I’ll ask the candidate to walk me through the process of designing a system to detect fraudulent credit card transactions. Depending on time, I’ll get into this, ask about design constraints etc.
- Explain how you would assess the value of data science project X to a senior manager. I really like this question because it forces the candidate to think strategically about the impact a particular project is having.
Best Interviews: CapitalOne, Orbital Insight, Kensha. Now of these companies, I only actually got offers at one of them, but I was really impressed by the process and company.
Worst Interview: I was asked to implement K-Means clustering using Map-Reduce. This interview annoyed me because I am pretty up front about what I do and don’t know, and this interviewer was just being a jerk. I don’t claim development experience with MapReduce on my resume. Pro Tip: If the candidate says they don’t know X, don’t ask them a million questions about X. That’s just being an asshole. Instead, find what the candidate is good at and see if those strengths align with what you are looking for.
Most Embarrassing Moment: In a moment of fatigue, the HR person from one company asked me what I was looking for in a job, and I told her someplace where “I wouldn’t be bored out of my fucking mind.” I got an offer from this company, but I was so embarrassed I did that. Pro Tip: Avoid dropping f-bombs during interviews.
Most Thought Provoking Question: Tell me how you would design an autonomous car
Weirdest Interview(s): Any small government contractor that wanted to meet me in a hotel lobby.
Biggest Disappointment: I interviewed with a large financial firm that had a beautiful office about 10 minutes from my house for a really great position. I interviewed with potential peers and two managing directors. As I was being walked to the elevator on the way out, the managing director told me that he thought I’d be a great addition to the team and looked forward to working with me. I totally thought I had that one in the bag, but after stringing me on for several weeks, I got no offer. Pro Tip: Nothing is ever in the bag. I’ve had interviews I thought I nailed and got no offer and other that I thought I bombed and got an offer. You never know.
Biggest Frustrations: My biggest frustration is when there is a lack of communication between the company and me. I was always concerned that persistence could be interpreted as either desperation or being a pest. There were two companies that strung me along for months in the process. Pro Tip: If you’ve interviewed a candidate, you owe them a response… any response.
Another big frustration I had was companies generally not being respectful of my time. I live on the East Coast–DC area. There were a few companies that wanted me to fly out to SF or Silicon Valley for an interview with the “home team” for a position in DC. I think this is a fine idea, but recognize that going out for one day from the East Coast is really a 2 or 3 day trip, unless you do red-eye flights or other insane scheduling. So, companies, if you are looking to hire an East Coast candidate and fly them out for an interview, please be respectful of the candidate’s schedule… and don’t make them front the cost of the ticket. You can be respectful by scheduling such interviews on Monday or Friday so that the candidate can minimize the time off of work.
In conclusion, I would say that when looking for a job as a data scientist, make sure you (the candidate) know what you are looking for and don’t veer to far from that. To companies: know what you are looking for and treat candidates with respect. You do a huge disservice to yourself and the candidate if you hire someone and you have no clue as to what you actually want. What I realized during the process is that when hiring, many people are looking for an idealized version of how they perceive themselves. This means that if the interviewer perceives themself as a hard worker, they will look for that quality in the candidate. If the interviewer perceives themself as an expert in subject X, they will ask a lot of questions about subject X. Good luck on your interviews, and if you would like to do a mock data science interview with me, please don’t hesitate to contact me.