Treat a suggestion as an unverified contribution
AI can propose explanations, test cases, and implementation alternatives. A plausible response is still a proposal that may misunderstand requirements or use an API incorrectly. Your responsibility is to decide whether the change belongs in the application and whether you can explain its behavior.
GitHub's responsible-use documentation describes limitations of generated suggestions and the need for human review and validation. Tool safeguards do not establish that a particular suggestion is correct. Build a habit of checking the requirement, reading the diff, running appropriate checks, and reviewing the result before accepting it.
For an interview or assessment, follow the explicit rules about tools. Ask the organiser when those rules are unclear. If assistance is prohibited, practise without it and complete the assessment independently. If it is allowed, disclose its use when requested and retain responsibility for the submitted work. Do not turn a tool's fluent explanation into a claim that you independently solved something.
Use a bounded request
Give the assistant a small contract: input, output, constraints, failure behavior, and allowed dependencies. For example, ask for an explanation of a bug in a pure function that totals integer amounts, rather than asking it to rewrite an entire application.
Provide synthetic examples and the minimum code needed. Keep access tokens, private keys, personal records, and confidential project material out of prompts unless an authorised workflow explicitly permits that data. Check your organisation's policy and the selected tool's data handling; do not assume every plan or deployment uses the same retention rules.
A useful learning prompt is: “Explain two approaches, their assumptions, and three counterexamples. Do not provide final code yet.” Attempt the implementation yourself, then use assistance to review it. This makes uncertainty visible and reduces the temptation to copy a solution you cannot defend.
Worked example: generated database code
Imagine an assistant proposes this Python function for a local SQLite learning project:
def find_note(connection, title):
sql = "SELECT body FROM notes WHERE title = '" + title + "'"
return connection.execute(sql).fetchall()
The problem is not merely that a title might contain an apostrophe. User input becomes part of SQL syntax. OWASP's SQL injection prevention guidance recommends parameterised queries to separate data from query structure.
For this SQLite example, bind the value:
def find_note(connection, title):
return connection.execute(
"SELECT body FROM notes WHERE title = ?", (title,)
).fetchall()
Placeholder syntax depends on the database driver; do not copy it indiscriminately. In a personal notes application, parameterisation also does not decide which user's notes may be returned. The verified owner must be part of the access decision and query scope. OWASP's authorization guidance addresses permission checks and access-control testing.
Test a normal title, a title containing an apostrophe, a missing title, and a synthetic injection-shaped string. Confirm that the last input is treated as a literal value. Separately test that a user cannot read another user's record. A successful security-looking test is evidence about that case, not proof that the whole application is secure.
Worked example: a convincing but wrong optimisation
Suppose the requirement is to return the second-largest distinct integer, or no result when fewer than two distinct integers exist. Generated code might sort the input and return its penultimate element. For [4, 4, 9], that returns 4, which appears correct. For [4, 9, 9], it returns 9, violating distinctness.
Use that counterexample to repair the specification and implementation. One valid approach tracks the largest and second-largest distinct values in one pass. Another sorts distinct values, trading additional storage and sorting work for simplicity. Whichever you choose, test an empty list, all equal values, negative values, and repeated maximums.
If the generated tests repeat only the first example, they miss the defect. Write expected outputs from the contract before consulting the proposed implementation. Review whether tests actually exercise the disagreement between the requirement and the code. Testing provides a broader foundation for choosing behavior-focused checks.
Review before executing
Read generated commands and scripts before running them. Pay particular attention to file deletion, network destinations, dependency installation, and credential access. A requested formatting change should not unexpectedly add an upload step or install an unrelated package.
Check dependency names and APIs against official documentation. If a package is unnecessary, prefer the existing standard-library approach. For unfamiliar code, shrink the change until you can explain it. Passing compilation catches certain mistakes; it does not validate ownership checks, business rules, or every edge case.
Keep a short record of material assistance: what was requested, what you accepted, what you rejected, and how you verified the result. This can support a clear project discussion and accurate claims in the resume builder.
Practical exercise: a 40-minute verification lab
Choose a small function from DSA practice. Spend ten minutes writing its contract and five expected results yourself. Use ten minutes to implement it independently. Then request a review or alternative and spend fifteen minutes evaluating each suggested change against your cases and official API documentation.
In the final five minutes, explain a rejected suggestion and an accepted one. If you cannot explain the accepted code, simplify it or remove it. Apply the same approach to arithmetic solutions in aptitude practice. Use Companies to research roles, then consult the employer's actual assessment instructions for tool permissions.
Verification rubric
Award zero for absent, one for partial, and two for complete evidence in each dimension.
| Dimension | Two-point evidence |
|---|---|
| Contract | Inputs, outputs, and important boundaries are written |
| Understanding | Every accepted change can be explained |
| Tests | Independent expectations include a counterexample |
| Safety | Data exposure, commands, and access checks are reviewed |
| Integrity | Assistance respects rules and claims remain accurate |
For this exercise, require all five dimensions to reach two before calling the contribution verified. That is a learning gate, not a security certification or hiring threshold.
Continue on the SDE preparation track
Build on this lesson with Project interviews, Behavioural communication, Revision readiness, Placement mock practice.
Source links
GitHub and both OWASP documents are linked at the relevant claims above. The debugging scenarios, verification workflow, timings, and rubric are original instructional material.