IMPORTANT! When you fork, make sure you uncheck the box that says "main only" so that the
solution
branch will be included from the beginning
Navigating the Files | Updating Your Forked Repo | Practicing Live Coding | Most Important
This collection of practice problems is intended for students/graduates preparing for their first rounds of technical interviews. It is recommended to put in a few hours of practice every week for several weeks ahead of any mock interviews or real interviews. You can also pair with peers to "interview" one another and get more comfortable with having a conversation throughout the process.
In each subdirectory you will generally find three files:
practice.js
- code this in themain
branchprompt.md
- read if practicing solo, or have a peer prompt you if practicing with otherssolution.js
- view this in thesolution
branch after you've solved it your own way
From time to time I will add or change content in this repository. If you forked and cloned this repo, you will need to pull in my changes.
If you run git remote -v
and you see only your origin
remote repo, run the following command:
git remote add upstream https://github.com/Carolista/live-coding-practice-problems
You can confirm with git remote -v
and you should see the upstream
repo listed.
Run git fetch upstream
to ensure your local repository has updated knowledge of what changes I have made to my original repo.
First, if you are not in the main
branch, use git checkout main
to switch. Then run the following command:
git merge upstream/main
You should now have my changes incorporated into yours. Push your newly merged version of main
to your own remote repository:
git push
Use git checkout solution
to switch branches again. Then run the following command:
git merge upstream/solution
Push your newly merged version of solution
to your own remote repository:
git push
- Have someone read you the prompt (or read it yourself if practicing solo).
- Take notes using comments in
practice.js
and confirm you understand the requirements and expected result. - Ask clarifying questions, if possible.
- Take note of any test data that is provided.
- Take note of any expected results that are provided.
- Talk through how you want to approach solving the problem.
- Think about variables and mechanisms like conditionals, loops, etc. needed.
- Consider if a helper function would be useful.
- TALK ALOUD even if you're by yourself — this practice is essential!
- Using a comment block (
/* */
), write out pseudocode. - Don't use actual code syntax.
- DO structure your pseudocode a bit, using indenting where helpful to indicate control flow.
- Keep talking aloud as you code.
- Try to use proper technical vocabulary (Example: Pronounce
words[i]
as "words at index i", etc.) - Seriously, keep talking OUT LOUD. This is a skill that has to be built over time, with practice.
- If you are practicing with a peer, talk to them like they are your interviewer. Ask them questions if you are second-guessing something or are still unsure of the end goal. They might give you hints.
- Don't be too quick to run the file. You may not always be able to do that in an interview.
- Instead, practice talking through the solution. What would happen to the test data as your code would be executed? Talk it out line by line. If there are loops, talk it through one loop at a time.
- See it through to the end and make sure the result is as expected.
- Run the file to verify the result after talking it through.
- If your code doesn't produce the expected result, show off your debugging skills.
- Keep refactoring as needed.
If working with a peer, discuss how things went and get feedback on what you can do to improve even more for the next time.
Be patient with yourself! It is difficult to get comfortable with this process and takes a lot of practice. Put the time in, follow the process, and it will pay off. The more you practice, the more you'll see yourself improve over time.