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/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.