The title question addresses two questions really.

  1. What can a programmer show off in a "portfolio?" and
  2. Would a programmer need "GUI/Designers" whereas designers could get away without a "programmer?"

So to clarify the title question. When I mean programmer, I'm talking about languages such as Python, Go, Perl, where there is no "direct visual output" other than text. As opposed to an html coder (who could also be a programmer) whose results are often easily visualized. There are clearly two separate jobs here and languages, programmer vs designer/coder.

It's understood that someone who knows html can essentially build and create pages to visually demonstrate their skills, such as in a portfolio, or to share with friends, etc...

What would an experienced programmer "show off" in the similar sense? Obviously they can come up with a software or .exe where if you type something in, it spits something out. But would a programmer always need to team up with or have an understanding of html or some other graphic interaction in order to have a portfolio?

  • 7
    VTC - Neither of these questions are specific to the Workplace IMO - this may be appropriate on some of the coding SEs but I don't think it is appropriate for Workplace SE Apr 18, 2023 at 0:51
  • 6
    It's definitely off-topic on StackOverflow, SoftwareEngineering and CodeReview.
    – MSalters
    Apr 18, 2023 at 9:29
  • 1
    I would rate the skills of an HTML programmer primarily by the code they have written, by actually looking at the source code of the webpage. Not by looking at what a web browser made out of that HTML file. Apr 18, 2023 at 20:11

7 Answers 7


A "programmer" does not necessarily require a portfolio of works to get a job in the field. Possession of a degree and/or previous experience in the role is often used as a benchmark for hiring.

However, one of the best examples of a "portfolio" for a programmer would be a link to their GitHub page (or equivalent), which will ideally show a strong activity in the form of number of contributions over the previous year. Similarly, contributions to open-source projects (or publishing of personal projects on GitHub) can also be used to show programming skills.

  • 3
    Not all programs have a GUI. Not all programs have "pretty" GUIs. So, no, showing off programming skills doesn't involve UI design skills unless they're essential to that specific code. ... All of which is stuff you should know, if you have enough programming skills to be thinking in terms of a portfolio rather than simply a work history.
    – keshlam
    Apr 18, 2023 at 3:31
  • 1
    @Brandin: I may be wrong, but I think OP was talking about a "UI designer" as in a person who designs/sketches the UI, which can then be implemented by an arbitrary programmer (with or without a WYSIWYG tool for arranging UI components). Apr 18, 2023 at 21:56
  • 2
    @createu: 'Would a programmer be dependent on a visual/ui designer (in an example of web development, an html coder) to make a "product" available to the public?' - no, and I'd wager that a vast portion of actual commercially sold software that features a UI has never had any dedicated "UI designer" involved in the development process. Sometimes it shows, but sometimes "regular" programmers are also rather good at making good decisions when it comes to creating a UI. Apr 18, 2023 at 22:00
  • 3
    @Therac "Degrees for programmers is a rarity" I have never seen a programmer without a multi-year formal education. Most common are probably Bsc. and comparable qualifications. Did you mean a specific degree that is a rarity?
    – nvoigt
    Apr 19, 2023 at 6:02
  • 2
    @createu I think you need to add the words "front end developer" and "back-end developer" to your vocabulary. A "front end developer" works with HTML/CSS/JS -- they're as much a "programmer" as someone working in Java/PHP/C+ etc.
    – academiaTA
    Apr 20, 2023 at 7:10

I think the lines you draw between coding and design are not actually where they are in reality.

A programmer is someone who can make the computer do things. Including showing a graphical user interface. A person who can only write scripts without a graphical user interface is not a proper programmer and neither is a person who can only create static HTML pages. Programming is craftsmanship, not art. A report for accounting can be correct or buggy, but never "not my style". Even with graphics, it is the programmers job, to fit it to the style the customer wants.

A designer designs things. Maybe even human-computer interfaces. While it involves craftsmanship, it is partially art. You can produce an amazing design, where everyone agrees that it is amazing work, and your customer can still say "I don't like it" and be right about that.

That is why a designer has a portfolio. Because it is art and no matter how good the designer is, it might not be what the customer wants.

And that is why programmers do not need a portfolio. Or need a portfolio as much as an accountant, plumber or car mechanic. There is no art or personal expression involved.

  • I think that line "Or need a portfolio as much as an accountant, plumber or car mechanic." is the real answer - you either show your past work or have customer references... same as listed professions. Apr 18, 2023 at 20:36
1. What can a programmer show off in a "portfolio?" and

TL;DR - Developers that have worked on open source projects can show their contributions, but that is not really sufficient to make a hiring decision.

Web Developers/Designers

Often a web developer/designers final product is publicly visible - they can simply point to a public website and say - I created that.

It is probably the case that early/unreleased designs created by a web developer/designer are "work for hire", hence still the property of the company that paid for them - hence a web designer may wish to consult a lawyer before sharing them with potential new clients.

Backend Developers

Except when working on open source projects, it is rare that backend developers get an opportunity to publicly display their previous work.

Note: I am defining "work" to be the source code - one could theoretically look at the final product of another developer, to try to assess their skill but it is generally considered more informative to look at the source code.

Open Source Contributors

You could restrict your hiring (not a lawyer/please check legality) to only developers that have a public open source profile.

  • Some people argue that it's a positive because they see OSS contributions as a kind of "extra effort".
  • Others argue restricting hiring to only OSS is a negative, as its not "extra effort" and you have now reduced the pool of potential candidates.

I don't want to get into that debate - you will have to make up your own mind if you see it as positive or a negative.

Pre-screening Coding Tests

A number of companies offer services to "screen" developers using coding tests. Often you can choose the number of tests and level of difficultly.

Using these test will screen out some percentage of the applicants. The more and harder tests you give the greater the percentage of applicants you will screen out.

The problem is not all good candidates (I assume you don't care about bad ones) will be willing to complete your screening test - they may be applying to multiple companies and unwilling to spend time on your process.

It is also not clear if increasing the difficultly results in more hires - you could make the process incredibly difficult and then only get candidates who are out of your budget for the position.

Phone/Zoom Screens

Almost all applicants will expect to do a phone screen at some point. Hence you should try to create a phone screen that obtains the maximum amount of information in the minimum amount of time (typically 1 hour).

A starting point might be:

  • (30 mins) Can they code - even the most basic coding test will eliminate a percentage of applicants - also note the time it takes to complete a basic test.
  • (15 mins) Some questions to probe the breath of their knowledge.
  • (15 mins) Some kind of design question.

I would suggest setting the difficultly of the phone screen slightly lower than you would accept for the position - the point of the phone screen is not to make a hiring decision. It is just to prevent very weak candidates from wasting your companies time during the rest of the process.


Coding tests can be use to screen out weak candidates (with some risk of losing potential hires).

People with solid open source profiles can probably skip some early stages in your hiring process (Coding tests / phone screens).

However to hire solid candidates you are likely to need to dedicate time from other backend engineers to do interviews - I am not aware of any way to eliminate that.

  1. Would a programmer need "GUI/Designers" whereas designers could get away without a "programmer?"

TL;dr - You need to hire a set of employees that cover all the skills that your company needs - in this case both.

A term that gets thrown around is "Full Stack Developer". Which roles that encompasses is somewhat subjective, but typically includes some combination of:

  • UI Designer.
  • UI Developer
  • Backend Developer.
  • Operations / IT / Cloud computing / Deployment.
  • Database Administrator (maybe)

If you had 5 employees would you be better off with 5 generalists or 5 specialist (one for each role)?

Generally your company will have a deeper depth of knowledge with 5 specialist, but you may find it more difficult to balance the workload (for example too much work for the UI Developer and the DBA sitting idle).

Note: There are people who are experts in all areas, but it's likely that they will command a much higher salary for that skill set - so you need to determine if you really need that.


What is a "programmers" product akin to an "html" coders web page?

The title question addresses two questions really.

  1. What can a programmer show off in a "portfolio?" and
  2. Would a programmer need "GUI/Designers" whereas designers could get away without a "programmer?"

Not all people who write code have a portfolio. I have never had one. I have never looked at a portfolio of somebody I was interviewing.

For a huge number of programmers there is no portfolio, and they will never had one. There are a a number of reasons for this.

  • They are part of a team. For a large program there can be dozens or hundreds or thousands of developers. The code they are most proud of can't be demonstrated in a vacuum.
  • They don't own the code. Their employer does. Or the customer of their employer does. They would never get permission to post it in a portfolio. They could be fired or go to jail if they post their code.

It doesn't reapply depend on the type of programmer they are. These things are true for many "coders". They can be UX developers, html/css developers, database programmers, data analysis tool developers, scientific programs, scripters, bug fixers...

All these people get jobs. What they have is experience. They can discuss why and how, they just can't point to a piece of code, or even a screen capture.



As a programmer, your product is code. The last time I was applying for a job, I brought a code sample on USB -- an application I wrote myself in my free time. (You could do it on GitHub instead. That might be easier.) My thinking was I wanted to be prepared to present some code I had written and discuss it.

Taking code from a former job is almost certainly questionable at best, but having some program of your own that you wrote -- regardless of what it does -- at least helps show knowledge and gives you a talking point.

You shouldn't really need to run it. It doesn't matter if it's an Android app, a Linux utility, or whatever. I would just expect to talk about the architecture of the program, perhaps some design decisions ("here I used a linked list rather than a hashmap because blah blah, and here you see I'm using mutexes to protect this structure from the multithreading I do here and here...") and do kind of a code review during the interview process.

Potentially you could have other documents, as well. You might flowchart your program, show unit tests, or PDF the overall layout -- anything that shows your approach to coding and problem solving.

Anecdotally, I have never had to show code in an interview. They always had their own questions, or their own little "coding test", but I do think it's nice to come prepared, and making your own little utility or whatever from scratch at least gives you something to present if needed. Don't worry about your "sample program" being unique or marketable. You're just showing that you know coding and can talk about it.

(Web page designers may tend to want visual presentation because after all, that's a big part of their job: "presentation". If I'm hiring a back end developer, I'm okay if his color coordination and button placement is questionable, because I probably have someone else to work on that. But I need to know he can code. I'd be more interested in seeing a client-server model he did for fun than a web page he created.)


You can show source code of your own hobby projects.

Things I would consider when looking at it:

  • Is there a well-written README.md at the root of the project?
  • Clean code?
  • Code easy to understand?
  • Well-documented?
  • Tests? And for what?
  • Automated builds?

and more. It is relatively easy to see even from hobby projects how experienced you are and what you consider important.


The problem with programming is that it's very difficult to get an impression of the whole quality of code at a glance.

Code style

What is most apparent from looking at code usually are stylistic and formatting aspects which are subject to wide variation and are of only limited importance. Moreover, there are automatic tools which can format code, so those with the least skill or discipline would just put their code through a formatter to conceal the fact.


The next thing of importance is the naming scheme. But whilst all programmers agree that naming is important for working with code, exactly what role it performs and what makes a good naming scheme, is not well-articulated.

Programmers tend to sense the quality of naming schemes through ongoing work with them over some period of time, and they don't always get their own schemes right first time.

Moreover, unless the reader of code has a deep knowledge of both the subject of the code, and the context in which the code is used (i.e. without the judge being a programmer who writes code for that area of expertise usually, and is practically in the same business and already a colleague of the programmer), it's almost impossible to judge. So the idea of showing a portfolio, whether during a hiring process or otherwise, is typically pointless.

Staff integration

Competence of programmers in certain areas is also a double-edged sword for the employer, because it tends to imply that programmer has a sharp eye and strong intrinsic views about the importance of that area, and that can lead to disagreements even between expert peers, it can lead to clashes with other staff who set a very different standard, and it can lead to a resistance to working with code which the employer already possessed but is written at a much lower standard.

In other words, whenever an employer wants more than one programmer to work together, or wants more than one programmer to work on a code base, there become important questions of fitting those people together and considering them as a set rather than as individuals.

It's the same as if you put two novelists, skilled but strangers to each other, to work on a book - only a small number of compatible personalities would ever complete. Fission would be the norm. And one novel is rarely ever revisited by a second subsequent and independent author - the results would almost always be unmarketable.

What this implies to a hiring employer is that you're not just looking to maximise the quality of code, you're looking to judge how the capability of the person corresponds to what you already have (or had).

Given that programmers might sometimes preen a portfolio and spend disproportionate time on it, it probably gives little insight into the question of whether they might fit.

Business integration

The most important factor of code, by far, is whether it "works", and whether it fulfils the purposes for which the business commissioned the programmer to work.

The ability of a programmer to grasp these purposes and the full detailed workings of the business (which is often a function of wider business experience, of intelligence, and of skills in communication and research), and to write code that "works", is of primary importance.

For those looking at abstract code in a portfolio, or indeed looking at any code outside a business context (or just without the deepest management understanding of that context), none of this capability can be judged properly. It's impossible to understand whether a programmer is apt to understand business purposes, simply by looking at any code he writes.

The competence of the interviewer

Last but not least concerning professional portfolios, a great many hirers of programmers don't have the remotest skills in the areas where they might want to assess the candidate.

Provided with a portfolio of code, a good many hiring managers could not read it even in its own terms!

My remarks above suggest that the ability to read code wouldn't itself improve a hiring manager's ability to actually judge the programmer in an interviewing context, but an inability of hiring managers to read code suggests they typically have no contact at all with the same professional area of expertise as programmers.

Other occupations which use portfolios

Although there are creative occupations which use portfolios, I suspect these occupations are often considered to be producing more self-contained products.

Graphic design, for example, may be complicated, but it's primary function is to please a human viewer, often at first presentation.

One rarely has to have a deep and detailed understanding of a specific business operation to either produce a graphic, or to form some opinion about its quality.

What pleases the viewer in one business will often be the same as what pleases in another, which is scarcely true of programming (and if it was, a company would typically just buy existing software than hire a programmer).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .