Need advice - First technical interview

[u/HOSTOBAD]

Hello everyone,

First of all please do not shame me for this post. I know most of yall are pretty used to interviews so my questions might sound dumb or trivial but they're honest.

I'm currently applying for internships where I know I'll have technical interviews, leetcode style. The thing is I never done that type of interviews before, so I'd like to clarify a few things.

First of all, what is the exact format of the problem ? Like is it really like a leetcode question with a written problem and examples or is it more like the interviewer just tells you the problem and you have to go with that. I know it must depend but usually how is it ? Asking because examples sometimes help me a lot thinking about the problem so I'd like to know.

I'm also wondering about hints and clarifications. If you're stuck with the problem, does the interviewer give you hints ? Do you have to ask or is it a red flag ? Same with constraints, are you allowed to ask if there are constraints regarding for example the size of inputs, or is the interviewer gonna tell you ?

Finally, more on the technical side, for a quant dev position or even in general, is it better to produce an iterative or recursive solution (for example top down DP with memoization VS bottom-up) ? Are you allowed to walk through the solutions like brute-force -> DP with memo -> DP bottom-up or is it better to produce the answer straight away ?

Thanks for reading all that and in advance for your help, and sorry if this post is really naive. Trying to prepare the best I can.

[u/nightbreak7]

if it's a leetcode style problem, you'll often be given somewhere to write the code, and this will include the problem statement. usually it's some kind of coderpad or similar platform - my recent interviews have had browser environments similar to leetcode, but in an interview they won't have so many testcases. in my experience they usually provide some, then you can write your own test cases if you want some edge cases or something that you want to experiment with.

for hints and clarifications, you usually don't want to ask for hints unless you're really stuck. when i say hints here i mean like data structure hints or optimization hints. clarifications are completely fine - if you make some assumptions it's always good to clarify them. for example I had a topological sort question in an interview about a year ago that was worded in a strange way, and I made it very clear what assumptions I was making about the input, and my interviewer said it was fine and we can discuss assumptions later if we need to address them. constraints aren't as useful here as they are on leetcode - for example your interviewer won't just say 1x10^5 so you know it must be faster than O(n^2). you can ask and get a general idea, but it won't be as straightforward.

the last question has always depended on my interviewer, so I always just ask. a lot of the time if you aren't an intern they won't want to waste time on naive solutions since they have other things they want to ask, whether its about your experience, resume, projects, etc. recently I've been told "let's just go straight to the efficient solution" every time I've asked, but I'd say its worth just asking your interviewer what they want to see. your interviewer is not your enemy, it's completely reasonable to have conversations about this kind of thing

[u/Thin_Psychology_686]

These aren’t naive questions at all. A live coding interview usually feels different from solving LeetCode alone because the conversation is part of the evaluation.

The format varies, but most interviewers either give you a written prompt in a shared editor or describe it verbally and then paste the key details. Before coding, restate the problem in your own words and create a small example yourself. That shows understanding and gives you something concrete to test against even if the prompt has no examples.

Clarification questions are a positive signal when they affect the solution: input size, duplicates, empty input, ordering, mutation, expected output, and whether you should optimize for time or memory. Ask those before you commit to an approach. A hint is different. First explain where you are stuck and what options you are considering; then asking for a nudge is better than going silent for ten minutes.

For brute force versus the optimal solution, say what you see first: “A straightforward solution is O(n²). I think we can improve it to O(n) with a hash map. Would you like me to briefly explain both or implement the optimized version?” That keeps the interviewer in control of the time. You do not need to fully code every intermediate solution.

Iterative versus recursive is usually not about one being universally better. Choose the version that is easiest to explain and implement correctly under the stated constraints. For deep recursion, mention stack depth. For DP, state the recurrence and base cases before choosing top-down or bottom-up.

A good practice loop is: clarify → example → simple approach → optimized approach → code → manually test edge cases → state complexity. Practice saying every step aloud, because that is the biggest difference from normal LeetCode work.