Coding interviews
Mock coding interviews in one shared editor you can run
Rehearse the coding round the way it happens on the day: someone watching, one editor you both type in, code that has to actually run, and a scorecard at the end. InnerViewHub gives you the room; you bring the person who interviews you.
What happens in a coding room
- One shared editor with live cursors. Both people see every keystroke, with syntax highlighting for Python, Java, C++, Go, Rust, JavaScript, TypeScript and more.
- Code that runs. Run the program in a shared terminal that everyone in the room sees, and type input into it while it runs, so the interviewer can feed in their own test case.
- Your own problems, with hidden tests. Write a problem once with sample tests the candidate can see and hidden tests they can’t. In the room, “Run samples” checks the visible ones, and a submission is scored against all of them by weight, with verdicts such as accepted, wrong answer, time limit exceeded or compilation error.
- Video, chat and private notes. Video sits next to the code, chat is there for hints and links, and the interviewer keeps notes the candidate never sees.
- A replay afterwards. The code is saved, and you can replay how the solution came together, which is the easiest way to see where time went.
A 45-minute session plan
| Minutes | Phase | What good looks like |
|---|---|---|
| 0–3 | Problem | The interviewer reads the prompt once; the candidate restates it and asks about input size and edge cases. |
| 3–10 | Approach | A brute force first, its complexity, then a better idea, before any code is written. |
| 10–30 | Code | Readable code, explained while typing. The interviewer stays quiet unless the candidate is stuck for a few minutes. |
| 30–37 | Test | Walk through an example by hand, then run it. Try the edge cases named at the start. |
| 37–45 | Feedback | Scores and written notes first, then the conversation. |
Agree on the hint policy before you start. A good default: no hints for the first five minutes of being stuck, then the smallest hint that unblocks (“what if the input were sorted?”) rather than the answer.
The coding interview scorecard
For a problem-solving interview, InnerViewHub asks the interviewer to rate these five criteria from 1 to 5, and then give an overall signal from strong hire to strong no hire.
| Criterion | What a strong score means |
|---|---|
| Communication | Explained their thinking clearly and asked good clarifying questions |
| Problem solving | Broke the problem down and found a sound approach |
| Correctness | The solution works, including edge cases |
| Code quality | Readable, well-structured code with good naming |
| Testing | Tested the code and reasoned about complexity |
The candidate rates the interviewer as well, on clarity, helpfulness, professionalism. Reviews build up over time, so you can see which criteria improve from one session to the next. See the feedback rubric for what each score means.
A starter practice set
Six well-known problems that cover the patterns coding rounds lean on. The third column is what the interviewer should watch for. Swap in your own once you have a rhythm.
| Problem | Pattern | What to watch for |
|---|---|---|
| Longest substring without repeating characters | Sliding window | Does the candidate explain why the window only moves forward? |
| Merge overlapping intervals | Sorting | Edge cases: touching intervals, a single interval, unsorted input. |
| Top K frequent elements | Hash map + heap | Can they compare a heap with bucket sort and justify the choice? |
| LRU cache | Design + data structures | O(1) get and put; do they test eviction order? |
| Course schedule | Graphs, topological sort | Cycle detection, and how they represent the graph. |
| Validate a binary search tree | Recursion | The classic bug: checking only the direct children. |
Tips for the person playing interviewer
- Don’t rescue too early. Silence while someone thinks is normal. Note the time they got stuck and wait before hinting.
- Ask “how would you test this?” before they run anything. It separates people who run code to find bugs from people who reason about it.
- Add one follow-up. “What if the input doesn’t fit in memory?” shows how the candidate adapts.
- Give feedback with evidence. Quote the moment: “You wrote the loop before agreeing on the approach, and rewrote it at minute 24.”
Common questions
Which languages can we run?
Common interview languages including Python, Java, C, C++, C#, Go, Rust, JavaScript and TypeScript. The language picker in the room shows exactly what is installed.
Is it free?
Creating an account and running interviews is free.
What about system design?
Pick a system design interview and the room opens with a shared whiteboard instead of the editor.
Set up a coding mock
Create a room, choose “Problem solving”, and invite the person who will interview you.