# FAQs ## What’s the best coding language to use? I always do my coding interviews in Java. Not because there’s anything special with Java but because it was my first coding language during my university studies. Over time I started to learn all the libraries for Java and practiced all my coding questions with the language. All my experience practicing and interviewing was in Java, even today when most of my professional work is in Javascript. If you are already committed to using a language, continue using that coding language for your interviews. Spending time learning new libraries and syntax of another language is not always a strong investment. **Keep compounding** on top of what you already know about your programming language and use that to your advantage. However, if you have just begun studying for your coding interviews, I’d strongly recommend using a simpler language like Python. Python is concise, readable, and widely supported for coding interviews. The time-savings of writing Python and reading Python will help you as you’re learning coding problems. But please don’t toss years of Java knowledge to cram Python for coding interviews. ## How many coding problems should I do? It’s not about how many coding problems you solved, it’s about how often you learned something from the coding problems you solved. There’s a lot to learn solving a simple problem like Two-Sum, but solving 1000 variations of that problem doesn’t help your algorithm knowledge. What you should strive for is learning about the **implementation** of each data structure and algorithm along with the **running times** of each of those implementations. If you did well in your university coursework, you likely don’t need to study as much. But if you don’t know what an array is, you’ll have a lot more to learn and practice. For any coding problem you’re working on, determine if you’re learning something new about a data structure or algorithm, or if you’re just applying what you already knew before. **Keep compounding** on learning new details about each data structure and you’ll impress yourself how well you can approach any coding problem. ## What do I do when I’m stuck? Being stuck is a symptom of two possibilities. Either the candidate does not know enough data structures and algorithms for the problem, or a small hint will lead them to solve the rest of the problem on their own. If the candidate doesn’t know enough to solve the problem, then the only thing they can do is to keep **studying** data structures and algorithms. This is a sign the candidate does **not** meet the bar. However, a candidate that can solve the problem after a smaller hint is not penalized and likely to pass the interview. This is because the candidate is able to clearly **articulate** their problem and work with additional information to **solve** the problem. If you’re ever stuck on a problem and you do know enough data structures and algorithms to solve the problem, explain **why** you’re stuck and **specifically** what you need to get unblocked. An interviewer will either be kind enough to nudge you in the right direction or remain silent to avoid exposing the solution. ## Which Interviews Should I Focus on? Interview with **every** possible onsite opportunity. Regardless if you’re actually interested in the company or not, interviewing onsite consistently will give you the most **authentic** practice applying for any job. Being able to solve a coding question is only **one part** of the process. But candidates receive job oers going through the **entire** interview process and doing well at each and every interview. Some may think learning how to solve coding problems really well is enough. But I will argue that doing well on 1 mock interview on a relaxing weekend is **not the same** as confronting 4 back-to-back interview questions during an onsite. Put yourself through the authentic experience as much as possible and reflect on challenges you have going on-site as a full experience. You may learn that you get **tired** after two interviews, you’re suddenly **nervous** being on-site and can’t speak, a 30 minute break makes you **forget** everything you know, or you’re **not prepared** for a behavioral interview after 3 coding interviews. These are the qualities you can’t notice in a single mock interview or solely practicing coding questions. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://smu-seniors.gitbook.io/excel-in-tech/interview/faqs.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.