Ask HN: How do I improve my answer to “Tell me about a project you worked on” | Hacker News Reader

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

14 pointswufufufu34 comments

I'm not the best engineer, but if my engineering skill is p50, my memory and ability to talk about technical things is probably p10. I strongly favor asynchronous communication like email because it requires less active comprehension demand.

Is there anyone else suffering from this? What do you do to get better at this in general? Or within the context of engineering interviews?

I will say that I think I have memory issues and auditory processing issues that aren't debilitating or that noticeable until they're exposed by a conversation like this. Is my only choice to yeet Adderall and "memorize my lines"?

View on HN

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.

What are changeset comments? Like the git log?

Yes

> 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.

i’m always surprised the first thing people think is that other people are lying, and than if they cannot answer a question right on the spot they must be lying.

there must be some name for this in the domain of human behaviour or psychology.

people are not aware of the fact that if they go into an interview with that assumption there is a probability that they will think somebody is lying when they are not. this is a real problem when hiring people.

> i’m always surprised the first thing people think is that other people are lying, and than if they cannot answer a question right on the spot they must be lying

Where did anyone suggest this is what was happening?

> Ultimately the point of the question is A.) To tell if you're lying about your experience

You’re the one who suggested the idea, that the question is a way to tell if a candidate is lying about their experience.

Right, among other things and not “on the spot”. And I would argue that being unable to communicate about your experience is, to an interviewer, pretty similar to lying as they’re just a candidate making unverifiable claims.

Many people lie about their experience. Usually it’s glaringly obvious.

your answer makes it clear that you must not have built anything yourself of substantial size or complexity. if you worked on something for 10-15 years chances are you cannot answer some random specific question about that project because you haven’t worked on that particular part of the code base recently. so that does not mean you are lying about having built the thing.

my point is that assuming everyone is lying, biases you to the extent you want the outcome to be that the person is lying such that you can pat yourself on the back for a good job done rather than coming to the awkward conclusion you were wrong. and that is a real problem in interviewing because it means you discard top candidates.

> your answer makes it clear that you must not have built anything yourself of substantial size or complexity.

lol

> if you worked on something for 10-15 years chances are you cannot answer some random specific question

Again, the "random specific question" we're discussing is "Tell me about a project you worked on." So, again, if you can't answer "Tell me about a project you worked on", if you're claiming to have worked on that project for 10-15 years...I suspect there's something larger at play than just an inability to communicate about one's experience.

> so that does not mean you are lying about having built the thing.

I can and do routinely answer these types of questions about my work without issue. So nope.

> my point is that assuming everyone is lying,

Is verifying that someone isn't lying the same as assuming they are? (Hint: no).

> and that is a real problem in interviewing because it means you discard top candidates.

I would guess fewer than .1% of "top candidates" fail interviews at the "Tell me about a project you worked on" stage.

"Tell me about a project you worked on." is not a specific question

"why did you choose to order the members of this struct in your C code the way you did" is one.

> "Tell me about a project you worked on." is not a specific question

Exactly. That's the point.

> "why did you choose to order the members of this struct in your C code the way you did" is one.

Neat!

I'll leave this chain now. This does not seem productive.

Good. Take this as an opportunity to treat people you don’t know more fairly and don’t assume everyone is a liar.

Lol

People think that other people are lying, because .. they extremely often do. Do you know how many people apply for engineering jobs and can't solve fizzbuzz? What's the alternative? Just trust anything people say and blindly give people any job they apply for because they say they have the qualifications?

The specific question helps settle the lying issue. If somebody claims to have experience, they should be able to produce an example of said experience. It's both an immediate test of their experience as well as at the same time providing lots of additional data, through their story, about how good of an engineer they might be.

Even if it's a person who has horrible communication skills, a decent interviewer can ask follow up questions to probe into the story's details that the poor communications skills left out.

“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.

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.

This is the approach to take. Getting better at conversations, impromptu ones in a low risk environment is going to help. Go to meetups or the like and talk to others about hobbies you have an interest in. Maybe its board games, go to a board game shop and chat with people. There are clubs that do this - Toastmasters I believe is the name of one from some time ago, although I haven't heard them mentioned post-pandemic.

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. Writing in a journal (and writing coherently on HN) seems to help.

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.

Another approach that can work is to give your memory a bit of time to adapt. For instance, if you're asked to share a story from the past and you don't have one prepared and can't recall anything, suggest starting by discussing your past in general. For example, list the projects you've worked on and briefly describe them. You will feel how, during this process, the ability to recall events returns.

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?

personally it's hard when the stuff I do doesn't seem that cool to me. What for others looks like "cool Lego set build" for me might be "I arranged blocks in expected manner" and my mind wouldn't even consider that as a possible answer.

Yes, because sometimes you switch between so many different projects that you forget the importance of them. You normalize yourself to the momentum of the work, and if it's barely more proficient than someone in the same field, it barely registers.

Sometimes it really is hard to see the mountain you've carved, when your neighbour has a carved a similar one next to you.

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.

How else is someone supposed to learn about your work experience, other than directly asking about it? How much research are they supposed to do ahead of time? Not everyone's code is publicly available on GitHub, and no sane interviewer has time to sit around reading every single line of code that each of their candidates has written. Summarizing each of your major professional projects of your career in a few minutes is really not a whole lot to ask.

I really don't get this extreme aversion of software engineers to answering any sort of question in an interview that requires a marginal amount of thinking. This attitude comes off as extremely disingenuous, and at the very least indicates that they have something to hide about their experience. If they took tests in school the same way they answer interview questions, they would have flunked out of first semester.

"Tell me about a project you worked on..."

That's not asking directly. It's vague. It's ambiguous. It's lazy. It's a cover for not having taken the time to prepare for the meeting (read: interview).

On the other hand, "I see Project X on your CV. Sounds interesting. Tell me more about that...." Is a legit question.

And no one expects every line of code to be looked at. That said, my CV has a section with links to repos. And yet I still get, "Can you send some links to code samples?"

Engineers with an aversion to questions? How about engineers who are tired of showing up to interviews and the hiring person/peoples are unprepared? The questions are a tell, a signal. And too often it's a tell with a smell. The aversion is to that smell.

> That's not asking directly. It's vague. It's ambiguous. It's lazy. It's a cover for not having taken the time to prepare for the meeting (read: interview).

I beg to differ. I think the more ambiguous the question to start with, the wider the field of possible followups. Perhaps project Y is something that the candidate is more excited about than project X, and maybe had a bigger role in.

I believe that, in a friendly setting, one can pick up a lot of information about the candidate's ability to work with ambiguity, from the clarity with which they have organized their thoughts, the concision with which they have presented it, their humility about their contribution, about the things that excited them. Or lack thereof. The interviewer need not be familiar with the details of that project to pick up on this.

> "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.

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.

This is probably going to sound weird, but I was reading an old post on your website, and wanted to say thanks because it helped me out a lot. It was the post about pitch detection. Thanks, it helped a bunch with what I was trying to do.

Not weird at all — really glad it helped!

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

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.

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?

Reply on news.ycombinator.com