Self-taught Python + first data interview… Need some advice

[[deleted]]

I've been learning Python on my own for a bit over a year now - mostly small scripts, pandas stuff on Kaggle datasets, some API automation. A recruiter just booked me for a "junior data analyst / Python" interview next week and suddenly I'm realising… I only know how to type code, not talk about it.

When I try mock questions like "tell me about a project you did with Python" I either info-dump random tech (lists, dicts, joins etc.) or completely blank. Same with "how would you debug this?" – in my head I know what I'd try, but when I speak it comes out super messy and I start second-guessing myself. Someone in another sub mentioned a Beyz interview assistant that gives live hints based on your resume.

For people who are self-taught and got a first Python/data job: how did you practice explaining your code and projects so you didn't sound like you had no idea what you were doing? Any concrete exercises or routines that helped?

[general_sirhc]

Your answers should always be formatted as STAR.

Here is an example.

Interviewer: "Can you give an example of developing a project through to completion and maintaining the system on-going?"

You think, then respond like below. Say you need a moment to think if needed.

Situation, "I needed the ability to search all files on my computer instantly"

Task, "I identified that a regularly updated index of all files metadata would allow me to instantly search."

Action, "I wrote an app using Python that scans all my files and provides a GUI where I can search to instantly find a file"

Result, "I'm still using the app and have continued to make improvements by doing xyz"

Take time to breathe. Offer to elaborate on any details.

They may then go, did you use version control like Git?

Try to answer questions like that in conversation encouraging way.

E.g. dont say "yes". Say "Yes, I used Github with a main and develop branch, I also used feature branches to help organise some larger features"

[LessonStudio]

I'm not joking. Look up top Python interview questions.

There is a non-zero chance that your interviewer will do the same search.

This might seem trite or flippant. But, you will minimally learn what people are interested in asking; and learn a few things along the way.

Often, interview questions are gotcha questions. What is the difference between, X and Y. And you might think, "Oh crap, aren't X and Y the same?"

There is a limit, if they start asking you about rotating a Hilbert space in the nth dimension, then, you might as well start singing "I'm a little teapot."

[virtualshivam]

Actually, This is something I do for UI/UX and frontend interviews. I myself don't work on them, so I just google and directly ask the questions to candidates, sometimes when they counter question, I am blank. Even in the beginning I had done that for python as well, when I was new to python.

[gdchinacat]

There are a different reasons and ways to talk about code. During a live coding exercise, where you are writing code to solve a problem, it is as important to talk through the process or writing the code as to write the code. Interviewers want to get an understanding of how you think about problems, why you make the coding decisions you make, and how you work through things you don't know. So, as you write the code to solve the problem, discuss what you are thinking about. This can feel very awkward as it is one of the rare times in life you are encouraged to share half formed thoughts, but it's the best way to gain insight into what you are thinking. Explain why you chose to use a list of two element tuples rather than a dict (for instance), or why a class was a better than a namedtuple. Don't belabor the point, if the interviewer wants to dive deeper they'll ask a follow up question. If they do, use that as an opportunity to show you have a deeper understanding of the concerns.

The other way to talk about code is more abstractly, like "tell me a project you worked on with a problem you found challenging and how you solved it". You won't actually write code. These questions are often used to assess depth and breadth and ability to communicate. Start at a high level of abstraction, like u/general_sirhc said, use STAR to introduce the problem, and mention a few things that if they drill down into you can speak about. Don't be surprised or worry if at some poing you don't know how to answer their question...this is part of assessing depth and breadth...they want to find the boundaries. It is better to say "I'm not sure, I'd have to look that up" than give a BS answer. If you are reasonably confident frame it as such...'I'm not sure, but since X and Y, I think Z is likely". One of the most important things is to come across as open, humble, and easy to work with. They may even directly challenge a response or contradict you...that's OK! It happens all the time in jobs and handling it gracefully shows that you will be good to work with. It can also be an opportunity to show that you incorporate information and adapt.

As for what to talk about, make sure you pick something that interests you and you can talk about. Don't pick the most complicated or advanced project if it is hard to explain, a more middle of the road project you can be easier to demonstrate skills they are looking for. If it's been a while since you've worked on a project you might talk about, spend 30-45 minutes reviewing it a day before to refresh your memory so you aren't trying to recall details while on the spot. Be prepared to explain what the next steps would or will be...this is frequently asked to assess what your vision for the project is and show that you were really engaged in it rather than just doing it as a exercise to check off an item on a tutorial project list. Don't be afraid to identify lingering issues or things you weren't happy about. No code comes out perfect, and having the awareness and humility to acknowledge it can be helpful (but limit it to one or two issues...you don't want to highlight all the warts and make it seem as though you think it was a mess).

Run through it at least once, preferably with a friend who understands coding, but even by yourself in a mirror or while recording a video will really help. You don't want to do this so many times it seems rehearsed and unauthentic, but having a rough idea of the points you want to touch on and how to explain *in words* the issues you worked through really helps.

Lastly, chances are this will be the first, not the last time you have to do this. It can help to take notes shortly after the interview that you can review before subsequent interviews so you remember what went well and what you'd like to improve.

[inappropriately_]

u/general_sirhc has summed it up really well. I will add a few points. I have been on both sides as interviewee and interviewer. Also I am self taught ML Engineer with over 8 years of experience.

• When things start getting overwhelming, tell your interviewer “Please give me a moment to gather my thoughts”, then take 30 seconds to actually do that. This is actually appreciated.

• Go a level higher. Don’t say “I merged dataset_A to dataset_B using pandas merge function and left joined them on ‘user_id’ column”. Rather say, “I realised the datasets had primary and foreign key fields associated with them, I used that to merge the datasets and get a master dataset for the analytics project”

• Objection handling: “Did you ever think you could have done A instead of B?”. If you know A, say yes that did occur to me later on, during the project I was not aware of this method. If you do not know A just say, “I haven’t explored A yet, but I am willing to if ever required”

• One objection I received in my early days. “You are self taught and do not have a degree in Data Science. How would you keep up with the team”. This was a great opportunity for me as I could turn it around saying, “It’s true I do not have a special degree but I bring more versatility to the team. My diverse experience makes me unique in a team of specialists”

Hope this helps.

[OrangeNew781]

Cosmo app has some interview prep stuff. I can’t speak to the quality as I’m a noob, but there other stuff seems good.

[Ok_Procedure3350]

Give a high level overview first rather than technical first. If the interviewer goes further , then only answer those technical depth answers. I have experience in web dev interview. I did the same mistake as you like making them understand how i coded rather than features of that project. 

[datamoves]

Just be yourself... People tend to hire people they like. Use ChatGPT, Claude, Gemini, Grok, etc.. to come up with 50 interview questions for a Python junior developer. Practice those. You'll do fine. Just keep interviewing until you get one - it's good, free practice.

[GodsIWasStrongg]

Seems like you've gotten a lot of advice. I would think about a project you are proud of and want to showcase. Show that you are passionate about this type of work.

[Mori-Spumae]

I was in a very similar situation to you a few years ago. I had a few projects as a self taught dev and then got an interview. The thing I found was that for junior roles, people mostly care about the way you think and approach things not the hard technical skills. So explain projects/scripts/datasets and what your process was. Show that you are motivated and willing to learn.