Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

I am working as a .Net developer for a couple of years. I don't have experience in presenting projects but I have an interview and I will be expected to present the projects that I worked on in the past.

How much/what kind of technical details should be covered? What other aspects of a project should be covered?

share

migration rejected from stackoverflow.com Jun 26 at 16:27

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as off-topic by Snowman, MichaelT, durron597, ratchet freak, Dan Pichelman Jun 26 at 16:27

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions seeking career or education advice are off topic on Programmers. They are only meaningful to the asker and do not generate lasting value for the broader programming community. Furthermore, in most cases, any answer is going to be a subjective opinion that may not take into account all the nuances of a (your) particular circumstance." – Snowman, MichaelT, durron597, ratchet freak
If this question can be reworded to fit the rules in the help center, please edit the question.

4 Answers 4

up vote 13 down vote accepted

The most important thing: What you did on the project.

How you contributed is much more important than what the project was (demonstrate your value to the team).

You can also talk about what techniques, technologies, and principals were used on the project, and why they were beneficial (demonstrate your understanding of the technologies involved). For example, "We used an MVVM pattern for the client, which helped us isolate areas of the application, and keep the parts testable."


I have done a lot of interviews the last couple years, and I always ask candidates in a fairly general sense (intentionally), "tell me about your last couple projects, and what technologies you used" and usually they tell me about what the application did. This just makes me think that the company had an architecture in place and some pre-selected technologies, and they adapted to it. I tend to find that only a few actually tell me what they contributed to the project, or why certain choices were made or why certain technologies were used. These tend to be the candidates that are more interesting and passionate about the profession and the software they helped create.

share
    
+1 I agree that it is very important talk about your own contributions to your previous projects during the interview. If you don't then you'll risk to come off as a charlatan with no real value to bring to your new employer. –  Spoike Mar 3 '12 at 0:08
    
Thank you very much everyone. I am glad that I posted this question and the information is very helpful. –  Jyina Mar 3 '12 at 1:04
    
I also agree with this. I interview .NET developer candidates all the time and so many say things like "we built this" or "we used that technology". Not only do I not care, it makes it sound like you used your teammates to cover the fact that you don't actually do any work. Tell me all about what the project would've been without you. Tell me what you love doing and what value it adds. –  Rex M Mar 3 '12 at 2:17
  • Give a high-level overview.

  • Higbhlight your contributions as others have said.

But most critically:

  • Tailor your presentation to both "who" you are presenting to - technical vs business analyst vs. CEO - and also to what they want to know. You'll know "what they want to know" from two main sources. First the job description. This can involve some reading between the lines but that's a whole seperate subject. Secondly the actual feedback you receive during the interview. Note which areas you are asked about and focus on how your experiecne relates to them.

In summary, there is no magic answer. The more effort you put into learning about the company, its products and mission and what the culture is, the better you'll be able to present yourself to them.

share
1  
+1 for tailoring the presentation to the audience –  jcmeloni Mar 3 '12 at 1:04
    
+1 Agreed, absolutely know your audience and really listen to them, don't just talk. –  Adam S Mar 3 '12 at 21:54

The couple of of interviews I've helped conduct, we were mostly interested in:

  1. Project architecture (Object relations, functional modules, communication paths, etc.)
  2. Third party technology involved (in particular, we appreciated the ability to recognize when a particular wheel had already been built, and then folding it into the code base)
  3. Any aspects of the project that were particularly challenging or interesting to solve.
share

How much/what kind of technical details should be covered? what other aspects of a project should be covered?

I'd look at this from a few angles:

First, make sure you give enough context on the project in terms of how many people worked on it, how long was the project, what kind of budget scope was there,e.g. was this a $10,000 project or a $10,000,000 project, and what technologies were involved to what scale.

Second, what roles did you fill on this project. Were you an analyst handling gathering the requirements? Did you design the solution? Did you help estimate the deadlines for the project? Did you write any code? Did you test code? Did you help with deploying the code?

Third, which practices were used. What methodology was used,e.g. Agile or Waterfall? Were there practices like Scrum, pair programming or any BDD, DDD or TDD done? This is the last part as once you have given the setting and roles done, this is what else was there to pass along.

share
    
+1 for noting development and testing methodologies. I think most people forget to mention those. –  rally25rs Mar 3 '12 at 1:31

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