Arjun had been a support engineer for three years when he decided he wanted to move into DevOps. He studied containers in the evenings, followed along with tutorials and kept a folder of half-built projects on his laptop. Whenever a recruiter asked for a portfolio he said he was still tidying it up. A year later the folder had grown and nothing had changed in his career. What finally broke the pattern was a bit of advice from a senior engineer: your portfolio does not have to be good yet, it has to be visible. This is the story of how Arjun put a rough first version of his professional presence online, and what it did for his skills and his career.
The trap of the hidden portfolio
Many people moving into DevOps fall into the same trap. They treat a portfolio as a final exam: it must show mastery of everything, with clean architecture and a flawless record. Because that standard cannot be met, nothing is ever published. Meanwhile the people who get interviews are often not the most skilled but the most findable. A hiring manager can only evaluate what they can see. A modest page with one working project is more useful to them than the most impressive project nobody has ever heard of.
Arjun’s first version: one project, one page
He picked a small container project he had already built: a simple web service packaged as an image and run locally. He wrote a short page describing what it did, how to run it and what he would improve next. He did not hide the rough edges. The README admitted that the image was larger than it should be and that he had not yet added any automated tests. That honesty, which he feared would count against him, turned out to attract the most useful responses.
- One project rather than a gallery.
- A short explanation of the problem and what he built.
- A visible “next steps” list showing he knew where the work was thin.
- A way to contact him via his professional profile.
What feedback taught him about skills
Within a week, a stranger commented that his image included build tools that did not need to be present at runtime. Another suggested pinning dependency versions. A third pointed out that his instructions assumed a particular operating system. All three were useful and all three were things he would not have found by himself. Reading the commentary on frequent slip-ups newcomers make when working with Docker after publishing, he recognised two of his own habits in the list and felt grateful to have found them in public rather than in a job interview.
He treated each comment as a free review. Over the next three weekends he trimmed the image, added a simple automated build and rewrote the README. The next version was demonstrably better than the first, and because the first was still visible in the history, anyone could see the improvement. That visible progress was itself a signal. It showed that he could take criticism, act on it and keep going.
Moving from a local project to something that ships
The second step was making the project run through an automated path to a real environment. Arjun read about how containers fit into automated build-and-release pipelines and applied the simplest version of it: every change to his repository built the image and published it. It was a modest pipeline, but it let him say in an interview, truthfully, that he had set up and maintained one.
Later, when he wanted to tighten his setup for something closer to a production standard, he used a guide to sensible container habits across development and production as a checklist, picking off one item at a time. He did not try to apply all of them at once; he applied the next most valuable one each week.
Turning the project into a career story
The project was the proof; the story around it was what made it matter. In interviews, Arjun described the arc rather than the product: he had published early, received specific feedback, changed what he did and shipped a better version. Interviewers noticed that he could talk about trade-offs, mistakes and decisions in a way that people who have only watched tutorials cannot. One interviewer later told him it was the first time a candidate had volunteered what was wrong with their own project before being asked.
Where he wrote it up
As the project grew, Arjun wanted a place to explain his decisions at more length than a README allows. He started a blog on a publishing site that describes itself as free and gives its writers each an address under their own chosen name, published a first, plainly written post about the image-size problem, and kept revising it as people replied. The post was rough at first. By the third revision it had become a reference that recruiters actually mentioned.
It is worth saying that not every response was kind. One commenter dismissed the whole project as a toy. Arjun replied politely that it was a first version and asked what a more realistic scope would look like, and the exchange turned into a useful conversation. He learned that the quality of a response often says more about the person giving it than about the work, and that a calm question usually turns a sneer into advice. That small lesson in tone is itself a workplace skill, and nobody teaches it in a tutorial.
Practical steps if you want to follow his path
- Choose one project that already works, however small.
- Write a short, honest description including what is not good yet.
- Publish it this week, not next quarter.
- Ask two or three people to review it and say what to change.
- Improve one thing at a time, leaving the history visible.
- Tell the story of what you changed in your profile and in interviews.
What to leave out
Early does not mean careless. Keep employer code, internal hostnames, credentials and customer data out of anything public. Use sample data and your own accounts. Check your repository for secrets before publishing, because a leaked key is far worse than a rough README. With those basics covered, a visible, imperfect project is a safe and effective way to start building a name.
Where Arjun is now
A year on, Arjun works as a junior platform engineer, and his first project still sits on his profile, with its awkward early commits intact. He keeps it deliberately. It reminds him that his career moved not when his folder was finally polished, but on the day he decided that visible and imperfect was better than hidden and perfect.
