AI tools are now a normal part of how students write code. Used well, ChatGPT, Claude, or Gemini can help you find bugs faster, understand unfamiliar code, and practise DSA with a patient tutor available at midnight before your online assessment. Used badly, they produce code you cannot explain, tests that test nothing, and a false sense of preparation that collapses in the first technical interview.
This guide shows how to prompt for the most common coding tasks, with good and weak examples, and how to use AI for DSA without becoming dependent on it. One rule runs through everything: verify every output yourself.
The golden rule: give context, then verify
Coding prompts fail for one main reason: missing context. The model cannot see your project, your error, your language version, or what you already tried. Every good coding prompt includes:
- Language and environment (Python 3, Java 17, Node, the framework you use)
- The code (the relevant part, not the whole repository)
- The exact error or wrong behaviour (copy the full message)
- What you expected versus what happened
- What you already tried
And every answer needs checking. AI can produce code that looks correct, compiles, and still fails on edge cases. It can suggest library functions that do not exist or have different names. It can confidently explain a bug that is not the real bug. Run the code, test it, and read it line by line before you trust it.
Privacy note: never paste API keys, passwords, database credentials, or your company's or client's confidential code into a public AI tool. If you are an intern, check your team's policy first.
Debugging prompts
Weak vs strong
Weak: My code is not working, fix it.
Strong: I am writing a Python 3 function to merge two sorted lists. It returns the correct result for most inputs but crashes with "IndexError: list index out of range" when one list is empty. Here is the code: [paste code]. Expected output for merge([], [1, 2]) is [1, 2]. Do not rewrite the whole function. Point out the specific line causing the error, explain why, and show the minimal fix.
The strong prompt asks for the cause and a minimal fix, not a full rewrite. A full rewrite might work, but you learn nothing and may introduce new problems.
Ask for hypotheses, not just answers
When a bug is unclear, ask the model to think like a debugger:
My React component renders twice and the API call fires twice on page load. Here is the component: [paste]. List the three most likely causes in order of probability, and for each one tell me how I can confirm or rule it out myself.
This turns the AI into a guide for your own investigation. You run the checks, so you understand the result.
Debugging template
Language/version:
What the code should do:
What actually happens (full error message):
Minimal code that reproduces it:
What I already tried:
Please: identify the likely cause, explain it, suggest a minimal fix.
Explaining code you did not write
Whether it is a senior's project, an open source library, or a starter repository for your internship, you will often read code you did not write.
Weak: Explain this code.
Strong: Explain this Java method to me as a final year student who knows OOP and basic collections but has not used streams much. First give a two line summary of what it does. Then go through it block by block. Finally, tell me one edge case where it might behave unexpectedly. [paste code]
Then check your understanding by flipping the roles:
I will now explain this code back to you in my own words. Tell me what I got right, what I got wrong, and what I missed. My explanation: [your explanation]
This second step is where real learning happens. It is also exactly what interviewers do when they ask you to walk them through your own project.
Code review prompts
AI is a useful first reviewer before you push code or submit a college project. Be specific about what kind of review you want.
Weak: Is this code good?
Strong: Review this Node.js Express route handler as a strict senior developer would. Focus on: input validation, error handling, security issues (such as injection or exposed secrets), and readability. For each issue, give the line, the problem, why it matters, and a suggested fix. Do not comment on formatting. [paste code]
Useful review angles
- Security: "Check this login handler for common security mistakes."
- Performance: "This loop runs on a list of up to 100000 items. Identify anything that would be slow and why."
- Readability: "Suggest better names for variables and functions, and point out anything a new teammate would find confusing."
- Edge cases: "List inputs that could break this function."
Treat review comments as suggestions, not orders. Some will be wrong or irrelevant to your context. Your job is to understand each one and decide.
Writing tests with AI
Tests are where AI can save real time, and also where it quietly fails most often. A common problem: the model writes tests that simply mirror the current code, so a bug in the code becomes a "passing" test.
Write tests from the requirement, not the code
Weak: Write tests for this function.
Strong: Here is the specification for a function is_valid_password(s): at least 8 characters, at least one digit, at least one uppercase letter, no spaces. Write pytest unit tests based on this specification only. Include normal cases, boundary cases (exactly 7 and 8 characters), and invalid inputs (empty string, only spaces). Name each test clearly so the failure message explains what broke.
By giving the specification rather than the implementation, you get tests that can actually catch bugs.
Then verify the tests
- Run them. Do they pass for the right reasons?
- Deliberately break the function. Do the tests fail? If not, the tests are weak.
- Read each assertion. Is the expected value actually correct?
Adding meaningful tests to your college or personal projects is also a strong signal on a resume, because it shows you think about correctness, not just features.
Learning DSA with AI without becoming dependent
This is the most important section. Online assessments and technical interviews for most fresher roles test whether you can solve problems, usually without AI assistance. If AI solves every problem for you during practice, you are training the AI, not yourself.
The rule: attempt first, then ask for the smallest help
Spend real time on a problem alone first. When stuck, ask for help in increasing levels, stopping as soon as you can continue.
Level 1 (hint): I am solving "two sum" on an array. I have a brute force O(n²) solution. Do not give me code or the full approach. Give me one hint that points me toward a faster idea.
Level 2 (direction): I still cannot see it. Which data structure would help, and what question should I be asking for each element? Still no code.
Level 3 (approach): Explain the approach in plain words, without code. I will write the code myself.
Level 4 (review): Here is my solution: [paste]. Do not rewrite it. Tell me if it is correct, its time and space complexity, and which edge cases it misses.
Most of the time, Level 1 or 2 is enough. That struggle is exactly what builds problem solving ability.
Prompts that build understanding
I solved this problem with a sliding window. Give me two similar problems that use the same pattern, and one problem that looks similar but needs a different technique. Do not include solutions.
Act as an interviewer. Ask me to solve "merge intervals". Do not give the answer. When I propose an approach, ask follow up questions about complexity and edge cases, the way a real interviewer would.
Explain why my recursive Fibonacci solution is slow, then guide me to convert it to dynamic programming using questions rather than giving me the code.
Signs you are becoming dependent
- You open the AI before reading the problem fully.
- You can read a solution and nod, but cannot write it on a blank page the next day.
- You cannot state the time complexity of your own submitted code.
If these sound familiar, try a simple fix: solve one problem a day with no AI at all, on paper or in a plain editor, then use AI only to review afterwards.
Verify everything: a checklist
Before using any AI generated code in an assignment, project, or job:
- Run it. With normal inputs and edge cases (empty, single element, very large, negative, duplicates).
- Read it. Every line. If you cannot explain a line, do not ship it.
- Check libraries and functions. Confirm they exist in the official documentation for your version.
- Check complexity claims. Work out the time and space complexity yourself.
- Check the explanation against the code. AI sometimes describes what the code should do, not what it does.
- Follow your college or employer rules. Many institutions have clear policies on AI use in graded work. Respect them.
What to do next
AI can make you a faster, more confident programmer, but only if your own understanding grows alongside it. Start with these steps:
- Save the debugging template and use it for your next bug.
- Pick five DSA problems this week and use only the Level 1 and Level 2 hint prompts.
- Ask AI to review one of your existing projects, then fix the issues yourself and add real tests.
- Practise explaining your project code out loud, since interviewers will ask.
To build these skills in a structured way, explore our courses, plan your preparation with a personalised career roadmap, and when you feel ready, start applying through the jobs board.