I went to an interview last week for a junior programmer and mentioned that I ha
ID: 642698 • Letter: I
Question
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:
Is the above idea something to work on? (top > bottom)
Should I concentrate more on algorithms?
Should I try to build a UML diagram or some other visual representation of the project?
Any other ideas?
Explanation / Answer
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