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"?
- 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 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.
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.
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.
Where did anyone suggest this is what was happening?
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.
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.
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.
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?
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'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.
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.
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.
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.
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.
When it comes time to interview, that becomes your updated resume and your bank of experience to talk about.
- 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?
