# A beginner’s engineering practice plan: solve, build, explain Build a repeatable practice routine: solve a small problem, explain your approach, test edge cases and revisit it without hints. Pair problem solving with a small GitHub project so you can show both your reasoning and working code. ## Start with a routine you can repeat Akash’s advice to beginners starts with three things: practise problem solving, learn the underlying data structures, and build work you can show. The resources below are his starting points. This plan is Opened’s suggested way to use them; it is not a promise that completing a list will get you hired. Try a 45-minute session on four days each week. Spend roughly 25 minutes attempting one problem, 10 reviewing the point where you got stuck, and 10 explaining or testing your solution. Adjust the time to your college schedule. A smaller routine that survives an exam week is more useful than a timetable you abandon after two days. Choose one language you can comfortably debug. Before an interview, confirm the languages and assessment format with the employer. Do not split your practice across four languages just because the resources support them. ## Give each resource a different job - Skilled.dev: use a foundational lesson when you cannot explain the structure itself. Its course covers topics including arrays, hash tables and recursion. Check the current access terms before paying for anything. - NeetCode Blind 75: use a bounded list to choose a pattern to practise. Start with arrays and hashing rather than treating the whole list as a deadline. - LeetCode: use the problem set for additional attempts and feedback. Availability and premium features can change; you do not need a premium plan to begin this routine. Sources: [NeetCode: Blind 75](https://neetcode.io/practice/practice/blind75) · [Skilled.dev: coding interview course](https://skilled.dev/course) · [LeetCode problem set](https://leetcode.com/problemset/) ## A worked session: finding a pair Suppose the task asks for two positions in a list whose values sum to a target. First clarify whether there is always a solution, whether the same element can be used twice and what to return when nothing matches. Write examples before implementation: duplicates, negative values and an empty list. A straightforward approach checks every pair. Explain why it works and why its work grows quadratically. Then consider a map of previously seen values: for each element, ask whether its complement has already appeared. Explain why checking before inserting prevents reusing the same position. Be precise about the typical linear-time and extra-space trade-off; data-structure behavior and assumptions matter. After you solve it, close the answer and write three sentences: the invariant, the complexity and the case that nearly broke your solution. If you needed a hint, record it. Tomorrow, try again without the hint. A remembered explanation is better evidence of learning than a green submission copied from a video. ### Diagram: A worked two-sum trace: [2, 7, 11, 15], target 9. 1. **Read 2** — The complement 7 is absent. Store value 2 at index 0. 2. **Read 7** — The complement 2 is already at index 0. Return positions 0 and 1. 3. **Check before inserting** — This avoids reusing one position; test duplicates and no-solution cases too. ## Keep a mistake log, not a streak scoreboard Use a plain text file with four columns: problem, failure, correction and revisit date. Example: ‘Pair sum / reused the same index / look up before insertion / revisit Friday.’ This makes your next session obvious. If you repeatedly cannot turn an idea into code, practise implementing the underlying structure or language operation. If your code works but you cannot explain it, rehearse aloud. If boundary cases break it, make a small test checklist. These are different problems; adding ten more random questions will not necessarily fix any of them. ## Build something alongside the problems Reserve one longer weekly session for a tiny project you care about: a campus event search, a CSV expense checker or a reading-list API. Pick one behavior that can be demonstrated and tested. Keep scope small enough to finish a usable version. By the end of week one, have a working happy path. In week two, handle invalid input. In week three, document one trade-off and add a reproducible setup. In week four, ask a friend to run it from a clean checkout and fix the first confusing step. These are suggested milestones, not a four-week job-readiness claim. Sources: [Opened: GitHub projects that show your work](/blog/github-projects-that-show-your-work) ## Know when to change the plan Use the actual role as your guide. An internship assessment may emphasize coding fundamentals; a frontend role may ask you to implement a screen; a backend interview may explore data modeling and failures. Keep practising fundamentals, but make room for the work the employer actually evaluates. At the end of each week, attempt one unfamiliar problem and explain one project decision without notes. Compare with last week’s attempt. If the same obstacle remains, reduce scope and work on that obstacle. Keep applying to roles whose published requirements fit your experience while you learn; there is no universal problem-count threshold you must reach first. ## References - [NeetCode: Blind 75](https://neetcode.io/practice/practice/blind75) - [Skilled.dev: coding interview course](https://skilled.dev/course) - [LeetCode problem set](https://leetcode.com/problemset/) Updated 2026-11-02 by Opened editorial.