Skip to content

Portfolio

A portfolio is a page per project with a photo, a measured result, and the files. It is optional. Expect most screeners to skip the link, and no portfolio replaces the resume. It pays off later, when a hiring manager wants to see the work behind a bullet, and it pays off most for a student with hardware to show: a board you laid out, a bench you built, a scope capture that proves the thing works. If that is you, build one. It takes a weekend, and less with an AI tool doing the layout. Keep it small, keep every link alive, and post the same projects on LinkedIn as you go.

Expect the first screener to skip it. The section on how a resume gets read on the resume page shows how many seconds a page gets. The link gets clicked later, by a hiring manager or an interviewer, and then it has to work. One hiring manager who reads hundreds of resumes sees dead GitHub and LinkedIn links all the time (opens in a new tab). A dead link costs more than no link.

The portfolio helps most when you have no internship. An ECE graduate with no work experience who got an offer in February 2026 kept a master resume, chose 2 of 6 projects per posting, and linked a portfolio that showed the projects in depth (opens in a new tab), with a web version where the application allowed it.

One project page, top to bottom

Seven sections of a project page in order. Result line: what it does and the measured number. Photo: the board, the bench, or the scope screen. Design: block diagram and the choices you made. Hardware: schematic and layout as images, and the part list. Software: what the code does, with a link to the repo. Results: scope captures, logs, and a table of numbers. What broke: the bug, how you found it, and what you changed.

One page per project. The order follows the student project sites in Cornell's ECE 4760 (opens in a new tab), which run from the design to the results and keep the code, schematics, and part lists in appendices.

Lead with the result line from your resume, then the photo. SlateGit, which sells portfolio sites, says to export the schematic and layout as images (opens in a new tab), because readers cannot open the design files, and to include a logic analyzer trace, a scope screenshot, or a terminal log as evidence that the thing works. End with what broke. The bug you found and fixed is the part an interviewer asks about. The section on your projects, line by line on the how to interview page lists the questions.

Put the code and the design files in one GitHub repository per project, with a README that repeats the result line. The section on showing it on GitHub on the software page covers the README and pinned repositories. The portfolio page links to the repository instead of duplicating it.

One project is the minimum, and three are enough. Pick the ones you can defend. The projects page covers how to choose them.

The pages that hold up are the ones that look like a lab report. Cornell's ECE 4760 final project sites (opens in a new tab) have been doing this since the early 2000s: an introduction with the result, the high-level design, the hardware and software in their own sections, the results with measurements, and appendices with the schematic, the code, and the part list. The students who wrote them were your age, and a hiring manager can read one in two minutes and know whether the project is real. Copy that shape before you copy anyone's visual design.

If your projects are software, a GitHub profile with pinned repositories and good READMEs does the job, and the section on showing it on GitHub on the software page covers it. A portfolio site earns its keep when the work is physical. A PCB, a power stage, a robot, a test rig, or an RF build has photos, scope captures, and layout images that a README shows badly and a page shows well. One student with no work experience kept a separate project portfolio that showed the projects in depth (opens in a new tab) and got an offer in February 2026 on the strength of it.

If you have one finished build and no photos of it, skip the site until you do. A thin portfolio reads worse than none.

These are portfolios by EECS students and new graduates, read from their public repositories in November 2026. The first four are linked and credited with their authors' names. Each entry lists what works and what does not. The gaps are as useful as the strengths.

  • Byron Bradley (opens in a new tab), a junior at Buffalo, has four projects on one page, each with a measured number and a paragraph on what is not done yet. One robot entry says the firmware compiles and that assembly, calibration, and trials are still ahead. That honesty is the strongest thing on the site.

    Pros

    • The Xbox 360 write-up walks from a power-fault code to a shorted MOSFET and the repair.
    • The maze and barcode entries label simulation and generated-image results as such, and say physical trials are still ahead.
    • Repair records, firmware, and experiment notes link out to public GitHub repositories.

    Cons

    • There are no schematics and no oscilloscope captures, even though the circuit-lab entry says gain, cutoff, and phase were measured on a scope.
    • All four projects sit on one long homepage, so a reviewer cannot open a single project and stay there.
  • Yasaman Kheradmand (opens in a new tab), at UBC, gives each of six projects its own page. A lighting controller page has PCB renders, a schematic PDF, a GitHub link, a bring-up video, and the input range and current it runs at.

    Pros

    • The lighting-controller page shows PCB renders, a schematic PDF, a bring-up video, and the input range and current the board runs at.
    • The robotic-piano page shows machined solenoid parts, wound coils, and several mechanical iterations.
    • Each project has its own page, so a reviewer can sit with one piece of work.

    Cons

    • An oscilloscope appears in the tool list and nowhere as a capture of a rail, a CAN edge, or an LED-drive waveform.
    • The homepage and several project pages repeat generic filler, including the line about going "from the circuit and PCB design all the way to programming, bring-up, testing," and long stacks of tool chips that do not add evidence.
    • The Smart Thermometer GitHub repository is empty, and the piano and smart-shoe pages have no source repository at all.
  • Panos Dimtsoudis (opens in a new tab), at Penn, opens with a predictions-against-results table on a chip design project and keeps a What broke note on another project, a power-reset problem and its fix. The repository README says an AI coding tool built the site itself and that every word about the engineering is the student's. That is the split this page recommends.

    Pros

    • The SRAM MAC page puts predicted numbers next to simulated results and publishes the misses, including runs that missed the prediction.
    • The Guitar Hero page states what went wrong: the board reset whenever the speaker drew current, and a 12 V pack with two 5 V regulators fixed it.

    Cons

    • No page shows an oscilloscope capture. The MAC waveforms are simulation and layout plots.
  • Zaid Saifan (opens in a new tab), at Western, has the cleanest structure of the five, with sections named The brief, On the board, Protection, Validation, and Next step. The repository holds the rules the student wrote for an AI coding tool, including one against inventing numbers.

    Pros

    • Every project page follows the same datasheet shape, so a reviewer always knows where to find the brief, the board, the protection, the results, and the next step.
    • The hospital-robot and RC-car pages include photos of the assembled hardware, and the RC-car page has a demo video.

    Cons

    • The home page leans on decorative effects (animated traces, 3D card tilt, magnetic buttons, a typed role line) that do not help a reviewer judge the engineering.
    • The golf-cart Validation section gives a current range as a design target with no measured current beside it.
    • The function-generator page says the outputs were captured on an oscilloscope, but the only waveforms on the page are an SVG drawing, with no scope screenshot.
  • The Cornell ECE 4760 archive (opens in a new tab) holds a semester of these pages at a time, 45 in fall 2025 alone. One of them (opens in a new tab) runs a Julia set on eight RP2040s over a custom multi-slave SPI bus and spends its Program Design section on the bug: the slave kept driving MISO low when idle, which jammed the bus until the pin was switched to a null function. That is the paragraph an interviewer reads twice.

    Pros

    • The Program Design section explains a real bus bug in enough detail that a reader can see the failure, the SDK limitation, and the pin-function fix.
    • The report includes a system diagram and a demo video.
    • The archive publishes a full semester of project sites at a time, so a reader can compare how different students write up similar work.

    Cons

    • The report title and opening overview stack buzzwords ("leveraging", "tightly integrated system", "push interactive graphics performance") before the evidence.
    • The write-up never shows a scope or logic-analyzer capture of the stuck MISO line, even though that is the central hardware bug.

Across the five, every site has photos and headline numbers, three link the code for each project, two show a schematic, three say what broke or what is unfinished, and none shows a scope capture. If you build one, the scope capture and the What broke section are where you pull ahead.

What five student portfolios show

A tally of six items across five student portfolio sites. Photos of the build: five of five. A headline number per project: five of five. Code linked per project: three of five. A schematic: two of five. A what-broke or limitations section: three of five. A scope capture: zero of five.

Read from the public repositories of the five sites described in the text, in November 2026. The scope capture and the what-broke section are where a new portfolio pulls ahead.

Every host below is free for a static site of a few pages and compressed images.

Plain HTML is fine. If you want a generator, Astro or Hugo builds the pages from Markdown. Do not spend a weekend on the design. Spend it on the project pages.

This is the one place in the job search where an AI tool can do most of the work. The site is a container. The project pages are yours, and the tool cannot write them, because it has never seen your board. Give Claude, ChatGPT, or Cursor the list of your projects, the result line for each, and your photos, and ask for a static site with one page per project in the order in the project page figure on this page. Ask for plain HTML or a small Astro project, no framework you cannot explain, and tell it to leave every number as a bracket you fill in. Then write the Design, Results, and What broke sections yourself, from your notebook. The tool saves you the day of layout and leaves you the hour of writing that matters. The AI use page has where a tool helps in the rest of the search and where it costs you.

A recruiter's search finds the words in your profile, so the profile is where your resume lines get found. BYU's Design Review says recruiters search LinkedIn for specific skills such as MATLAB or CAD, and a profile without those words may not show up (opens in a new tab). Three rules:

  1. Write a headline with the job you want and one specific, such as "EE student, embedded firmware and test automation, graduating 2027", not "Student at University".
  2. Put the same project bullets in Projects, with the measured number and a link to the portfolio page. Georgia Tech's College of Computing says to use industry keywords in the profile and a professional photo (opens in a new tab).
  3. Turn on Open to Work for recruiters only while you search. LinkedIn says that setting shows your status to people using LinkedIn Recruiter, and that it tries to hide it from recruiters at your current employer but cannot promise complete privacy (opens in a new tab).

Your school's career center has a LinkedIn guide. Berkeley's (opens in a new tab) and MIT's (opens in a new tab) are public. Use LinkedIn for people, too. The LinkedIn section on the networking page covers the alumni tab.

Post about your projects while you build them, and again when they are done. A photo of the board on the bench, a scope capture with one sentence on what it shows, a short note on the bug that ate your weekend. A recruiter who searches for your tools then finds a profile with proof on it instead of a bare headline. Keep each post to the fact and the picture. Nobody needs the lesson at the end.

Before each application season, open every link on the resume, the portfolio, and the profile. Fix or remove each dead one. Update the result line when a project moves. If a project is dead and you cannot explain it line by line, take the page down.

Content by eeprep contributors (opens in a new tab), licensed CC BY 4.0 (opens in a new tab). Code licensed MIT (opens in a new tab). Source is in the eeprep (opens in a new tab), resume-generator (opens in a new tab), and company-lists (opens in a new tab) repositories.