6 ms·
My background is that of an econometrician (ie quantitative economist), and I now work as a Research Engineer at one of the FAANG research divisions. I think t
by fnbr 8y ago
My background is that of an econometrician (ie quantitative economist), and I now work as a Research Engineer at one of the FAANG research divisions.
I think the advice about getting in as a hardware engineer is solid. At my workplace, there's a ton of need for people working on specialized hardware for DL, and for people working on the software that works with it (optimizing compilers, etc).
If you are looking to break into the software side of DL, the first two thirds of the Deep Learning book [1] contains all the math you need to know to pass the interviews. Then, it's just a matter of getting interviews; I found that I needed professional experience deploying DL/ML to do that. I got that by doing side projects at work. For instance, we had a long standing operations research problem, and I spent some free time at work implementing a RL algorithm to solve it. I didn't get too far, but I was able to talk coherently about the papers involved and about how I planned to conduct the project, which went a long way.
[1]: https://www.deeplearningbook.org/ https://www.deeplearningbook.org/
- ultrasounder 8y agoThanks and I just subscribed to your Byte-sized videos at aiworkbox.com.
- fnbr 8y agoThanks! Let me know if anything's unclear :)
- heinrichf 8y ago> Then, it's just a matter of getting interviews Are you implying that, once prepared well enough, the contents of the interviews are simpler than getting actually noticed in the pile of applicants ?
- joshvm 8y agoYou need to think like an interviewer - what can you reasonably make someone do in half an hour (plus time for chat and questions after)? Apart from being able to parrot deep learning theory, implementing things is tricky. Do you learn anything from making someone implement VGG in their pet framework? Training models also takes more time than you have to spare. Much easier to quiz the applicant how they would solve a problem, or to discuss a previous project or paper they've published (or are interested in). Some people will find that much easier than whiteboard coding, others will hate it. It really depends where you apply and if you want an applied or research role. Some places won't touch you unless you've got a publication in somewhere like CVPR. Others will go _hard_ on the stats questions. Other places want to see a strong Kaggle rank or some personal projects. It's really useful to have a portfolio here.
- heinrichf 8y agoThanks, that is helpful advice.
- fnbr 8y agoPerforming well on the interviews is a skill that you can acquire through practice. If you do 100 Leetcode questions, read through all of Cracking the Coding Interview, and suffer through 30 phone screens, by the end of it, you'll be a hardened interviewee capable of passing an interview anywhere in tech (you can probably get by with much less practice; I'm being purposefully hyperbolic). Does this mean you'll be good at the job? No. Is this very wasteful? Yes. Getting interviews, on the other hand, requires you to read the recruiter's mind, and can vary depending on what the recruiter had for breakfast, or if they fought with their significant other that morning. It's much less formulaic.