How do I improve my answer to “Tell me about a project you worked on”

Here is what I did (I have no idea if this is helpful):

- Pulled all my changeset comments within the range I care about.

- Put them into Excel and strip dupes, shorts, and general cleanup (e.g. remove anything with "fix" + "bug"/"exception"/"crash" in it).

- Put the remainder into ChatGPT and ask it to make me a bullet list of my projects.

- Expand and clean up the resulting bullet list by hand.

Then take that to interviews with me, and when someone asks me I unapologetically change to that page and skim it as I talk. I don't pretend I don't come prepared or even over prepared, I want them to know I am ready for their questions.

I don't understand where people got the impression you need to memorize this stuff; it is a professional business meeting, and you wouldn't turn up to any other meeting without notes or references to what you're going to talk about.

I field that question but I don't like it. In a word, it's lazy. The interviewers has my CV, why not say, "Tell me about Proj X you mentioned..."

I've had two interviews in the last week and I'm not sure why they bothered. Both came off as disengaged. Both probably didn't prep for the conversion. Both asked that question.

Yawn.

Practice. Look for opportunities to give talks and make a talk complete w/ slides about something you did. Give the same talk or almost the same talk at a few different places. Write a blog post about it.

> Is my only choice to yeet Adderall and "memorize my lines"?

I really cannot fathom why you jumped to this. Is "practice and get better" that unreasonable? You really only need a handful of things to talk about if the question is as open ended as "Tell us about a project you worked on". The question is akin to having a normal conversation with another dev about something you built.

Ultimately the point of the question is A.) To tell if you're lying about your experience, B.) To tell if you were conscious of things like edge cases, alternative strategies, failure conditions and scale, C.) If you can communicate effectively. I wouldn't overthink it. It doesn't have to be Google 2.0 to be the project you talk about, just something that you had a significant hand in making and were aware of any tradeoffs available.

> "memorize my lines"?

Be humble. Be honest. Be authentic. Practice by imagining the situation, by all means, but be yourself. Exaggerating your ability or outright lying will require increased cognitive load. And the truth will out, eventually.

If you struggled, say so, and talk about how you overcame your difficulties. Pretty much every project I have ever worked on included some new technology that was unfamiliar. So I had to do various things to learn that new tech. The fact that I did not know some specific technology was not a downside; the fact that I was able to learn it, or more generally, the fact that I was able to overcome a problem was an upside.

How are you not able to answer this even in a minimal way? You have memory issues and the first thing you go to is "memorize my lines?"

Even a child should be able to answer "what cool shit have you done" in a barely minimum way.

"What cool shit did you work on this week"

"I built this really cool lego set from blocks and customized it with stuff"

Is this that hard?

Track what you work on as it happens. Every time you think, "Wow, I just did a good job," write it down. Keep track of those wins.

When it comes time to interview, that becomes your updated resume and your bank of experience to talk about.

Write down your answer to that question. If the project was particularly complex, or you were on it for a long time, the answer might be several paragraphs long. Read it out loud, and time how long it takes. The goal is to come up with two versions - one that is 90 seconds long ("elevator pitch"), and another that is 2-3 minutes long. That way you have two options depending on how much time you have to answer the question.

Anticipate questions a listener might have about your project. Write down your answers. Read them out loud. Try to prune those answers to 30-60 seconds.

I can relate a little bit to your last point. Between age and the effect that Covid has had on my socialization, I seem to struggle a bit more to process verbal information. Writing in a journal (and writing coherently on HN) seems to help.

“Tell me about a project you worked on” is a great question for the person being interviewed, because you can and should have a strong prepared answer.

It's basic story telling. You have the opportunity to tell an interesting story about something you did to the people interviewing you.

Chances are the interviewers are devs like you and don't want to be there any more than you do.

So you get to make their jobs easier by telling them a story that has lots of opportunities for them to ask you questions that you have good answers to.

- A few months ago I worked on a project that does ...

- It was a complicated project because of ...

- I was the lead X on the project, responsible for ...

- This is what I did ...

- These were the problems we encountered and this is how I approached those problems ...

Every developer should have a couple of good stories just like this. The entire interview can hang off a good story and can be repurposed to fit different variations of that question.

And best of all, it's YOUR story, which allows you to control the conversation.

There are specific frameworks to help you prepare. Google STAR it stands for Situation Task Action Result. Formulate a bullet point list under each and then turn that into a story

If the interview is structured in a way that overloads your short-term memory, which is often the case, you'll have problems remembering things from a long time ago. Ask someone questions about recent events for a few minutes, and they won't even be able to remember not only what they worked on in projects many years ago but also their grandfather's name. Everyone has this problem; it's just how memory works, and poorly structured interviews trigger this effect. A workaround is to prepare beforehand and keep a list of things to talk about nearby.

For many reasons, I recommend creating a brag doc like Julia Evans mentions here: https://jvns.ca/blog/brag-documents/

It can help you keep track of what you've worked on. Got an interview coming up? Take a few minutes to review your brag doc and look at the largest/most complex/coolest sounding projects to refresh your memory. Combine that with the practice that other commenters have mentioned.

Some tips:

- talk about things where you took initiative

- how did you identify the problem?

- how did you get support from your team/management?

- how did the project go?

- what was the outcome?

- what went well, and what would you do differently knowing what you know now?