Hacker News Reader

> > That said, I'm always surprised how many candidates cannot even point to one problem they worked on they found interesting or one solution that they're proud of.

> It could be that this technique favors people good at telling stories.

Or people who think they're impressive. I know I would've been able to point out many problems and solutions I found interesting and were impressed with when I was 15. Today, not so much. The more I know, the less impressed I am with myself, and more and more stuff just feels "routine" and nothing special.

It could be that I'm just not impressive. At all.

At this point in my career I'd have to say I agree. Many of my team are at the start of their careers. I find it really interesting the number of times they seem impressed by something I did that I'm just "meh" about.

Oddly enough, the opposite is true as well. I'm constantly impressed at the level of ability they have at this point in their career as compared to my ability at the same point in my career. They just simply know more. Of course, there's more to know these days but still, I find it impressive.

I'm not a "look at me!" kind of person, but here's what has really helped me with these kinds of interviews.

Keep a daily journal of what you work on. Nothing fancy, just stop by once a day religiously and add a few notes on what you did, what meetings you attended, who you spoke with, etc...

Save your evaluations and especially any award packages you or your team might get submitted for. At least where I work both are your supervisor's attempt to make you look as good as possible.

Then, when you're job hunting review your notes and bullets and collect the ones that sound the best and perhaps ones that have numbers assigned to them (size, savings, productivity, etc..)

Preferably you'd memorize these few stories about yourself, but if you must you could also bring a notebook with prompts to remind you.

If someone brought along an notebook full of problems they'd experienced and how they'd solved them to an interview I was conducting I would be very impressed!

My grandfather used to do this. He had notebooks filled with what he did every day of his career. It's really cool to be able to go back and look through his notebooks and see what he was doing in April of 1971.

My notetaking is not as rigorous as my Grandfathers, but I do something similar. Every month I make a new manilla folder with the month and year on the tab. Each week I write down every project I'm working on and every meeting I have. If someone brings me a new project I put it on the sheet. Every note I take a meetings and during projects goes in that folder.

At the end of each week I go through the notes from that week and write down anything interesting on that week's note sheet. At the end of the month I go through all the notes and write what I accomplished on the front of each manila folder.

It makes it really easy to keep track of everything you've done, without consciously keeping a journal in the moment. It's also a really easy organizational system. When someone asks, "What did we do for [x] in the past", all I need to do is flip through my folders looking at the front for anything that rings a bell, rather than trying to keep up with a tagged organizational system.

This probably doesn't work if you don't have a file cabinet though.

This is great advice, thanks. In the past six months, I've been better about keeping notes. Not specifically for this, but this is definitely another benefit of journaling.

Or, they just don't find the work terribly exciting. There's a lot of unexciting work to be done in software, and somebody has to do it.

There's definitely an industry bias towards "programmers as artists". If you don't love your work with a passion you're seen as less good.

It's an alright proxy for other things, but there's a ton of good developers that leave their ego at the door, and their work at work.

Good point. When I notice that people are struggling with finding something, I usually just pick one thing from the resume and try to go more in depth about that.

You sound like a good interviewer that adjusts to each candidate. I wish more interviewers would learn the importance of this.

> If I didn't know that you'd be asking for solutions I'm proud of, I might draw a blank at that moment. Granted it's an interview setting and these are the questions one needs to prepare for.

The key word there is "prepare". These are standard interview questions that you just have to have a prepared, rehearsed answer for that you can rattle off without thinking. There are tons of these types of "behavioral" questions. Tell me about a project that you worked on that failed. Tell me about a time you had to deal with team conflict. Talk about a struggling project that you had to help turn around. You can get a book full of them. Be ready with canned answers for as many as you can and practice them in front of a mirror.

> Be ready with canned answers for as many as you can and practice them in front of a mirror.

Practicing algorithms for a whiteboard interview sounds a lot more fun.

Yup, whiteboarding and reciting tried and true stories are inevitable routines when interviewing. However, you'd also be surprised at how many people don't know how to prepare for this. My main concern would be the possibility of turning a great candidate down just because they didn't happen to interview well.

> My main concern would be the possibility of turning a great candidate down just because they didn't happen to interview well.

Too bad (for candidates) that that concern doesn't appear to be shared by... well almost everyone in tech hiring these days. The general wisdom of the day seems to be "it's better to eliminate 100 false negatives than hire one false positive."

Probably because it's "easier to hire than to fire".

I worked with some really great folks that had trouble getting hired and it was because of the flawed interview process. One person writes concise and clear Rails code that's easy to read, and makes some of the wittiest comments on Slack (subtle puns that go unrealised for two minutes, then you finally get it and makes you smile). But he stutters a bit. And because of that, interviews are difficult for him. Which is a real pity, because in less judgmental situations, no one would think twice about that.

(Don't worry there's a happy ending and he's now at a good company.)

I learned after my first university job fair the necessity of being more outgoing during these situations, but there's great engineers out there who still live by the myth of "they'll know me by my work".

I think many will be able to tell the story if it is a story about something they care a lot about. Also, there is an opinion that good developers are good communicators.

You can be a good communicator without being a story teller.

Not being able to a story doesn't make you a bad communicator.

A story is entertainment not work communication.

Companies differ, and what they are asking of software engineers.

I was working with a brilliant guy in the same company. He was very technical and you could say that easily he was programming all day long non stop. His intelligence and technical expertise amazed me. Thing is he wasn't good with people skills, hence he wouldn't fit the company I am currently working for.

There are companies that hire devs to solve a problem and give them time, space etc to go all hardcore. Then again there are companies that require from their dev's to be able to communicate with the rest of the team, and take part on meaningful theory-crafting meetings.

So neither whiteboarding, nor tell me a story question is wrong.

I just find it that whiteboarding difficult questions should be asked from the very technical jobs, and I've found whiteboarding difficult questions when interviewing for a company that wants to move out of wordpress to their own website in angular.

> It could be that this technique favors people good at telling stories.

It does, but then again, maybe that's what they're going for (even if subconsciously).