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, no registration required.

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|improve this question

migrated from stackoverflow.com Mar 2 '12 at 23:38

This question came from our site for professional and enthusiast programmers.

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|improve this answer
+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|improve this answer
+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|improve this answer

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|improve this answer
+1 for noting development and testing methodologies. I think most people forget to mention those. –  rally25rs Mar 3 '12 at 1:31

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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