Developer Portfolio Feedback: Where to Ask and What to Fix

The main routes are a school or bootcamp career desk, developer Discords and study groups, public Q&A on mentoring platforms, paid one-on-one review with a practitioner, and AI checking tools. Each is good at a different kind of check, so it works better to split the job across routes than to expect one source to answer everything.

When choosing a practitioner, look for someone who has read applications for the role you want, rather than someone with a senior title at a well-known company. A backend applicant gets more from one comment by a person who has screened backend candidates than from general advice by a famous engineer. Before sending any repository or file, strip out employer-internal information and personal data.

Send the target role, the job posting, how finished the portfolio is, and two or three specific questions. A message that only says 'could you look at my portfolio?' gives the reviewer nothing to judge against, so the reply tends to be a general impression.

The template below is an editorial suggestion from Preterview, not an official form. Trim or reword it to fit.

• Target role: [e.g. junior backend developer]
• Job posting: [link, or a summary of the required qualifications]
• Stage: [e.g. project selection and order are set, wording not yet polished]
• Question 1: [e.g. from the first screen alone, what does my strength appear to be?]
• Question 2: [e.g. which projects are thinnest on results?]
• Question 3: [e.g. which required qualification in this posting is not visible in the portfolio?]

Avoid asking 'will this pass screening?' The reviewer cannot know, and the answer will be either encouragement or worry. Show the portfolio when project selection and order have just been settled, before the wording is polished. That is the point where advice to restructure can still be acted on.

Act first on comments that name a location, cite a reason, and suggest a direction. These three checks are Preterview's suggested test. A comment missing all three goes into your notes, and you can raise it again in the next review.

'This looks careless' leaves nothing to fix. 'The order management dashboard entry has no result anywhere in it' names the entry, says what is missing, and implies what to add, so it can be fixed the same evening. However blunt the delivery, that kind of comment is the cheapest improvement you will get.

When comments conflict, use the posting's required qualifications as the tiebreaker rather than a vote. If one reviewer wants more performance numbers and another finds them forced, the question is whether the posting asks for high-traffic experience or for judgment in an early-stage product.

Keep every comment from every reviewer in one document. When two unconnected people point at the same spot, fix that first. A wording preference raised by one person can wait.

Each entry should let a reader see your scope, the problem, what you did and why, and the result, without leaving the entry. MIT's career office advises describing projects in a problem, action, result sequence with verifiable scale where it exists official guide. The example below follows that shape and is a hypothetical written by Preterview for illustration.

Before: 'Built a second-hand marketplace as a team of four. Used React, Spring Boot, MySQL, and Docker. Implemented the chat feature and the payment module.'

After: 'On a four-person second-hand marketplace, I owned the chat and payment servers. Chat messages were being dropped, so I replaced polling with WebSockets and added reconnection logic, and confirmed in local tests that message order held after reconnecting. For payments, I chose the retry count and the failure logging approach to handle outages in the external API.'

What changed is the subject and the result. Sentences with no stated owner, which read as the whole team's work, became the scope I owned; the list of technologies became the problems those technologies solved; and a result with its verification condition was added. Nothing about the project was made larger. Every sentence in an entry can come back as an interview question, so it helps to rehearse them; the developer mock interview guide covers how follow-ups on your own projects tend to run.

Do not invent them. State what changed as a fact. A result means the sentence contains a before and an after, which is not the same as attaching a percentage to every line. Writing '30% conversion improvement' on a practice project with no users leaves you with no answer when someone asks how it was measured.

Measure what can still be measured, and attach the conditions. As a hypothetical for illustration, 'list endpoint latency went from about 800ms to about 120ms, averaged over 100 local runs' is a small number that holds up because the environment and run count are stated.

When there is nothing to measure, write factual outcomes. 'Merged three duplicated code paths into one module, so later features change one place instead of three.' 'Wrote a deploy script that reduced a five-step manual process to one step.' Both have a before and an after without a percentage.

For clone projects and bootcamp assignments, add one line about a decision you made differently from the original. The assignment itself is not the issue. Without a stated difference, there is no basis to tell you apart from others who submitted the same brief. 'The tutorial kept state global; here is why I scoped it per screen' is enough.

Suggested order: factual errors, then results and role, then structure, then wording. Left to instinct, most people start with wording because it is the most visible change. Smoother sentences do not add the missing results or scope.

1. Factual errors: broken links, repositories behind access permissions, typos, the wrong company or role name, half-finished pages. These need no judgment calls, so clear them first.
2. Results and role: pick the two or three projects closest to the target role and add one result line and one scope line to each. Move the rest into a short list or cut them.
3. Structure: check that the first screen, before scrolling, shows the target role, a one-line summary, and links to your strongest projects.
4. Wording: polish sentences last. After one pass, show the portfolio to someone new and ask the original questions again to see whether they are now answered.

If you are revising a resume at the same time, start with the project summaries on the resume. Once you know what to emphasize there, the portfolio order tends to follow. The developer resume guide covers that side. Bootcamp graduates handling both at once may also find the sequencing in the bootcamp job search guide useful.

Use an AI check for items that can be judged from text: structure, whether results are stated, whether your role is explicit. Re-check technical judgment and company fit with a person or against the posting. A tool cannot open the implementation behind your links.

Preterview's portfolio check takes a file or link and points out entries missing results or role and structural gaps to fill. It sits alongside a document-based mock interview and post-interview feedback, so a revised portfolio can be turned into practice questions right away. It is free once a day for a signed-up account, and each further review uses 1 pass (as of October 8, 2026; 5 passes start at $6.99). The free review shows scores, the evaluation and one improvement in full; the other improvements show only their titles, and one pass opens them on the result page. Check current terms on the pricing page and the specificity of the comments in a sample report before deciding how much to hand over.

Whatever the tool, avoid reading a score or grade as a prediction of the outcome. A first check gives you coordinates for where to start. Final calls belong to the posting and to human reviewers.