The thing is, I've never gotten much interview experience. I got that job through a very weak selection process with basically no testing, the real test was an internship and then a trial period. I don't know what interviewers expect (I'm looking for machine learning jobs), or how to practice it. The first interviews I take, I'll probably bomb.
Is the best way just to start with positions I'm not that interested in and bomb them for practice, buy a book or two about ML interviews and go through exercises, or do more side projects?
I'd like to have an offer that I can accept in the next few months. I can take time off to practice if needed.
Aside from just technical skills, these mock interviews can help you articulate your thought process clearly, which is often as important as the solutions themselves in ML roles. Remember, it’s not just about getting the right answer, but also showing how you approach problems.
A side note based on a pattern I've observed so far: candidates who practice like this tend to perform better not just in technical assessments but also in explaining their past projects and teamwork experiences, which are equally critical parts of the interview process.
Hope this helps. Dive in, get that feedback, and refine your approach. Good luck!
Many employers go into these discussions thinking that they are going to put you under the microscope. But if you direct hard questions in their direction, the power dynamic changes. Suddenly they are trying to convince you that you should work for them.
One of the best questions to ask early in interviews is "Outside of what's in the job description, what are the qualities that you are looking for in the ideal candidate?" Then you can frame your responses in a manner that aligns with their description.
Another great question to ask: "What are the circumstances that led to the availability of this position?" I asked this question recently and the employer revealed that 1) a former employee in that position had left, and (after further probing) 2) this employer tended to hire inexperienced engineers, who frequently left after a couple years to pursue better jobs. Needless to say, that info prompted me to end the conversation.
Remember: It's far better to be rejected by a good employer than it is to end up working for a shitty one because you didn't ask the right questions.
Your employer is only one company, but understanding its side of interviewing can help guide you in how to present yourself as a candidate.
Also, yeah, the best way is practice and self-reflection. And the best way to get practice is to do it, so submit resumes to jobs you aren't sure you really want rather than only your OMG I want this job. This gives you a chance to do some negotiation practice too, and maybe have some offers to play against.
The best advice is to get as much practical, real interview practice at companies that aren't your #1 choice before you go interview for your dream job.
The reality is that people that do the hiring are usually workaholics, so they turned interviews into dating. The only way to get a job is if all the people involved like you outside the job.
So look into networking, nepotism and cronyism.
- you can do practice interviews with peers, some people will be good and some will be bad. Anyway, record them, play them back, take notes on how to get better, and repeat.
- get a list of sample questions, all of them, and figure out through some thought what the best answer to each is, and then drill on that. I used Anki, made hundreds of cards
- learn about MECE and make your answers MECE compatible
YMMV but I was able to really make a leap via some deliberate practice over the course of a couple months.
The best way to learn to interview well is to interview other people. You very quickly see what works and what doesn't. Of course, it's difficult to just make that happen in the short term.
In the end, you should just go interview places. You'll quickly learn whether you're all good (because you get offers), or if there are any problems to address. Only worry about it if there are problems.
Your limited experience - internship as work history - will already allude to the fact that you don't have interview experience. You can address that up front during the recruiting process.
After series of failed interviews I got my first job by during interview clicking with my future boss on a personal level and we ended up talking more about Witcher books than job itself lol. Less than a year later I ended up leaving that corpo as despite good performance and good opportunities I was just very wrong cultural fit
So moral of the story is that stuff can be really random and the only way to get it right is to just keep trying
https://news.ycombinator.com/item?id=39754083 also puts it well.
You can also do something like interviewing.io or just have a friend interview you to get an idea without actually having to interview with a company.
But don't interview for jobs you don't want or it is a total waste of time for all concerned. It can't be that hard to find jobs you'd like, so interview for those, even if you don't have a hope of getting them.
Interviewing is a skill just like ML and coding are skills, and you need to practice to do it well. And the best way to practice... is to do it!
And frankly? Everyone should be interviewing on a regular basis, anyway. Always keep an eye on the market and be ready to jump if something better comes along.
Best of luck!
I do a bunch of interviews, just finished one about an hour ago actually. If you've gotten as far as an interview, great stuff! Most CVs go right in the bin.
There'll be a few things on your application that caught the recruiters' eye. No-one wants to waste time interviewing people who they don't think can do the job, on paper at least. You're doing well.
When I'm interviewing, I have three broad questions in my head, in pretty much this order of importance.
a) What is this person going to be like to work with?
b) What can they do that we / the other candidates can't?
c) Was this person honest on their CV?
On a) People want to work with nice people. At least one of the interviewers will be spending a lot of time with you. It depends on the role and company, but particularly with less experienced candidates where the need for some learning is a given, I'd much rather have someone nice than a highly-skilled arsehole.
You want to be relaxed and confident. Tough without experience, but don't sweat it, I have a practical suggestion below. Also smile and make some eye contact, and you're allowed to have a light bit of humour about you. You can use that bit before things get rolling properly for a _very_ light bit of banter. Get things off to a good start.
In terms of getting that confidence? Have you got experienced, professional older friends, relatives? In the sector is best, but not essential. You can ask them to help you out with a mock interview. I've done a bunch for friends and family over the years, it seems to help folks get over your exact concern. Bit of roleplay, they'll need to do a bit of research themselves (e.g, on technical questions) so it'll need to be someone who's will to go out their way for you.
On b) side-projects are good here as you suggest, particularly when you're young. You always want to be able to give examples of things you've done (check out the STAR method), and more projects means more to talk about and more chance you're bringing that X factor to the table.
Right now if you're into ML, others in the thread may disagree, but maybe give an LLM project a go? I'm recruiting for an ML-adjacent role (vis/analyst) right now, we're having ML practitioners apply, and only one or two candidates have any experience with LLMs. Total differentiator. We're too busy to learn stuff, would much rather get someone in whose time isn't yet eaten up to check it out. Have a head start.
c) Actually pretty rare and pretty easy to spot most of the time. I hope that's not you, I spent a while on this ;-)
Good luck!
The best thing I learned from the book was that for some positions, interviewers weigh your experience more heavily than your side projects.
This, like all advice on this topic, highly depends on the company, the individuals interviewing, and your side projects.
I typically think of it this way.
When you are fresh out of college you've had little to no professional experience - the most you've had is probably an internship. For an employer to hire you, they'll probably evaluate your internships, school work, and personal projects. It's evidence of your knowledge and how well you'll fit into a role.
After your first job - it's much different. Employers care much more about your experience, because you've worked within scenarios that you'll work in at their company. With fresh graduates, it would be unfair to evaluate them on years of working experience - because they won't have any - which is how personal projects come into play.
An employer will want to hear more about your experience at X company, because you've worked on things that have users, scale, and issues that come with all of that and more - which personal projects sometimes do not have.
That being said, personal projects can matter more if: 1) You are changing tech entirely, so you have a project to act as evidence of your newly gained knowledge, 2) Your personal project is running somewhere and has users, and/or 3) you work on open source projects. There's probably many more reasons that I'm missing.
I'm typing all this out because for me I weighed personal projects much too heavily. My first company had extremely outdated code and custom frameworks everywhere - I was afraid that my experience didn't mean anything. I kept on trying to find time to work on projects, and which led me to never try interviewing - because my projects were never done. Reading the book I suggested helped me to break out of this belief - and led me to find a new position.
Aside from all that I've said - the other things you suggested are good: taking interviews as practice and going through interview exercises.
Pramp[1], and other resources people have recommended here, are really good to practice with. That being said - the best practice is to be in an actual interview. I highly recommend finding companies that you aren't that interested in and interviewing there.
You may find that you are much less nervous! Going into an interview not caring about the outcome and maybe even expecting to fail really calms the nerves. Additionally, if you pass the interview and find that you actually like the company - then more power to you. Accept the offer and cut your practice short.
My final piece of advice - I know it is tempting to take time off to practice - but the best time to find a job is when you are employed. It's less nerve wracking knowing that you still have a way to make money if you fail the interview you are in.
As I mentioned previously, this always depends. For example, if you're living with your parents rent-free and your expenses are really low - then it is up to you. For many other people, it could lead to situations where you are running out of funds, and now you have to take the first offer you get.
1) Do some research. Know what the company does and some of the basics of how their industry functions. Try to know where the money is coming from etc. This base understanding will help you not to come across as a total liability.
2) Do some research (2). Read and reread the job description or if unclear give the recruiter a call and ask them what they are really looking for. The job spec should have some info in there and it would be good to decompose it a bit.
- Stuff they will expect you to know. eg "We're looking for a pytorch dev...". OK you need to know python and pytorch. Yes if you've been doing tensorflow still apply, but play around with pytorch a bit going into the interview so you know a bit about the differences. Say you've mainly done tensorflow but you've been using pytorch and it's been faster/slower/more ergonomic/whatever. Try to be positive though - Noone wants to hire someone who is going to spend all their time whining about the tech stack.
- Stuff they will expect you to be able to do. eg "...to help optimise our data ingest and embedding thingummybobber." OK so as well as basic ML dev stuff I'm going to need to know a bit about data wrangling. Maybe brush up on sql and a few other things to do with making data pipelines, cleaning data etc. Or maybe it mentions training so reread your stuff about gradient descent, regularization etc. You don't need to be the world's expert but you want to give yourself the best possible shot.
- Characteristics that are desireable in some way. eg "... The ideal candidate will have some knowledge or experience of ML as it is applied to customer-facing yadda yadda". OK so scratch your head about what you've done that you can say relates to this etc.
Ideally for each of the main things you have thought through how this applies to you in some way and have some bullet points in your head ready to go if you get asked.
For a first job they aren't expecting you to know everything so the main things they'll be looking for is your potential. Do you seem smart? Are you going to be able to learn quickly? Are you likely to be able to get shit done? etc. Try to think through what you might be able to say that is evidence of each of those things. Smart: think of something (even unrelated) that you have learned deeply. Eg you became the resident expert in regexes in your computer lab at school or you got totally into abstract algebra and nerded out on that or whatever. Quick study: When you went to school maybe you only had done Javascript dev and then you had to pick up python or vice versa. Some evidence that you can learn and adapt.
You can really help yourself a lot if you think about these things so you have something at your fingertips when they ask you a question about how you're going to be able to learn.
just throw yourself in the pool, you'll learn to swim.
My piece of advice is to remember your star format, and if you don't know exactly how to do something. Tell them, and then walk them through how you would do it based on what you know. tldr; throw a hashmap at it.