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?

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.

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

4 Answers
4

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.

+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.
–
SpoikeMar 3 '12 at 0:08

Thank you very much everyone. I am glad that I posted this question and the information is very helpful.
–
JyinaMar 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 MMar 3 '12 at 2:17

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.

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.