Hacker News Reader

Comment by JustSomeNobody | Hacker News Reader

> But the aha moment for me was that not everyone does well in those fast-paced brainstorming sessions. A lot of people (including me) prefer to sit with a cup of coffee and some data and try to think things through.

This is me. Hard to get that across in an interview, but once people work with me, they're cool with me coming back an hour later in an email with some thoughts on the last meeting topic. They know and respect that that's the way I work[0].

[0] I'm not the only one on the team who does this, so that helps.

View on HN

We french have an expression for that: "l'esprit de l'escalier", literally "staircase spirit".

It's meant to characterize people who think about what they should have said/answered only when on their way out, in the staircases.

I think I work this way. Maybe it's a way to ignore my lack of wit, my slow paced brain, and to maintain some self esteem.

Ha, wonderful expression, thanks.

Given that many people report that their best thinking is done while walking or taking a jog, it might not be too wild to try out interviews which allow the candidate to take a walk before they give an answer.

that's an interesting idea. how can we implement that without it becoming awkward?

the problem i see is this:

it is unexpected, so the interviewee doesn't know what to make of that offer.

i don't know how much time to give them, and they don't know how much time they need. they also don't know how much time they should take.

i don't even know if they are the type that likes to take a quiet time to think. if they aren't then that offer could come across as a suggestion that their answer is wrong and they should think about it more.

at best it would be some institutionalized coffee-break, like we do the interview in two parts, first we are doing a bunch of exercises, then we take a break and after the break we do something else, but the interviewee is offered to add thoughts on the exercises that they may have come up with during the break.

The solution to unexpectedness is to tell them up front what you're going to offer. With that in mind, I like the idea of the "coffee break" where you're allowed to wander off.

Of course, you can also just leave the room while they're working on it.

I'm like this and I know why it happens for me. I cannot think my thoughts while listening to others. Either I'm listening, or I'm thinking, I cannot do both at once. I can follow others and sometime I can make a contribution, but it would be a small contribution, a deal less than I could do given a time to think.

I tried to find some way around it, and the only way I see is to learn how to think loudly. The only way is to supress others from thinking by speaking aloud my thoughts as they come. Let others follow my thoughts, not the other way around. I figured it out while making some group work with ~20 yo students being a student myself. I'm older (I was 35-40 over that period) and therefore smarter and in the most cases I was able to do this group work myself a way better then they do.

I tried different approaches. I tried to take a leader role in a discussion and to talk everytime I feel like this. I tried to let someone else to become a leader and to follow her. I tried to just get out of the discussion, to sit quietly with my own thoughts and to come with my own solution to compare it with the group one. The conclusion is: I cannot think AND listen at the same time.

Hijacking this thread to say that blog post isn't about Microsoft as a whole, but only about Microsoft's Developer Division (Visual Studio, etc.). The rest of Microsoft still uses the standard whiteboard/Leetcodey approach.

My life's motto is: "Let me think about it, I'll get back to you."

That same nugget was in The Pragmatic Programmer which I recently have been reading. In regards to estimates or questions about things you don't know, if you can't give a good answer on the spot the second best answer is "Let me get back to you.". The bad answer or estimate will just cause pain for your team/org.

My goal when interviewing candidates is to ellicite this response at least once. I want someone who is honest that they don't know the answer and won't bullshit me about it. Also like to hear how the candidate would go about figuring it out, e.g. what resources they would use. I'm also fine with speculative answers as long as they're clearly stated as such, "I dont know, but I think it'd be something along these lines..."

Yeah, in an interview, I would certainly expand on that succinct motto; and attempt to do exactly this. But, as others have suggested, people respond too much instead of just thinking about a problem/issue/comment/etc. from all the angles (this skill was natural for me; but honed during the Ph.D. process.)

It took me a very long time to realize this is an okay reply. "Let me stew on this."

I’ve never done any leetCode style interviewing or studying, but from what I have heard, it’s all about “pattern matching” and knowing how to solve similar problems.

I have done plenty of architecting. A large percentage of architectural problems that you are asked to solve have already been solved. After enough years at enough different companies and reading enough architectural books, it’s just pattern matching and figuring out the correct tools.

Can you recommend several such books?

(None of these are affiliate links)

https://www.amazon.com/Domain-Driven-Design-Tackling-Complex...

https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma...

https://www.amazon.com/Clean-Architecture-Craftsmans-Softwar...

https://www.amazon.com/Patterns-Enterprise-Application-Archi...

https://www.amazon.com/Refactoring-Improving-Existing-Addiso...

https://www.amazon.com/Code-Complete-Practical-Handbook-Cons...

https://www.amazon.com/Pragmatic-Programmer-Journeyman-Maste...

https://www.amazon.com/Mythical-Man-Month-Software-Engineeri...

And just because it’s asked at every interview.

https://www.amazon.com/Design-Patterns-Object-Oriented-Addis...

I’m focused on AWS these days, but a lot of these principals are universal.

https://d1.awsstatic.com/whitepapers/architecture/AWS_Well-A...

This is actually something I've encountered outside of interviews in day-to-day work with teams.

When the topic is something where I know some underlying complexity exists, or the stakes are high, I often want to spend a bit of time thinking it through by myself because that's how I think best about those sorts of problems.

I've encountered friction at times with those that aren't familiar with and/or care about the underlying complexities and just want to talk high-level and make decisions and move on. Sometimes it is important to make quick decisions to avoid analysis paralysis, but often it is worth giving those who do best thinking through things on their own a chunk of time to go off and do what they do best. I wish more people took that into consideration when conducting brainstorms.

I had a different experience. They gave me a lot of time but either I don't know python at all, or they didn't.

they asked me to build something. I used dictionaries and wrote the code in ten minutes.

Both interviewers wouldn't believe that the code could solve the problem.

They later told me that dictionaries are not used in practical applications. Never understood why.

Are dicts not used in "real life"?

Dictionaries are used ALL the time.

Exactly! I was sitting there wonderinf if they understood doctionaries at all. My guess is that they came from Java background and thus don't use dicts as default as HashMaps aren't native basic data types

I'm not the best with Python, but if someone gave me that answer I'd feel like I avoided a land mine. Dicts, and analogous data types, are incredibly useful.

Yes! I avoided the landmine. I can't imagine how I'd have felt working with a woman who interviews for Python role and doesn't know or understamd dictionaries!!

Plus they were giving me (x%) a raise, and I got (x-5)% in my current company. So thank God I didn't join there. Contacts are more important than salary.

I'm not sure I can think of a python application I've worked on that didn't use dictionaries in some way.

Exactly! That's what bothered me, plus the fact that they didn't understand my code of 10 lines.

The most charitable explanation I can think of is that they have a very narrow idea of "practical application" where the performance of looking stuff up in hash maps all the time is not good enough. If that's the case, they should have been more specific, and asked for specific improvements. Otherwise, they're full of shit.

Yeah, that's what I thought. She kept yapping about how this is not a performance tuned code blahblah

This is fine in most situations, but sometimes companies want people who actually have experienced in a given problem domain, and generally speaking, if you have to "sit with a cup of coffee and some data and try to think things through" that implies a lack of experience, which may not be desirable to the interviewer.

I'm one of a couple domain experts on my team. I am well respected as such. The reason I "sit ... coffee.. think things through" is because I am doing a mental impact analysis. How are the suggestions going to affect the system as a whole. One simply cannot know these things off the top of their head in a meeting for a system of any meaningful size.

It is precisely because of my experience that my team is OK with me taking an hour to ponder.

Edit: Let me clarify one thing. I'm not talking about situations where, say, the PO comes and asks, "Hey, JustSomeNobody, why does the system do this under these conditions?" I know the answer to this. If they want logs for that specific instance, I can get them. What I'm talking about is, when the PO calls a meeting and says, "I just got off the phone with <Entity>, they want these changes to the system. What will it take?" I don't answer these questions, definitively, without thinking about them. That does NOBODY any good. I'll sometimes give a few initial thoughts for the sake of the meeting, but that's it.

thinking. it's almost a lost art.

i’m like this but admittedly, in some cases, you’re interviewing for roles where it’s critical you identify that candidate can think on their feet (eg devs that might need to serve in 24/7 ops roles), where “let me get back to you” isn’t a feasible option

Usually those who optimize for thinking on their feet do so at great compromise in quality. Maybe you can afford that, but it's kind of "shooting from the hip" so to speak.

It's probably not that these candidates can't think on their feet, it's just that they generally aren't willing to compromise so greatly on accuracy and quality of the answer.

in a situation like that i'd like to see both happening. start the emergency procedure, and while it's running think through if you missed anything or if there is an alternate approach.

just had that happen. we had an overloaded server, and while we tried to figure out how to make the server faster, after some thinking we realized that the better long term solution was to change some of the architecture so that the server would get less load to begin with.

that was definitely not what came to mind first.

That's reactive thinking and it honestly sucks. While you might encounter unexpected situations from time to time, a good ops person will be preventing problems a lot more than he firefights. If you only hire a good firefighter, he will do the only thing he knows ad infinitum.

I've worked with people that were reactive and would love to be "the fixer" when, in reality, 99% of the issues he fixed were caused by his ignorance/incompetence in the first place.

Specially for crucial 24/7 roles, you need people that think ahead and not reactive ones.

Reply on news.ycombinator.com