I went to an interview last week for a junior programmer and mentioned that I have been working on a project with a buddy of mine. Tomorrow they would like to see this project in order to decide if they should hire me or not. So I was wondering:

  • What parts of a project are of interest to someone who has not seen the project before?
  • What could I show that would change their perspective of me as a programmer and what I know?

The project is in C# and have been a hobby project for 6 months now. Without going into to much details:

  • it's a networked program
  • it's server / client based where clients end up connecting to each others
  • there is synchronization of data between clients
  • we are using files to store information about the different clients, which is also being synchronized
  • the program in whole is divided into some different projects (some which go into .dll's)
  • the project will later handle multiple layers of displaying the data to the user (meaning cmd, a window etc..)

I have green lighted this with my buddy as well and it is ok to show. My idea was to show the shell (cmd) that we have which is working and the top layers of the hierarchy, the ones that the shell communicates directly with. These are three classes in particular, one that connects and communicates with the server, one that handles the synchronization and one that handles the objects that are being synchronized. I'll try to go into some details about how we store the objects and how this is communicated to the synchronizer class. Then discuss on a higher level of how we synchronize the data, ending with going into some detail about how this is done.
Basically, start from an abstract layer and go into detail where the magic happends.

But I wonder how this will be understandable for someone who has never seen our project before. How will this show that I am a better or worse programmer than my next? They are programmers so I guess they will understand the basics and be able to follow the functions and what the code do. But I know that I have trouble with understanding the overall picture of a project, much less in 1-2 hours. Also, I wouldn't know how to decide if it was a good programmer or bad unless I saw some bad code. So my question is:

  1. Is the above idea something to work on? (top > bottom)
  2. Should I concentrate more on algorithms?
  3. Should I try to build a UML diagram or some other visual representation of the project?

Any other ideas?

closed as primarily opinion-based by Ixrec, durron597, user40980, GlenH7, gnat May 31 '15 at 19:30

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.


Give a general description of the problem you're trying to solve and how you went about it. A diagram of the main pieces and how they interact will be helpful with this type of application. They're buying you and not the application. It may be something they have absolutely no use for, but want to see how well it is constructed.

Once you start showing them your code, they should have a lot of questions and start directing what they want to see. Be prepared to identify areas that have been coded well and those that may be a work in progress. They'll probably ask how long it took to write certain sections of code.

Hope your work looks as good or better than your buddy's ;)

  • Nice answer. the fact that they will ask questions directing me to parts of the program is a really good thought. And the code is maintained by us both, so it's all good :) Otherwise mine would look worse (he's been working as a prof. programmer for some years now). Everything is work in progress actually, but I have already mentioned this to them. We haven't even released an alpha – Default Dec 19 '10 at 11:50

I am a freelance developer and I think I lately have found the ideal way to "talk" to customers: BPMN.

Generally after the requirements gathering I model their whole business process and add my $0.02 with what I intend to implement. In a second session to clear up doubts I present the BPMN process (and subprocesses) and open with: "this is your business process, it is modeled with a specialized notation called Business Process Modelling Notation, it is like a flow-chart but here are only two symbols you must know, circles are events (stuff that happens instantly) and squares are tasks (stuff that takes time)".

And I totally have them there; then I start explaining them how I understood it and how it will reflect in the implementation, and what are the future possibilities, and then the magic happens: customers are totally engaged in a proactive discussion.

If you ask me why I'd tell you that this way you can show the client/employer that you actually understood the problem, and where you didn't, he/she will have an actual opportunity to know how to tell you why, where and what is missing.

Try http://www.bizagi.com/ as a BPMN editor, its free and the diagrams just look gorgeous. The tool actually explains you BPMN on the fly (mouse-over the pallette). Tip: make a general process and use "Reusable SubProcesses" in it, so that each reusable subprocess refers each other diagram you create. When you finish, export in HTML, it just looks awesome.

Remember, BPMN is meant to describe mainly business logic, not program logic (e.g. don't diagram "ifs" and "loops" if they are not relevant to the business logic), and this makes possible to show only the relevant parts of the problem and how your software solves it.

Give it a try, and good luck.

P.S.: Check the wikipedia page on BPMN.

  • BPMN was a very interesting idea! I will definitely take a look at that. Thanks! – Default Dec 19 '10 at 12:16

To be honest if you are applying for a programming position do not be at all worried about how 'technical' you get. If the interviewer does not understand to the same level or a higher level than you despite you knowing your project inside out, you should have their job!

"How will this show that I am a better or worse programmer than my next? "

Your app will speak for itself. If it's an illegible mess, providing the interviewer is NOT of the breed above, then it will appear as an illegible mess.

It might be beneficial to produce a brief UML diagram (and I mean brief). Up to now though this only covers application design. I imagine they are going to want to get dirty and see the actual code. For that reason have source code ready (print out the entire app if you have to or have it handy on a laptop).

  • My laptop died last week, so I guess I'll bring it on a usb floppy.. Not sure what "illegible mess" means.. All source code will take a long time to explain, so I guess I should focus on some parts. But what parts of a projects says anything about a programmer? Is it optimal algorithms? small functions? self-explaining function names? Thanks for your answer though! – Default Dec 19 '10 at 11:43
  • @Default: Well, aside from the overall design of the app, they're going to want to see best practices being used. Good coding standards and such. Readability being a part of that. Make sure you aren't doing anything the 'amateurish' way because that will show in your code. – Damien Roche Dec 19 '10 at 12:35

Not the answer you're looking for? Browse other questions tagged or ask your own question.