Editorially revised on 9 October 2026.
Prepare for the technical task the role actually requires
Technical interview preparation starts with the role and the assessment format. A software role may include code, debugging or design; another technical role may involve calculations, equipment knowledge or a practical explanation. Do not assume that every technical interview requires the same algorithms, platform or system-design questions.
Check the actual invitation and role description. Identify the scope, permitted tools, time or format instructions and what you may need to explain. Harvard's interviewing resource supports role research, preparation and clear explanations. Its examples do not establish a universal technical interview process or employer scoring rubric.
This guide works through an original Python practice task, including a contract, a failing approach, a corrected implementation and tested cases. It is not a proprietary employer question, production-ready utility or evidence that someone passed an interview. Use the method to practise a task relevant to your own role.
Confirm the contract before choosing an implementation
The original task is: accept a Python list of nonblank strings and return a new list containing the first occurrence of each exact string, in the original order. Do not alter the input list. Reject a non-list input or non-string item with TypeError; reject an empty or whitespace-only string with ValueError.
The contract deliberately uses exact string equality. It does not trim the returned values or merge upper- and lowercase forms. Therefore "A", "a" and " A " are different values. Whitespace-only strings are invalid, but surrounding whitespace in a nonblank string is retained. These are practice rules, not a recommendation for real customer identifiers.
An empty input list is valid and returns an empty list. The task does not accept a tuple or a comma-separated string as a list. It does not supply requirements for files, network data, concurrent modification or untrusted custom object subclasses. Keep those limits separate from the small built-in-value exercise.
Explain why a tempting shortcut does not meet the whole contract
A tempting draft is return list(set(items)). Python's data structures tutorial describes sets as collections without duplicate elements and without a defined sequence order. The shortcut therefore does not guarantee the required first-occurrence output order. It also does not implement the supplied type and blank-string checks.
Another draft, return sorted(set(items)), explicitly changes the order. For the input ["B", "A", "B"], the contract requires ["B", "A"]; sorting produces ["A", "B"]. This is a concrete failing case even though both outputs contain the same unique values.
The failure is a mismatch with the task, not proof that sets or sorting are bad tools. A set can track membership while a separate list records the intended order. Explain which requirement each structure addresses instead of selecting a familiar technique before reading the contract.
Use an original bounded implementation
The following implementation uses a list for ordered output and a set for membership tracking. The input validation belongs to this exercise's stated contract.
def unique_strings(items):
if not isinstance(items, list):
raise TypeError("items must be a list")
seen = set()
output = []
for value in items:
if not isinstance(value, str):
raise TypeError("each item must be a string")
if not value.strip():
raise ValueError("strings must not be blank")
if value not in seen:
seen.add(value)
output.append(value)
return output
For ["B", "A", "B"], the first B is appended, then A, and the second B is skipped because it has already been seen. The returned list is ["B", "A"]. The code does not sort the output or assign into the input list.
Validation occurs while reading the values. If a later item is invalid, the function raises instead of returning the partially built output. The exercise does not expose that local partial list. It does not promise a complete error report listing every invalid item in one call.
Check meaningful cases, including the intended failure
The exact public implementation was run against the following original cases during editorial verification. The outputs and expected exceptions matched for these finite cases. That checks these examples, not every possible Python object or a production application's requirements.
| Practice input or condition | Expected result |
|---|---|
["B", "A", "B"] | ["B", "A"], preserving first occurrence. |
[] | []. |
["A", "a", " A ", "A"] | ["A", "a", " A "], keeping exact forms. |
["x", "x", "x"] | ["x"]. |
["दिल्ली", "दिल्ली", "पुणे"] | ["दिल्ली", "पुणे"]. |
Tuple, string or None as outer input | TypeError. |
A number, boolean or None inside the list | TypeError. |
| Empty or whitespace-only string inside the list | ValueError. |
The ordering case checks the requirement that the sorting shortcut fails. The exact-form case checks the decision not to normalise. The invalid-input cases check the exception contract. A separate check confirmed that the input list remains unchanged and the returned object is a new list.
Python's unittest documentation describes assertions for results and exceptions. Tests are useful evidence when they address the contract and important boundaries. A green finite test suite is not a hiring score or a guarantee of all correctness.
Explain the approach and its limits clearly
You can explain the solution in a few steps: validate the outer type, inspect each string, reject a blank value, track values already encountered and append only the first occurrence. The output order comes from the list, not iteration over the set. The set's purpose is membership checking.
The function reads each list item once in its loop, but that observation is not a blanket wall-clock performance guarantee. String length, hashing, equality and memory use matter. If an interviewer asks for complexity, state the assumptions you use rather than claiming the same runtime for every input or implementation.
The output and membership structure require additional storage for distinct values. This toy task does not establish whether that is acceptable for a large real dataset. A different requirement—streaming input, normalised identifiers or a complete error report—would need a different contract and potentially a different design.
Respond to changed requirements explicitly
Suppose a practice interviewer asks whether "A" and " A " should now count as the same identifier. That changes the contract. Clarify whether trimming is required, which form should be returned and whether case also changes. Do not silently modify one assumption and leave the expected output unexplained.
Likewise, accepting any iterable rather than only a list would change validation and possibly the way errors occur. Reporting all invalid items would change the error contract. An in-place result would change the mutation rule. Identify the changed requirement before offering a revised solution.
You do not need to pretend a new version is already tested. Explain the proposed change, then run the relevant checks if the format and tools permit. A proposal and an observed result are different parts of the record.
Practise communication with the permitted tools
Rehearse explaining one failed case and one correction. Ask a willing partner to check whether the input, output and assumption changes are understandable. Their feedback can identify a missing explanation; it does not certify technical competence for every role or predict an employer's assessment.
Follow the actual interview's rules for editors, documentation, calculators, internet access and AI tools. A tool available during private practice is not automatically permitted during an assessment. Do not use hidden assistance, record without agreement or share proprietary interview materials with an external service.
For the wider listening and evidence sequence, see interview skills. For correcting answer overclaims and logistics gaps, see common interview mistakes.
Frequently asked questions
Does every technical interview involve coding?
No universal format is established here. Check the actual role and invitation.
Does the toy function normalise identifiers?
No. It keeps exact strings and rejects only blank strings under the stated contract. A real normalisation requirement needs separate clarification.
Does passing these tests prove production readiness?
No. They verify the supplied finite cases and mutation rule. Real applications may require additional contracts, security and operational checks.
Can I use documentation or AI in an interview?
Use only what the actual process permits. Ask the designated contact when an important rule is unclear.