Seriously though, what do you expect from a junior data scientist/dev?

February 17, 2019 6:57 PM

I'm a PhD student pivoting out of academia, I have a bit of personal programming experience, and I have about 6 weeks left of a data science bootcamp. I've learned a lot, I've been Pythoning my butt off, and I'm starting to think about job interviews and how to prepare for them. The problem: the internet is rife with conflicting advice. If you've hired a junior or have been hired as one, HELP ME PLEASE!! (Note: While I'm primarily focused on data science, I'd be happy to do junior dev work too).

This is mostly a question about technical interviews, as I feel like my interpersonal skills, stats knowledge and critical thinking abilities are strong. I've seen some postings for jobs that I really feel like I could do, but I'm worried I won't be able to pass the technical interview based on what I've seen out there. These are postings primarily for startups or small tech companies in my area.

I understand that every company will be different, but it's really hard to get a feel for what people actually expect from juniors in an interview environment. There seems to be a lot of gatekeeper-y advice out there ("If you don't know X or Y, don't even bother. Make sure you do ALL THE THINGS EVER before you even think about applying!"), but I've also seen people say that they're usually just looking for someone teachable and likeable with some basic skills. This is also what people have told me IRL but I can't tell if they're just being nice or what. I've heard that things won't get much harder than fizzbuzz (seriously?), but I've also heard that technical interviews are gruelling and days long and to buckle up.

Some people say to put all your focus into a strong portfolio, others to say portfolios don't matter and to focus all your energy into practice questions and sites like HackerRank. Again, I know there's not going to be a one-size-fits-all answer but the advice is seriously all over the place. I don't want to be spending all of my time obsessing over HackerRank questions (and feeling unprepared if I get stumped on a few) if I can instead focus my time on fiddling and working on small projects instead. However, if I do have to pass a bunch of tricky programming questions so be it.

So: if you've spent time interview juniors or you yourself were once a hired junior, do you have any advice for me? Would you say your expectations were more "Do all the things?" or "If you seem teachable I'm happy with that"? (Note: I am totally aware the advice in this thread may also be all over the place and if that's the case, well, okay then!) Thanks in advance!

posted by thebots to Work & Money (5 answers total)

Things I look for in a junior dev: Teachable. Some small projects. Confidence (not cockiness). Snowing excitement about the subject matter. Interpersonal skills.

We don't do tricky technical questions, but we're do all a few standard questions to determine basic competence.

YMMV
posted by pyro979 at 7:34 PM on February 17, 2019 [2 favorites]

I mean, advice varies wildly because company behavior varies wildly. I will say that companies that ask easier/no technical questions tend to be ones with a lower level of technical competence - this could be because they're an undesirable employer or it could be because their product work doesn't require a high level of competence. This isn't a reason to give them a pass but it is something to think about. WRT hackerrank vs portfolios, in general portfolios aren't as popular because they don't scale well - it takes a lot more prep time for the interviewer to study a portfolio than to ask a whiteboard question.

Frankly, you only really have to prep for interviews if you want to - assuming you do in fact know how to program a bit, you will probably get some offer. You may or may not get into a top-rank company but this isn't like grad school - the company you get into as your first job is not going to have that much impact on your overall career.
posted by inkyz at 9:42 PM on February 17, 2019

My company uses a take-home practice problem as the launching point for our interview sessions. This ends up being a scenario where it doesn't hurt to demonstrate "rote learning" or an almost checklisty approach to doing data science work: If you're given an exploratory data analysis problem, don't skip steps you've been taught in your bootcamp. Creativity and special talents are great, too, but don't allow a suggestion that you think your special skills should outweigh the basics. With junior people — especially PhD-types who might think they can become experts at anything quickly — it looks good to show that you've taken seriously what you've learned in bootcamp.

On the other hand, it's good to show that you can make judgment calls about which of those "basics" are important in whatever problem is in front of you. Also, if you're struggling with an answer and an interviewer asks you an (irritatingly) open-ended question like "what other considerations might you have?", it's a great time to think through the basics and just talk about why you think some might be relevant and others not.

Teachable means curious, so it's important to show curiosity at every opportunity. Beginner mind *is* a superpower, and that one of the reasons why a company is interested in hiring people at a range of seniorities.
posted by xueexueg at 10:13 PM on February 17, 2019 [1 favorite]

I did this. A few caveats though: my PhD is in combinatorics, which means a) I enjoy solving those whiteboarding problems and b) I'm likely going to have a knack for it, and, secondly, my current job title is "Software Engineer, Machine Learning", meaning I've arguably fallen out of the "data scientist" role altogether. (That said, "data scientist" doesn't really mean anything that anyone can agree on.)

A few thoughts:

• Be able to derive linear regression. It's completely useless as an interview question, but it is popular. During my last job search, this morphed into "explain logistic regression". I think this is the result of trying to jam statistics questions into the form of an already imperfect software engineering interview.
• I find Cracking the Coding Interview to be invaluable in terms of preparation, which much more helpful explanations than HackerRank. (That said, it's nearly doubled in price since I bought a copy. HackerRank will do fine if money is an issue.)
• People (me included) will tell you they're looking for problem-solving skills and an ability to think and learn. A lot of interviewers don't actually know how to assess this and use "gave me exactly the answer I was looking for" as the criterion instead. People with tons of experience (both interviewing and engineering) tend to be better at it, as do less experienced people without CS degrees (because they had to learn on the job). In other words, you can give the same interview performance at two different companies and get completely different responses.
• In my first job search, I did highlight some tiny projects I did on my resume and I did get asked about it in interviews, so that's something. Broadly, though, I don't think people look at portfolios--too time consuming as someone said above. (Caveat: I did also have an open source software contribution that sounded way more impressive than it actually was. I got asked about that several times and would say "Seriously, way less impressive than you think it is.")
• There can be a bias against people with PhDs--we're not practical, we think we're too clever, etc, etc. I don't think there's much you can do to demonstrate how practical you are or whatever. This and the lack of a CS background are obviously less of an issue when interviewing with teams where you won't be the first person ticking either of those boxes.

posted by hoyland at 6:45 AM on February 18, 2019 [3 favorites]

I've been asked technical-ish questions about stuff that's on my CV. The interviewer will say "I see you have used the Random Forest algorithm for blah. Can you describe parameters that govern the algorithm and how you might choose appropriate parameter values?". I was asked about random effects models - also on my CV - and why use such a model instead of a standard linear regression. I've been asked things like, "lets say you have this kind of problem - how would you go about handling it?" I've been asked super-basic technical coding questions about skills on my CV - like, in SQL, how would one create a table with cases that are in both set A and set B. I've never had a software-engineer type interview with white-boarding or fizz-buzz, etc - possibly because I'm not a software engineer and nothing on my CV suggests that I am. As a data scientist I would have been willing to do a take-home project and present my approach and findings (tell a story with the data) and take questions on them, but it didn't happen. Data science encompasses stats and programming, and I am heavy on stats and light on programming (well, I use R daily but never C++/Java) - so it's my bias that if a company wants to do software interviews this is the wrong job for me.
posted by everythings_interrelated at 6:51 AM on February 18, 2019 [2 favorites]