My First Project Demo

Since I graduated Flatiron School 2 months ago, I’ve been job searching and networking. I got lucky recently and was asked to interview for a Software Engineering Apprenticeship role with a lovely company. The interview process consisted of a phone screening/information session, a code assessment, a conversation with a couple of the engineers there and a final round interview. The final round interview was probably the most extensive with me having some cross-team interviews, meeting most of their staff and having to do a project demo in front of their engineering team. This is the experience I want to share with you all.

The company provided me with a lot of information about what I should expect and what they expected from my demo. I was to pick one project from my Github profile that really showcased my full-stack coding skills. I chose a project that I named Calorie Bookie which lets a user log their daily calorie intake on a 30 day basis and they can bet on whether or not they reach that goal.

The demo would start off with me showing the app and an overview of the codebase and technologies used. I used a Ruby on Rails backend along with React for the frontend. A third-party API was used to collect food data and PostgreSQL was used for the database. The first part of the demo wasn’t so hard and I always find it fun to show off the app itself.

I was asked to pick one feature of the project and go into detail showing methods and functions used for the implementation. This part was where I got the most out of the whole experience and learned so much about demoing a project. Walking someone through your code and showing them how certain pieces fit together was so new to me. I had gotten used to just coding and showing the final product with very little questions asked about how I got there. So I really had to plan out how I would explain my methods and functions so that they were clear and I’d come off as knowledgeable about my own code base.

The feature I picked to demo was the bet feature. This allows the user to place a bet against the app/calorie bookie. If they reach their 30 day goal, they get to keep their money. If they lose, the calorie bookie keeps their money. This particular company I interviewed with was kind enough to send me an email with some of the questions they’d like answered during this demo, so it was much easier to prepare. I took that email and turned it into an outline and then wrote out the answers. Below are some of the questions asked:

1. What is the main purpose of this feature?
2. What problems does it solve, or capabilities would it add for your users?
3. In broad terms, could you describe your technical approach to implementation?

They also asked me to do a walkthrough of the code I wrote to implement this feature. This was where I had to be very thoughtful. I decided to do a mock walkthrough of this feature with a couple of my former classmates. It was then that I realized how hard the walkthrough portion could be without preparation. My project has a backend and a frontend. So this means the frontend communicates with the backend and the backend sends information to the frontend. Because of this, methods and functions sometimes run simultaneously or one after the other. I saw how much coordination I’d need to have while explaining these steps. This also opened my eyes of how important it is to know where I wrote certain functions/methods and to remember exactly what they do. I’ve heard famous singers say how they don’t remember the lyrics to their own songs and I was always so puzzled by this becasue most of the time, they are the ones who wrote them! Doing the walkthrough of my code base was very much like that. I had to refresh my mind on what every little part did and how it was used along with another part. So I wrote myself a “roadmap” of sorts. Below you will see a screenshot of it:

Please forgive any typos or sentences that might not make any sense, this was literally for my own use during my interview. But I wanted to show how I prepared for this demo. I color coded things by an action step(red) methods/functions(blue), models(bold black) and components(purple). This “roadmap” helped me to know exactly where specific code was and it helped me to have a flow during my demo. I was very nervous and didn’t want to at any time lose my way and forget what the next step was. I’ve added a few code snippets from the demo below as well.

Overall, this was a great experience. I really wanted to give some insight to a project demo for new devs who havn’t really had one yet. I thought it would be helpful for someone who is preparing for one themselves. A few things I learned from this are:

1. Make sure you have a very good understaing of the code you write and why or what it actually does.
2. How important it is to be able to explain your code clearly using the proper technical terms.
3. How important it is to practice project demos with peers and by yourself. Having a script or notes are super helpful and getting feedback.
4. Don’t let your nerves get the best of you. I had this demo in front of a bunch of strangers who have been coding way longer than I have. I know I could have probably done better with my delivery, but having gone through this has really shown me what to expect the next time. Confidence is key!

I haven’t heard back from the company about their decision yet, but fingers crossed I get it🤞🏾! If I don’t, I’m still so happy I went through this process so that I know hat to expect in the future and to get better at it.