1. Break down "data science" into several different roles–in our case, Analyst (business-oriented), Scientist (stats-heavy), Engineer (software-heavy). Turns out that what we mostly want are Engineers-Analysts, so our process screens heavily for those.
2. Figure out which types of people can be trained to be good at those roles, given the team's current skillset. I opted to look primarily for people with strong analysis skills and some engineering.
3. Design interview tasks/questions that screen for those abilities. In my case, the main thing I did was make sure that the interviews depended very little on pre-existing knowledge, and a lot on resourcefulness/creativity/etc. E.g. the (2-hour) takehome is explicitly designed to be heavily googleable.
4. Develop phone screens that are very good at filtering people quickly, so that we don't waste candidates' time. By the time someone gets to an onsite interview on our team there's something like a 50% chance they'll get an offer.
On the candidate side, when I'm applying I try to figure out first and foremost what a company means by "data scientist", usually by networking & talking to someone who already works there. This filters out maybe 90% of jobs with that title, and then I put more serious effort into the rest.
For instance, a common description might say the candidate will be working with "big data" to help with "data-driven initiatives" and the requirements will be something like "knowledge of Excel, with a Masters in Statistics, or equivalent experience".
It's really hard to tailor a cover-letter or a resume to a job posting like that. For one thing, I can't even imagine what kind of work they are doing if they are using Excel for "big data". Second of all, I currently have a job, and writing cover letters and creating resumes takes a lot of time. By the time I get to the phone screen I've probably already spent at least a couple of hours applying. Plus, in the interest of keeping my cover letter and resume short, I have to leave off a fair amount of my experience and performance metrics.
Honestly, at this point I think I'm just going to start reaching out to people in the fields I'm interested in and asking them if they know of any roles that would fit my skill-set. The way I see it, I'd at least have a chance of getting feedback from someone who can view my skill-set holistically, rather than HR, who will let me know that I don't tick all their boxes (or vice versa).
I lead a Data Science team and part of the struggle with writing sensible job descriptions is that there are too many people providing input into the job description. HR can also put their hand in the pot when they try to use buzzwords (e.g. Hadooop) to internally justify why a role with 2 years of experience needs to be paid like other roles (e.g. traditional Excel based Analyst) with 5-10 years of experience.
>>They tend to have a short description of the role, which is generally filled with buzzwords, followed by a list of requirements. I wish organizations would talk about what they wanted to do with their data instead.
One major challenge for Data Scientists is how hyped the role is, leading to people in an organization believing whatever they want about Data Scientists. Are you a leader who wants a business analyst who can use software and interface with IT? Data Scientist. Are you an engineering manager who wants a person who can interface with the business and use machine learning? Data Scientist. Are you a VP who thinks big data and ML is the problem to your bad or non-existent data? Data Scientist. Do you want somebody who can exhale the maximum amount of hot air while still sounding like a tech and math genius? Data Scientist.
Also add in that business people with minimal experience in modern Analytics are trying to build up Data Science and Analytics capabilities in their own part of the organization because they realize Excel is not the answer to every question. I've spent a lot of time speaking with people to help them understand the type of people they need to hire. Sometimes people are sensible and sensible job descriptions and expectations come from that. Other times they are adamant about what they need (even if they are wrong) and the end result are convoluted job descriptions that are either never filled or filled with the wrong person.
It may seem like a daft question, but have you tried asking them? They may clam up and refuse to give you anything, but I would imagine most small companies would be willing to talk about what the role involves. It's a bit late at the end of the interview to be asking "So what would I be doing?".
You may find out that they're working on some data which is e.g. image-heavy and you happen to be an image processing expert.
Candidates know that, typical in person interview has a 1/10 chance (or worse) of getting an offer from an inperson interview, and so most candidates, including good ones, would care less to spend much time on interviewing with any one employer, or do much to increase their unknown chances.
As a rusult employers don't get right candidates and then wine about lack of talent and pay for crappy tools that just sort resumes half assed way... good grief.
An engineer who wants to learn data science is a great fit for us, an academic who wants to write R all day is not (though an academic who wants to learn engineering/functional programming is fine!)
Beyond that, I ask some questions about projects they've worked on, and in particular, how their approach would change if assumptions were different. Here I'm looking for the ability to reason backwards from a business goal, as opposed to somewhat blindly applying statistical techniques.
If they do well on these, we send the take-home exam. As previously noted, this is specifically designed to require relatively little knowledge but heavily test analysis skills, and lightly test programming skills. It's almost impossible to complete this exam without using Google effectively, so that's another thing I'm testing.
BTW, as to some of that "feedback":
Honestly, I think the way you communicated your thought process and results was confusing for some people in the room.
"Okay, pal - let's put your people up in a room full of strangers (some of whom show through their body language and/or constant phone-checking that they pretty much don't really want to be there in the first place), make them answer some made-up questions (which may or may not be coherently presented; or even particularly relevant to the job description) -- combined with the background stress of being unemployed, and/or stuck in job they absolutely HATE, and can barely stand another day of -- and see how they do."
Quite honestly given your questions [about vacation policy] and the fact that you are considering other options, [we] may not be the best choice for you.
Great -- so they're basically accusing you of being a slacker (not really into the work, only interested in what's in it for you, etc). Which is quite a presumptuous attitude to take in response to a perfectly reasonable question about the value proposition they're asking you to consider (a question for which it might be in better form to wait until the later stags of the negotiation process to bring up... but that's a very minor style point that you definitely shouldn't be dinged for).
"Quite honestly" that attitude sucks. And you don't need to feel bad about being "rejected" by people like that.
I thought about if I should ask or not but I honestly don't understand how such a policy could be good for employees so I wanted an idea of the culture that allows it. If that question contributed to them not giving me an offer then good riddance so I don't regret asking.
Wow, get similar rejection lately: this is a fast paced company and the way you explained your thought process was confusing and might slow us down, so good luck with your job search.
Better not answer with "Thank you very much. I also had a feeling that some people in the room lacked the mental capacity to follow my explanation."
;)
Internal recruiters have hinted that my Software QA Engineer background + no CS degree implies I have no technical skill.
My own experience was that my initial position as a software performance engineer resulted in a perception that I was a "tester" without technical skills despite having multiple CS credentials and published code in practitioner-oriented sources.
Overcoming recruiter biases was such a struggle that I now routinely counsel students and early career programmers to carefully consider whether job role perceptions would negatively affect their future prospects. I also tell them, when financially viable, to not take on roles where hiring orgs cannot give them a day-to-day job description that directly matches their desired career path.
This advice seems quite challenging or maybe misguided for data science careers though. It seems like just getting an entry-level data science job might require a dedicated MS in either CS or stats, with a healthy set of projects in whichever of those two subjects you didn't spend grad school working on to prove yourself . . .
Contrary to what the reddit folks would have you think. The ONLY thing that consistently get someone through the door is demonstrable real work experience, on real projects, in the industry (read: not academia). Side projects are not a substitute and the lack of degree is a barrier.
It turns out that QA was only the tip of the iceberg. You have a job title as "QA" and a job title as "support".
You will NEVER get any development or engineering job with that. Expect 90% reject in the resume screening because you are not a developer.
If they were development jobs, replace both by "software developer".
My most recent job is obfuscated a bit in the public eye/only visible to logged-in LinkedIn users, for good reason. (I politely request people looking into it not discuss it)
Are you applying online or via getting coffees with people in the data science team and just talking shop? The latter seems to have a high conversion rate if you can nail it.
In the OP's case I would change their title (if applicable) to "QA / engineer" as a) that probably paints a more accurate picture of what you were doing and b) gets around yokels that look down on QA/SDET.
Others have said the same, but I'd wager the biggest issue is (a) the limited past roles that directly dealt with data science/analysis or (b) SF's narrow-minded hiring practices. Maybe a masters or data science bootcamp would go further than more blog posts?
They're really trying to mitigate risk that they pass you along to engineers and the engineers say "why am I looking at this person with no formal qualifications" and then the recruiter feels like they've wasted the time of the engineering team. It's stupid but insidious.
If you can I would suggest trying to bypass the recruiters and contact the engineers/hiring manager directly; ask them out for coffee and ask for advice on starting a career in data science, or show them your portfolio via email there.
edit: spelling
I realize that most startups recruiting through HN are looking to hire for web, app or backend development, but there are a few data science jobs. Since people recognize you here on HN, you have a much better chance of landing a job.
It's unfortunate that most recruiters primarily screen based on resume.
I don't know if Triplebyte [1] helps people find data science jobs, but do check with them.
It's OK to leave stuff out on your resume if it's not relevant (and maybe even harmful) to the position you're applying for.
Once I got that offer and 'data scientist' was listed as a position on my resume, I've had at least one or two recruiters reach out to me each week. Not just your 'bulk tech recruiter', but individual hiring managers/team leads from companies who had no interest in me prior to the title change.
Hell, I had a manager I had already interviewed with from another company (and got rejected) reach out to me TWICE to come back in. To be honest, I'm not entirely sure he remembered that I had interviewed there only a month earlier.
All after I had the title change on my resume. What I'm getting at, is for me, the title change really opened up doors. I figure 'data science' is such a huge buzzword now, recruiters look more for that buzz word than they do for the actual content of what you've done on your resume. I'm sure it will die down at some point.
This may be more prominent outside of silicon valley where I am, and (in my opinion without any facts to back it up), where I feel more weight is given for the title than the substance.
I've had the following:
- 106 Rejections
- 39 Offers
- 24 Refused
- 15 Contemplated
- 5 Taken
- Software Engineer (55rj, 8o, 6r)
- Product Manager (5rj, 6o, 5r)
- Senior Software Engineer (31rj, 23o, 22r)
- Product Lead (0rj, 1o, 1r)
- Senior Product Manager (9rj, 3o, 2r)
- VP of E (2rj, 1o, 1r)
- CTO (0rj, 1o, 0r)
Things to note:
- People conflate Agile & Scrum a lot.
- Make it easy for people in the room to know what you personally accomplished during your career.
- Make an impression, don't overdo it however.
- Make your descriptions easy to understand.
- Don't just list tech stacks on your resume, list achievements.
- Stay consistent.
- Ask questions.
Regardless how impressive your Github & Stackoverflow accounts might be, you will still be asked to do a stupid code challenge. It irks me. I understand the reasoning for it when you don't have a viable pool of information on the individual, but when you do... It's just disrespectful.
Few places I have been rejected by:
Salesforce, Atlassian, Trello, Twitch, Segment, AirBnB, Twitter, OKCupid, LinkedIn, Shippo, and many many more.
Amazon, VMWare, Oracle, Google (twice), Apple (twice), Venmo, Auth0, Discord, Youtube, Hitbox, Steam, Pusher, CloudflareI'm glad I had those interviews early on, so now when I see an interview start to drag on, I cut it short as it doesn't look like a priority on their end.
I had a very similar experience. Job offer was basically on the table and then they balked because I mentioned that I had another offer (at a larger company, which they seemed shocked/annoyed with) and I had a question about parking at their new offices. The current offices had free parking, so I had simply asked if the new ones would too. The response was very cold (must have a been the source of internal strife, I guess?). An hour later I got a call saying they were no longer interested.
It still hurts, of course.
Mentioning that you have another offer is seen as a negotiating tactic. Then they have to compete/bid against the other offer, and you are removing some of their leverage/power. A strong reaction to such a move can be to cut off the interview, so to regain back their power.
In his case, the author doesn't seem to have had an offer on the table. Perhaps the interviewer felt as though the candidate was trying to negotiate too much, too early in the process. Perhaps the interview didn't go over all that well?
To share my story, I also had a difficult time transitioning into a data scientist role after leaving academia (pure mathematics), and I always thought the root cause was my lack of experience and competency. So instead of keeping on applying, I spent over a year just to sharpen up my skills. It paid off in the end.
How can one develop his/her skills and cultivate expertise if one is job-shopping all the time (possibly aimlessly)?
Dodged a bullet on that one:
- PTO is a touchy subject?
- They are looking at more than one candidate, why would any candidate limit themselves to one potential employer?
I was shocked to hear that, apparently it is somewhat common in retail jobs not to get paid out. Happened to me at a company that claimed to be more of a technology company. Maybe they don't think word gets around. Or that smarter employees will just take a lot of time off before quitting, which does a lot more harm to the company than if they just paid out the time owed to the employee.
I have a hard time understanding. At least for what I've seen/done, it would take about a year of experience to be of any real value. I'd say you start seeing real dividends from an employee near the three year mark. I think the primary exception would be where you have a big gaping hole in an organization...like building a data science program or something from the ground up. But if you've got software and customers long long past the 1.0 stage to support, and someone is going to (someday) understand/contribute to the core? Think about Google's monolith or the Linux kernel...sure most software isn't that mature/grand, but there are many projects out there that are closer to that than greenfield. And it's not just the code, it's the developed relationships/rhythm with coworkers and customers.
Maybe I've explained it to myself, I don't know. The difference may be startup companies or projects versus mature ones. At least in the latter case, it seems to me that if a company retains an engineer for less than 2-3 years, they've almost certainly lost on that investment.
That's actually the only correct answer. Having been on both sides of the table for many years, I can pretty much guarantee that whatever reason the candidate is given is nowhere close to the actual reasons.
There may not be any specific reason why we didn't pick you, but we'll give you a tiny sample anyway. So you think that's the reason - it's not.
In other cases, we have a strong reason not to pick you, but it's embarrassing so we feed you a bogus reason instead.
And in more cases than I'd like, there is no problem on your side, we are having internal issues that we can't reveal anyway. Any reason you hear from us in that case is completely irrelevant.
By the way, when you evaluate people in interview, you really need to figure out a vector: where they are today in terms of knowledge and experience, but also in what direction they are going (fast learner or not, high potential, etc.). Which is why sometimes you can hire someone who has less relevant experience, but you think they'll learn fast and are very smart, and sometimes you are looking for the perfect match to the current position, but don't care too much whether they can pick up new stuff or not.
And your lawyers would strongly advocate against that.
In most cases they can't/won't tell you because it could open up legal liability. If they say a reason for you, but then hire someone else to whom that reason also applies and you find out, you could sue them. Or you could find a way to twist it into something against a protected class. Too many ways for the company to get screwed.
That's why they all say "we've decided to go another way" or something equally generic.
And he was right, too.
But I broke it down as follows. We received 300+ applications, we filtered down to 100 that were worth even reading in detail. From those we took 50 that we discussed/scored as a group, and came up with 15 people we wanted to interview. Of those we interviewed 10, and of those we interviewed 5 a second time, and 3 a (brief) third time.
"So yes, you did well, and we'd like to keep your name and reach out" (said sincerely). But for him knowing that he didn't screw something up, there was just an even better candidate and he was realistically still in the top 1-2% of applicants was confidence-boosting.
Even one or two sessions can help you a lot - they are trained in pinpointing "soft" issues.
It's a difficult enough field to hire in when you understand what it is (and isn't) - and lots of companies are trying to do it with far more vague goals.
(1) They are inundated with applications folks of all sorts of backgrounds: engineering, finance, academia, marketing, BI/analytics, etc.
(2) They still haven't figured out hiring. To be fair, no one really has figured it out. Jeff Kolesky recently covered this as part of an excellent blog post. [0]
(3) In addition to the typical variance in engineering interview processes, we now introduce variance in the definition of data science across companies, which just complicates things further.
(4) Basically everything else Tim mentioned in his post: role or goals aren't clearly defined, remote data science is an unknown, etc.
Let's supposed, for a moment, that the hiring was completely random. 100 people apply, they pick a random name out of a hat, and hire that person.
Your name might never be chosen.
For startups, this transcends data science. It might be the one time that week they focus on that need.
Networking is still king.
Exactly and this also argues against wanting to get hired to work remotely.
True, though not unheard of. I worked at a startup that hired remote devs via networking of that nature. It seemed to work well for them. Eventually the entire team migrated to the same area but things operated smoothly remote for the time being.
- Signal is still quite low among noise, even with long multiple interviews, take-home homework, coding challenges, etc. Most relevant data is still hidden and takes months-years to come out.
- Companies seek to minimize false-positives much more than minimizing true-negatives.
- It's a numbers game from both ends because the probabilities are low, due to above 2 points.
And doesn't bother to respond after you submit. I'm certainly not the world's best coder, but my solution met all those requirements in a reasonably elegant manner, and took several hours (10-20?) to make comprehensive.
That gets you on my shit list, and people I know get to hear about it, too.
Does anyone have any suggestions? Here is my linkedin account: https://www.linkedin.com/in/karl-dailey-02557b65
My takeaway from it.
There is a ramp up time for new hire, which could be a couple of months. So durations of a year or less doesn't look good. I personally like to see minimum of 2 years for each job. Of course, too long can be a concern too unless they really grew in their role.
I agree with his conclusion, Network is king, but I also believe in listening to the universe. If everyone is "wrong", maybe you are the problem. If lots of people don't wish to hire you after you have solid experience in the industry, something is wrong with you and you are being stubborn by refusing to recognize it and fix it.
My future really rests upon this. I have a degree in mechanical engineering with irrelevant experience. My only regret is not doing bachelors in computer science.
I wouldn't lie if all the post got me little tensed and made me thinking, "what am I doing with my time". About to finish introduction to Computer Science using Python on Edx.
That said, what is this?
a) "I cannot do X" b) "But here is some advice on how to do X"
I mean... why would anyone listen to the advice that is proven to lead to failure? Serious question.
I know switching jobs is common here, but i would think that sticking at least 1 to 2 for a job would be normal (assuming it works out).
Bit of a silly article. You could say this about anything. And I don't see what the problem is with never being contacted, if someone doesn't want me for whatever reason, I don't really want to hear from them again.
You wouldn't want to work there.
" but the team has decided to keep looking for someone who might have more direct neural net experience."
Fair enough - but this has to be slim pickins. How many AI jobs are there out there? Realistically, very few.
We got confused, and then we stopped. The end.
apply for 100 jobs, get zero response, and zero reason why.
be told illogical things.
be told out right lies.
welcome to capitalism. welcome to the workplace that is run entirely by data. (or by people who only care about data). welcome to the future of humanity.