# Coding interview preparation for software engineers Confirm the coding format, clarify the problem, and explain a correct approach before optimising it. Implement in a familiar language, test ordinary and boundary cases, and state time and space costs. Practise spoken reasoning and executable code separately when your practice tool does not run code. About 7 min read. ## On this page - [Confirm what kind of coding interview you will have](https://preprole.com/guides/coding-interview-preparation#format) - [Turn the prompt into a contract before writing code](https://preprole.com/guides/coding-interview-preparation#clarify) - [Worked example: remove duplicate IDs without changing order](https://preprole.com/guides/coding-interview-preparation#worked-example) - [Explain complexity with the assumptions attached](https://preprole.com/guides/coding-interview-preparation#complexity) - [Test the contract, not only the example](https://preprole.com/guides/coding-interview-preparation#tests) - [Recover when your approach stops working](https://preprole.com/guides/coding-interview-preparation#getting-stuck) - [Use a repeatable coding rehearsal](https://preprole.com/guides/coding-interview-preparation#practice-plan) ## Confirm what kind of coding interview you will have Ask whether the interview uses an algorithm exercise, code review, debugging task, or role-specific implementation. A browser exercise without execution needs different preparation from a repository you can run. Confirm the permitted language, tools, documentation, and AI assistance before practising. Do not assume that a familiar interview label tells you which resources are allowed. Amazon recommends checking likely subjects with your recruiting contact and applying computer science knowledge rather than memorising details. Atlassian's handbook describes data structures and code design within its own coding interviews. These are examples of employer guidance, not a shared format or scoring rubric. Use the invitation and your recruiting contact to decide what to prioritise. Reference: [Amazon Careers: software development interview topics](https://amazon.jobs/content/en/how-we-hire/interview-prep/software-development-topics) ## Turn the prompt into a contract before writing code Restate the requested input and output in your own words. Ask about the constraints that could change your solution: input size, ordering, duplicates, invalid values, and whether the input can be modified. Then work through an example with the interviewer. You are checking that you are solving the same problem, not trying to delay the implementation. If the interviewer asks you to choose an assumption, state it and continue. For example, you might assume event identifiers are case-sensitive strings and that missing identifiers are rejected upstream. Explain how a different assumption would change the code. Avoid spending the entire opening on remote possibilities that do not affect the approach. - Input and output: identify the values and their types - Constraints: establish relevant size and memory limits - Semantics: confirm order, equality, and duplicate handling - Examples: check an ordinary case and one boundary case ## Worked example: remove duplicate IDs without changing order Consider this illustrative practice problem: return each event ID once, preserving its first appearance. For input [b, a, b, c, a], the output is [b, a, c]. Sorting and removing duplicates would change the requested order. Checking the example before coding prevents you from optimising a solution to a different problem. A baseline approach scans the output to see whether each incoming ID is already present. It can take quadratic time when many IDs are distinct. An alternative keeps a set of seen IDs alongside the output. For each ID, append it only if it is absent from the set, then mark it as seen. Explain why every distinct ID appears once and why append order preserves the first occurrence. - Implement the baseline if you need a working starting point - Introduce the set to avoid repeatedly scanning the output - Keep the membership check, append, and set update consistent - Explain the invariant: the output contains first occurrences from the processed prefix > My output starts empty, as does my seen set. Reading b appends b; reading a appends a. The second b is already seen, so I skip it. I then append c and skip the final a. This produces [b, a, c] without modifying the input. I would check that the chosen language's set uses the equality behaviour we agreed on. ## Explain complexity with the assumptions attached Let n be the number of input IDs and k the number of distinct IDs. The set approach takes expected O(n) time under the usual constant-time hash-set operations. It stores O(k) IDs in the set and O(k) values in the output. The auxiliary space is still O(k) if you exclude the returned output; a separate set is not free memory. State which property of the data structure your analysis relies on. Do not describe every hash-table operation as a worst-case constant-time guarantee. If memory is constrained or the data arrives as an unbounded stream, discuss that changed problem explicitly. You might need an external store, a bounded deduplication window, or a different contract. Do not claim the original implementation solves those variants unchanged. ## Test the contract, not only the example Predict the result before running each test. For this example, check an empty list, one ID, repeated identical IDs, all-distinct IDs, and duplicates separated by other values. Include case differences if equality is case-sensitive. A test is more useful when you can explain which requirement it protects, rather than listing unusual inputs without an expected answer. When execution is allowed, run the code and investigate failures before announcing that it works. Check language-specific details such as collection initialisation and mutation. Without execution, trace values through the implementation and say which checks remain unverified. Spoken confidence and a plausible-looking loop do not establish correctness. A practice tool's positive feedback does not replace a test run either. - Empty input returns an empty output - All-distinct input preserves the entire original order - Repeated IDs appear only at their first position in the output - The input remains unchanged when that is part of the contract ## Recover when your approach stops working If you are stuck, identify the unresolved part aloud. You might understand the desired output but lack a data structure, or have a correct baseline that misses the requested complexity. That is more actionable than saying you have no idea. Work a smaller example, write down an invariant, or ask whether a baseline implementation would be a useful next step. Treat a hint as new information. Explain which assumption or operation changes, then revise the approach. Avoid defending an incorrect solution because you have already spent time on it. If time expires, distinguish implemented behaviour from intended improvements. Do not claim unfinished code handles a case you have not traced or tested. ## Use a repeatable coding rehearsal Choose an unfamiliar problem at a difficulty where you can make progress, then practise clarification, explanation, implementation, and testing in that order. Use a timer as a rehearsal constraint, not as a claim about an employer's time limit. Keep a note of where you lost time: understanding the contract, recalling syntax, selecting an approach, or debugging. On the next attempt, change one constraint instead of reciting the same solution. Ask what happens when order no longer matters, memory is limited, or equality rules change. This checks understanding beyond recall. Rehearse with invented or public data, never proprietary source code or customer records. Follow the employer's rules about assistance in the actual interview. ## Frequently asked questions ### Should I memorise coding solutions? Learn the reasoning behind patterns, then solve unfamiliar variants. Recognising a pattern is useful, but you still need to clarify the contract, justify the approach, and test your implementation. Repeating a remembered solution without noticing a changed requirement can solve the wrong problem. ### Which language should I use? Use a language allowed by the employer that you can implement and debug in comfortably. Practise its collections, equality rules, and common operations. Do not switch to a less familiar language solely because a practice solution used it. Confirm whether the interview requires a particular stack. ### Is talking through code enough preparation? No. Spoken reasoning and executable correctness are different skills. Practise both. If the exercise does not allow execution, explain your manual checks and their limits. PrepRole's Code Pad is read by the AI Interviewer but never executes code, so run implementations separately. ### What if I cannot reach the optimal solution? Explain the correct approach you have, its costs, and the bottleneck you would improve. Use hints and test cases to make progress. A baseline is not a guarantee of a favourable evaluation, but it gives the interviewer more evidence than silently searching for an ideal solution. ## Practise the next answer Use a Mock Session to rehearse your explanation and responses to follow-up questions. When the session includes the Code Pad, the AI Interviewer can read it but never executes your code. Run your implementation and tests separately in your own environment. Review a Scorecard for reasoning you could explain more clearly, not as proof that an algorithm is correct. Practise for your job: https://preprole.com/setup [Understand the Interview Stages and Code Pad](https://preprole.com/guides/stages) ## Sources and scope Employer sources describe their own processes, which may change. The exercises and illustrative examples are PrepRole editorial guidance, not employer questions or hiring criteria. - [Amazon Careers: software development interview topics](https://amazon.jobs/content/en/how-we-hire/interview-prep/software-development-topics) - [Atlassian: engineering interview handbook](https://www.atlassian.com/company/careers/resources/interviewing/engineering) ## Related guides - [Explain implementation decisions from your projects](https://preprole.com/guides/technical-deep-dive-interview) - [Prepare for architecture rather than coding](https://preprole.com/guides/system-design-interview-preparation) - [Prepare your own questions for the interviewer](https://preprole.com/guides/questions-to-ask-interviewers) AI feedback can be wrong. A practice Verdict is not a hiring decision.