I had many many technical interviews this year. Nobody wanted to listen to my stories. I got a technical task and needed to solve it. From explaining steps in Visual Studio on paper how to create a functional hello world GUI. To some crazy undefined system design tasks. The single story I was allowed to tell was my introduction. I never experienced an interview where somebody wanted to do something else than assess my technical skills.
> I never experienced an interview where somebody wanted to do something else than assess my technical skills.
I don’t understand why interviews in the software I industry are so different compared to other industries. I also get the impression that during many interviews what you’re about and what you’ve done matters very little. All that matters is if you can solve two Leetcode hards in an hour multiple times.
An alarming portion of people in software industry can't code. Leetcode or otherwise. This was shocking for me when I started interviewing but it is what it is. Most people just can't code.
I don't like brainteasers and never propose anything remotely intimidating. After all, interview is a stressful affair as it is there is no need to make it any more so. But I'll never hire a person who can't write a few lines of code on demand either.
It's because the amount of story telling and wordiness in an interview is often inversely proportional to the amount of output produced by that engineer.
I've learned the hard way not to hire the big talkers. Doing is much more important than saying.
Having been on the "other side" of the table, I can kinda answer this.
In my experience, the interviewees who talk too much are the bullshitters (in fact that's a red flag). They usually can't code for nuts. The ONLY way to separate the wheat is to give them a problem and then see how they navigate it.
Those who can talk AND code are worth their weight in gold.
Talking too much can be a sign of nervousness, or maybe because interviewee read a an article advising to keep no pauses. That's not necessary a bad indicator. It's when you are fed with long, but barely related stories instead of answers on concise questions then you can suggest bs is being produced.
It's because the top earners make obscene levels of money, and a union might disrupt that. So you have a situation where a company might only lose lower performers to unionization, which they can afford to handle.
Partly true. Unions are a way to balance power disparity between Owner and Worker.
Currently, tech mostly has more work to be done than engineers to do said work - so the balance is tipped toward the individual. (At least in the US). Once that balance is tipped the other way, the value of Unions will go up dramatically.
That seems to be mostly a US thing. Programmers there seems to be more libertarian than elsewhere, and unions are seen as, if not an embodiment of Big Bad Communism, at least a recognition that we’re not as independent as we might would like. Here in France we’re hardly opposed to unions. We’re lazy in not joining for sure, and some do say they’re useless, but almost no one would dare suggest they’re bad.
By the way I believe the difference between our ways of thinking goes beyond such politics, and influence our technical decisions as well. Someone who’s all about negative freedom (lack of restrictions) and distrusting authorities (most notably governments), is I think more likely to prefer permissive licences and dynamic typing.
Conversely, those who prefer static typing are more likely to see programming as a branch of applied maths, accept more immediate loss of freedom for a greater good, and believe that a government can be trustworthy even if they may not like their current one.
> And yet, the majority seems to oppose unionizing despite calling themselves tech workers.
I find this an interesting statement because it equivocates self-identification with a socio-economic class (Workers) with a banal statement of fact ("I am employed doing work in a certain field"). The identification with Workers as a class is a political-philosophical stance, whether in the old school Labor vs. Management sense, or Marx's Proletariat vs. Bourgeoisie or some other.
Is it really so difficult to believe that workers in the second sense (the set of people providing technical expertise for money) have a diversity of views on any subject?
> Puzzling, how often people act against their own interests.
Perhaps. As humans we can all be short-sighted. It is also possible that the evils of working in the tech field are somewhat exaggerated. We are paid well relative to the median, we get to work in conditions that would have been considered luxurious across most of human history (temperature controlled indoors, without physical labor), and can pick our level of engagement (working at high finance or in an early startup is trading high risk and stress for the promise of a better payout, working in established businesses allows for fewer hours and less stress).
I think there can be good stories that capture interest, however you should use some sort of method to first test the waters whether this sort of story would be interesting to the other party.
Reading the blog post, the story about tripping due to bad shoes to me would be a turn off to hear. Because are they going to tell this story from out of nowhere?
If they started off with "I had a crazy scare today, I almost slipped and fell walking high up.", I might appreciate it more since I can choose myself then to ask whether I want to hear more details about the story.
Otherwise the story just takes up too much time and it's not polite to interrupt them. It's a risky investment of time that the other party might not appreciate or care for.
Of course it depends on the personality of the person who you are telling the story to. Some people definitely may appreciate the detailed visuals etc, but to me when someone ends up with a long winded answer, I tend to think "man, they could've just summed all of this information up with one sentence".
I took the story as simply an example of the difference between an interesting vs uninteresting anecdote. I think it's implicit in the article that the story you choose to tell is relevant to the interview situation you're in.
Yes, however still to me people sometimes will talk too much, when it would be much better where they are concise at first and I can ask immediate interactive follow ups about the details. Interview is such a limited time so to me it seems most efficient to have a dialogue out of the box.
Or they should at least make pauses to give opportunity for cuts.
I don't want to listen to prose someone studied word by word.
I don't need to "feel" the challenge as the author said. I need to be able to figure out during 1 hour the problem solving capability of the candidate. If they spend unnecessarily much time on stories, I would be concerned whether they are a bser and want to limit my ability to ask questions as the time runs out.
Maybe at the beginning. But later they will definitely want to hear more about what was accomplished on past projects, and that lends itself to the story.
It probably depends on the company, the 'tier' of companies or your level. After reaching 'staff', the bulk of time spent in interviews is on the behavioral side, which is literally storytelling. Even interviewers tasked with evaluating technical competencies reserved 10-15 minutes at the end to ask 'loaded' TMAAT questions - 'Tell me about a time when you wanted to quit on the spot', 'Tell me about a time when you were publicly humiliated' - and the likes.
>I never experienced an interview where somebody wanted to do something else than assess my technical skills.
That's such an outlier I struggle to believe it. Nobody has ever asked you about your work history? Never about a time when you needed to work in a team to solve a problem, etc.?
I worked at a company where we split the interview up. 5 interviews (including HR screen). The 3 tech screens were just that - tech screens. You didn't go over the work history or work in a team. It was three 45 minute sessions with a developer where you were given leetcode questions to complete in the 45 minutes. Nothing else.
I was asked to do one for another team and during the meeting where we discussed if the prospective hire would get hired I got in trouble because I didn't copy and paste the candidates pseudo-do code into an IDE and see if it compiled. I never agreed to do one again.
According to the article, had you spun an interesting enough yarn full of half truths, you might've been able to skip all that stuff as you lulled your audience into a false sense of security.
All true! But not limited to interviewing. Most human interactions rely on some form of storytelling. He who controls the story often control the outcome.
Storytelling is how we understand the world.
Is this overused? Sure. Do many articles start with the same couple of sentences, so much so as to become ridiculous? Sure. Is the New Yorker one of the greatest offenders? Sure.
But we can't do without story. It's not just that stories are interesting; it's that, if there's no story, we often cannot understand what is being said.
> it's that, if there's no story, we often cannot understand what is being said.
There's an interesting corollary here to the mundane art of stakeholder management:
One of the first things you learn in this art form is that, if you don't provide a story, people make up their own. Ten people can look at the same stew of random events and come up with 10-20 different stories about what's happening and why.
I'd say it's not just that stories are interesting; it's that we manufacture stories as a way of parsing and compressing the world into something understandable.
It is very difficult for humans to remember just a set of facts and reason over them. So stories are how we spread the facts out thin and link them. This is also the technique which athlete memorizers use to remember the order of deck of cards. Story telling or associative memory or stream of consciousness is how we remember stuff.
Yes, very important point as well! If there's no story around the facts, we can either ignore the facts, or build a story to fit them in. Stories are where we store facts.
More often in my experience "x causes y" is how people misunderstand the world. "x causes y" is true in physics, but it is almost never true in metaphysics (anything involving humans).
Trying to explain deeper complexities of metaphysical causality in a logical or scientific way almost always is rejected with a story, and higher base intelligence or a science background tends to amplify the problem rather than reduce it. More cognitive power = better, more persuasive stories I guess?
Have to agree with part of this.
I'm not sure how bad the New Yorker is.
Over thanksgiving did have this happen.
Wanted to lookup a recipe. Just Instructions.
But had to wade through 3 paragraphs about the authors trip to see her grandmother as a kid, riding in her parents car through the country, the sun through the trees, etc......
I just wanted a recipe.
As much as I recommend telling stories, do keep it to the point.
I used to think this way about recipe stories, but I've changed my mind about it.
There are arguments about people doing this for SEO or ad revenue. But also personally I really don't mind the stories. I think it can give a lot of interesting background context for a particular recipe. If it's not interesting it takes like 2 seconds to scroll past it.
Also it feels just a smidge karen-y complaining about a recipe that's shared with readers for free on someone's personal blog just because it also has an easily skippable life story attached (you know, life stories, the kind of thing that you'd normally put on a blog).
Maybe you could make an argument that such an author could optimize for less frustrated viewers from search engines looking for recipes if they removed the fluff. But I think either (1) they would prefer to optimize for the more loyal recurring viewers with an interest in the author rather than the grab-recipe-and-go type of viewer, or (2) the fluff is what adds the SEO that brings in more of the viewers in the first place.
Sure, if it is a home grown personal blog. And it's a real story, then fine.
A lot of them appear to be just churned out by a corporate like Food Network, and many others, that are just filling up the online-recipe-ad-industrial-complex.
They seem very much like vanilla created stories to give the 'veneer' of 'quaint homespun' stories to provide the feel good quality.
I'm pretty sure those awful recipe stories are just there so an advertiser thinks you saw their ad when you click 'skip to recipe'. Or maybe that's just a story I tell myself to make sense of things.
I would argue that we can do without stories if we choose to - most people don’t think about it, don’t see the value in it, and aren’t committed to doing so.
Stories are simply the path of least resistance for how our brains work - they satisfy something primal. It takes hard work to countermand that internal process.
As an interviewer, when I rate the candidate that I just interviewed, I will take into account how good the candidate is at communication, but it wouldn't be a decisive factor. The decisive factor would be whether they solved the problem and wrote good-quality code.
If you have extra N hours to prepare for an engineering interview, I think spending them on practicing problem-solving and coding would be more efficient than practicing storytelling.
If you are already pretty good at interview problems, it might be valuable to invest a bit of time into communication. Doing a mock interview or two would be good way to do it.
One the biggest challenges I am facing with a colleague I hired (I was not the hiring manager but technically it was my say finally) is their communication skills. They find it really hard to explain a problem to others. They also do not listen properly or adequately and it is not malicious at all. I did not consider communication as a deciding factor at least to some extent. Lessons learnt.
Also, I have been focussing a lot more on “coding” problems (as in that whiteboard thingie) because that is what I guessed asked whenever I interview. I am going to work on that as well. That, while shows candidate can solve that coding challenge, is more of a GRE - GRE shows the person is good at taking GRE and may not necessarily be good at english, maths or reasoning at all.
When I wrote that it's not a decisive factor, I didn't mean that it doesn't affect the decision at all. It happened to me once or twice that I had such a hard time communicating with the candidate, that I highlighted it in the report and gave them lower rating.
The other side to this is that if you're interviewing and communication is not a decisive factor, you should walk away. You don't want to work in places where this is common practice, as your job will be unnecessarily difficult, communication being the most important part of software development.
That hints to me that you are likely a "Jira ticket shop" and the engineers are handed code tasks on at a time. They aren't expected to be part of team figuring out the product problems and improvements.
Very few interviews I’ve done had a real technical component. Most have been talk about what you’ve done, how it brought value, how I approach problems, etc.
This is for data science, data engineering and cloud architecture positions.
I sometimes think problem set focused technical interviews are an American thing. Even when applying at google in Europe I didn’t have a technical test.
What position in Google were you interviewing for? I thought any engineering position requires around 4 technical interviews. There is no difference between Europe and the US in this regard.
Something like a customer success engineer. What I was told was my technical interview consisted entirely of thinking of reasons why an imaginary customers AdWords weren’t showing. I didn’t move on from that so maybe there were leet code waiting for a more suitable candidate.
I do hardware design in the midwest US and my experience tracks yours. I've done maybe 10 technical interviews over the last 10 years. They typically want to talk about problems I've had and how I've handled them, some basic level of technical understanding (i.e. explain this circuit, or show how you would change X parameter of this design), and in the better interviews they ask questions to see how I communicate with people.
Better communication skills have easily tripled my negotiated salary. I was always this good at tech stuff, but not at speaking. While what you say may be true, I question this being normal or the average. Most of the time folks want you to talk well and that's what rewards you.
I'd like to add that while you are right for engineering, for certain analytics roles communication would be the decisive factor I'd consider (granted of course the candidate knows how to use SQL and got decent scripting skills). The reason is most of our job as analytics engineers is communication and translating stakeholders business problems.
To clarify a bit, cause it matters. This is more of a listening skill, and then an analytical skill. Mind you listening is half (or more?) of good comms. But evaluating listening is 10x more difficult than speaking or writing. The latter two are not a proxy for the former.
Has anyone encountered someone who was poor at both verbal and written communication but turned out to be excellent at designing and writing maintainable code?
Maintainable code in this case would be a combination of using clear and easy to reason about logic, good names for everything, creating useful non-leaky abstractions, no major performance issues, thoughtful and extensive test cases, good documentation, etc..
Yes, It's not too uncommon to see devs producing good software, but struggling to communicate on a less-technical level, either with non-technical people or with technical people who aren't familiar with the specific subject/domain at hand
Yeah, actually it could be the case, where someone who is so deep into what they are doing, they don't understand how everyone else doesn't understand the intricacies and so they end up explaining and communicating in a way that others don't understand. Even though it is said that if you can't explain a concept to a child, you don't really understand it, but I think there still can be cases in which you are so deep in there, you have hard time grasping what is the best way to make it simple for others considering their understanding.
Especially if you have been working around other people who are deep there and now you are put into a group where people have completely different levels of understanding.
It's sometimes easy to assume that something is common knowledge when it really is not, because it seems so natural to yourself.
And obviously I have faced it the other way in different fields where I absolutely lack all the knowledge and they start to use terms I am clueless about, but I feel stupid about asking about each term because they talk in a way that it seems they think it's so obvious that I should know.
Solving a problem internally within your mind is a form of communication as well. This is also the reason why rubber duck debugging works. The solution is not revealed to you unless you are Ramanujan.
It's exactly what I do. I always try to bring the interviewer on a territory I am comfortable with and paint myself in a good light.
If you seem hesitant, if you seem unsure about what you did and why, it's not good. Why should an employer trust you with the job if even you don't trust yourself that much.
From two people, one with lower technical skills but with good people skills, projecting trust and confidence, the other with better technical skills, the former will almost always win the job. Employers want wheels that work well with other wheels and turn fast.
You don't absolutely need to paint yourself in a good light. One can describe mistakes, mishaps, even times when they were being mean. Injecting some bad outlooks can help balance the narrative and make the whole picture look more sincere.
But the hero of the story has to be in charge. They can fail, or make huge mistakes, but they can never watch events happen and pass them by, without them doing anything. That's the worst mistake a storyteller can make.
>Injecting some bad outlooks can help balance the narrative and make the whole picture look more sincere.
You have to asses whether the person values sincerity or it wants a new shiny thing. Act like a car salesman. Also, look into the interviewers eyes. Try to watch your gestures.
I never injected bad outlooks unless being asked what were some mistakes I made. I made sure that my mistakes were insignificant and maybe not mistakes at all.
I am a purrrfect developer/architect and I want to help making the company purrrfect. We want to satisfy our customers, while making lots of money for the shareholders, make all bosses happy, big and small, and achieve great things together as a team. That's the message.
> You don't absolutely need to paint yourself in a good light.
That really, really depends on the interviewer. Some will laud sincerity, others will scorn weakness. Though personally I could never figure out who I was dealing with before I tell my story. If they don’t like how I am, oh well. I’m not hungry yet.
I can’t remember exactly where but there was a study- it could have been recommendation letters or maybe resumes- where candidates who has some low to mid level flaws mentioned were rated significantly higher. I think the theory is that a couple minor downsides make the upsides more credible. Obviously there’s limits. And going on a long rant about how crappy you actually are would def provide needed entertainment.
We are arguing semantics but IMO the sincerity is part of painting yourself in a good light. Saying you are perfect is not painting yourself in a good light, but making sure you attribute success also to your colleagues (I did x they did y) and mention good things you did, even with mistakes, ultimately tells good things about you.
TBH, that's still painting yourself in a good light. Just a subtler approach to that. Overcoming flaws is more compelling than never having them in the first place. Because we all know that everything/everyone fails all the time.
There’s a difference between hesitating and pausing to think. Perhaps not internally, but in body language. In some ways they’re even polar opposites: hesitations are involuntary and make you look weak, while pausing to think can help you control the pace of the conversation, and (if not overdone) can grant you some authority.
The timing is very important: if you pause in the middle of a sentence that generally feels like a hesitation. If you pause before you start answering, then it’s all fluid, that’s pausing to think.
I can accept that this is effective with most companies, and I don't blame you for doing what you can to increase your chances, but in an ideal world each side is their genuine self.
I understand that some people see an interview as a sales meeting, but in the end, if it works out, what results is both sides having to interact with each other on a daily basis ideally for a long time.
An employment relationship is in the end a relationship between people. Embellishing in an interview just makes that relationship uncomfortable.
> in an ideal world each side is their genuine self.
You're hired primarily based on other people's estimate of you. They'll hold you in higher esteem if they like you. I don't see how you get from "it's a relationship between people" to "you should be your genuine self". Interacting with others always involves a certain degree of masking, unless you are implausibly neurotypical.
>An employment relationship is in the end a relationship between people.
I view it as a product sale. Me selling my knowledge and skills, they buying it. Similar to how they sale or rent their software to the customers.
A company is not people, a company doesn't have soul. It solely exist to make shareholders profit. People at the company I will have relationships with, and I try to have good relationships.
I never lie, just tell the story they way I benefit from it.
>what results is both sides having to interact with each other on a daily basis ideally
If I foresee that I might dislike the interaction in the future, I can just move over.
If you like the idea behind this advice, have a look at The Job Seeker’s Script by Judith Humphrey.
If you want to read it before buying (or borrowing) it, have a look at some of the articles on fastcompany.com that excerpt parts of the book, particularly the hiring/career articles: https://www.fastcompany.com/user/judith-humphrey
> I'm not talking about making things entertaining. But it does matter how you phrase things. You can mistakenly make a complex thing sound simple, and you can make a simple thing sound complex.
Which is obviously true. Storytelling might be a way to deliver that message more clearly in some cases. But to be honest, the sections where the author starts to tell a story, I just glanced over.
Storytelling is overrated – in interviews, in marketing, in non-fictional books.
The audience must be factored in when crafting the story. Because it dictates aspects of it. the language used, the embellishments added/removed, delivery method, the actors etc must be carefully crafted.
Some stories are short and straight to the point.
I had a colleague where if the analogies are used to as part of the story told, the message is not full understood by him.
Now let's say I am responsible for hiring. Obviously, I can't hire a person with no skills, or I would be in trouble. But given a developer with a decent skill set, which is an agreeable person, shows will and passion and he is determined to make things work, and a person with just better technical skills, I would chose the first. Because for me and my colleagues the interactions matter and having a smooth process also matters.
Agreed. If you stick to the 'smart and gets things done' mantra when hiring, lots of things like 'better skills' are trumped by the idea that if they are smart, they'll pick up the skills they need.
The absolutely low hangingest fruit, highest ROI activity I recommend every candidate do as they're gearing up for a job search is to meticulously go through their past work history month by month or even week by week and dredge up the memories of all the things they've actually done leading up to this point in their career and then find another person and do the physical act of explaining each of the things so they know if they can even tell the story in a way that makes sense or not.
The reason I believe it's the highest ROI activity is because I keep on suggesting it to people and most people think it's a great idea and then they don't do it. It's gotten to the point where, for the people I really care about, I have to schedule a 3 hour block with them on a weekend and sit down with them just to actually have them do it and after it happens, everyone agrees the result is transformative but people have a weirdly high activation friction to actually doing this.
It should get to the point where I can quiz you on a "tell me of an example where you X" and they should be able to rapid fire answer back to me what example they would pick and we can do a round of 30 of these in 10 minutes. If they find themselves having an esprit de l'escalier moment of wishing they had picked different examples, that's a sign they should go back and revise more.
I have so many friends who have done so many awesome things in their career but then freeze up in the interview and just plain forget to mention the perfect relevant anecdote and they think it's some defect on them but, surprise, all of our recall is terrible and we all constantly forget details of things that happened years ago and the only way to get good is with discipline and practice.
Another technique I encourage every candidate to master is the classic politician technique of transforming every question into the question you wished the interviewer had asked in a seamless enough way that they don't notice. eg: One of my close friends who I coached was absolutely terrible at hypothetical scenarios, she would totally freeze up because that's not how her brain worked. I trained her so that whenever an interviewer asked:
"How would you design this theoretical feature for this made up example"
Her templated reply would go something along the lines of:
"Oh yeah, we faced quite a similar problem when I was working on [...] at [...]. The way I approached it was [...] because [...] and it meant that [...] for [...] stakeholders. So I guess in this scenario, I would apply those same techniques [...] to make sure that [...] met [...]'s requirements.
At the end of the day, we're generally all in denial about how much interviews come down to vibes and how vibes is a very trainable skill that it's very possible to reduce the error rate through practice (note: this is different from presenting a different vibe from how you actually are IRL which I generally advise people is long term counter productive). Engineers especially have a lot of emotion invested in how interviews "should" be that isn't at all concordant with any version of reality and they have hangups about investing skillpoints in things that empirically improve their interview performance because it goes against their mental model of what should improve their interview performance.
Well, I think I did good at interviews, not because I have the best technical skills, but because I trained a lot for interviews. And I not just imagined what potential interviewers might ask, or read a lot about interviews online.
That might be helpful, but what worked for me was physically going to a lot of interviews. The more interviews I went to, the better I became at the process.
And going to lots of interviews had the side effect that I ended up having to chose from several positions I really like.
More than that, a position which I kind of not thought greatly about when I read the job description and I read about the company turned out to be a great workplace for me. So even if you have some doubts, it's better to check it.
> but people have a weirdly high activation friction to actually doing this
Storytelling is hard. It takes effort and practice. It requires to think about all the stakes and all the stakeholders. In AI terminology, it uses a large context window.
People don't do it because they're unfamiliar with the techniques. They need to train until it becomes second nature.
> The reason I believe it's the highest ROI activity is because I keep on suggesting it to people and most people think it's a great idea and then they don't do it.
There is nothing in this sentence to suggest anything about the ROI of this activity, except your 1-person opinion. Maybe it's a high ROI activity, maybe it isn't, but we'll never know if people never do it.
Maybe people are able to get jobs without it, or do it and just never tell you?
>note: this is different from presenting a different vibe from how you actually are IRL which I generally advise people is long term counter productive
No, sorry, that's exactly what a LOT of this advice is doing - getting someone to change how they communicate to satisfy someone else with ways and methods that aren't natural to them.
You can test whether this is really true if someone is willing to accept written answers to interview questions exchanged over email. Clear communication supersedes the format.
You cannot pretend this is anything other than pressuring people who prefer to communicate differently, which is fundamental to human tribalism.
But I've observed it is always one side that should be satisfied, rather than reaching a compromise.
"Funny that you ask me about this problem! One time, my brother, who is now out of state, had a similar problem and came to me. He said: "I have these numbers, and every time theyre a multiple of 3 or 5..."
People on both sides of the table have the common misconception that coding challenges are about solving the problem. They're not, coding challenges are there for me to gain an insight into how you think through problems and the questions you ask are 100x more important to me than the code you write.
I have a colleague who, every coding challenge, immediately started by writing a bunch of tests and asking questions around the edge cases so that he could clarify the exact specs of the task he was being asked to perform. Any interviewer who didn't roll with that was a sign to him that there probably wasn't an engineering maturity culture fit and helped eliminate a lot of companies.
The story he was trying to tell was that he was an engineer that considered understanding the problem to be a much more important task than understanding the solution and he managed to tell it via the way he approached whiteboard coding.
> Any interviewer who didn't roll with that was a sign to him that there probably wasn't an engineering maturity culture fit and helped eliminate a lot of companies.
Different problems test for different skills. Perhaps that colleague just misunderstood what he was being tested on.
Linus Torvalds had this to say: "Bad programmers worry about the code. Good programmers worry about data structures and their relationships." Not every coding challenge is about software design skills. A large number is about the programmer's potential to code to DS & A. It's assumed that design, philosophy and other moot software skills can be picked up, or that internal coding standards and code reviews somewhat mitigate a lack in that area.
But I can very well see a mature engineer being annoyed by someone incessantly asking to confirm small details on a problem where they could make their own decision about terminal and exceptional conditions. Even if they have to explain them later. After you probe your interviewer once or twice on edge cases, you're usually told to assume the simplest situation. This should nudge you to what you're actually being tested on. No need to beat around the bushes, just solve the problem.
Also, to gain insight into the culture of an organization, don't just assume or infer things, like that colleague did. Ask proper questions. Express that working in an organization with a mature engineering culture is a concern of yours. Ask about code review, software development philosophy, etc. You've shown yours, ask them to show theirs.
I tell them "Hey, I've used this question before when I'm interviewing developers" (often not true, but what's a little white lie), then explain what I'm looking for in a developer when asking those kind of questions.
It makes the point that while those kind of coding challenges could be a useful filter or signal, it also stresses that I'm looking for a senior developer role and that perhaps time would be better spent assessing that part of my skill-set.
I also had an interview where I joked, "You're not going to ask me to define SOLID are you?".
The interviewer sheepishly replied that they only ask that if the person puts it on their CV, before scrambling for a different question to ask.
> I tell them "Hey, I've used this question before when I'm interviewing developers" (often not true, but what's a little white lie), then explain what I'm looking for in a developer when asking those kind of questions.
I would thank you for that and I would ask you to kindly do the code challenge.
Story telling is not about code challenges. When it comes to code challenges, you can either do it or refuse the job.
Anyway, aside from a few bad faith individuals who try to make them seem smarter than you, the interviewers aren't going to fail you for small mistakes. They are more interested in your thought process, how you approach the problem and how fast. They even might give you some hints or guide you slightly if you are in trouble.
Talking through what the expectations are, what you're thinking and what you're doing help cover points where you may make a mistake and vitally where there's a disconnect with your understanding and theirs.
I've had paper problems to do that to solve the literal problem in front of me would be to write some very short code. But the problem looks like a shrunken version of a bigger system, and so explaining this shows I'm not just over engineering this toy problem I'm showing I understand (this was an early position) classes and inheritance and how to manage that.
Are you asking how I'd build systems to do this kind of thing? Are you asking what I'd do if the boss comes over and says they need this one off thing done asap?
You want to be seen as someone they could actually work with on something.
Exactly! Coding challenges are not about miraculously finding the right solution, which is boring (and extremely suspect). They are about describing a path from the problem to the solution, and dangers and pits along the way.
Given that some companies now have candidates do them on fully automated web pages, it's pretty clear they are often just about getting the right solution, and nothing else.
All job interview steps are "simply trying to filter out the pool of candidates". If it is the filter that removes the most people, that actually makes it the most important part of the interview process.
Ye. Story telling is important for the non-technical part of interviews (although some technical interview do benefit from some story telling). It won't save you from having to cram leetcode for days.
Am I the only one who is more than tired of storytelling as panacea trope? Yes, it has value. Yes, it appeals to humans. No, it's not a substitute for substance. As a tool, it has its place. But please stop using it as a euphemism for "When you lack substance in the moment, then baffle'em with bullshit."
I think this is extremely good advice so I'm making a top-level comment to defend it and respond to some of the criticisms in this thread.
First, no one is asking you to lie. This isn't about inventing details or exagerrating. This is about deciding how to answer and phrasing your answer.
Second, "story" in this case means personal anecdote, like the author's hiking example. It is not very closely related to stories in books or games or whatever. What can we say about the stories you tell casually at parties or with friends? Probably that they take less than two minutes, they start with an interesting hook, and they include a problem of some kind and the resolution to that problem. That's what your interview stories should look like.
Ex: Suppose you are asked, "Tell me about a time when you had a disagreement with a coworker and how you resolved it". Compare these two answers:
1) "One time I had a coworker that kind of hated me. I'm not sure what his deal was, we didn't interact all that much and I thought his work was pretty good, but he developed a personal animus towards me and started being rude and picking fights with me on Slack. He ended up getting fired after he threw eggs at my car."
2) "I was leading the effort to fix the critical-but-brittle X service, and I wanted to start by wrapping it in a service with modern deploy and test automation, so we could at least deploy it safely while we fixed it. However, the lead architect was opposed to that plan, because of Y. We worked through it by getting all of the stakeholders together and doing Z.
Which answer is more true? The first one might feel more honest. After all, the "disagreement with a coworker" part is much more central to answer 1 than answer 2. But it's also a terrible answer, because it has fuck all to do with your abilities. It's just a thing that happened to you that happens to meet the criteria the question asked for, but is otherwise not relevant.
a) think of the 3-5 best things you've done recently at work
b) practice describing them to a friend (you don't work with) the way you'd tell any other personal anecdote
c) When asked a behavioral "Tell me about a time when" question, instead of trying to comb through your memory of the thousands of experiences you've had at work, just ask yourself which of your 3-5 stories is closest, and tell it
d) if that feels dishonest (and it does to a lot of people!) remember that the whole point of an interview is for you to tell them how great you are. If they knew you had led the effort to fix the critical-but-brittle X service, they would've asked you. They asked a vague open-ended question to give you the latitude to answer however you see fit.
If storytelling isn’t part of your interviewing process you are absolutely leaving value on the table. You would be wasting less time interviewing & get better outcomes if you improved your path to getting into the interview.
Ideally you have a conversation with the hiring manager before you even enter the formal hiring process and storytelling should absolutely be part of that conversation. The story is “why you want to hire me specifically.”
Maybe it’s just my way of thinking, but the best stories to tell in an interview are not the ones that describe a work related incident. It is the story that links something irrelevant but deeply relatable with a concept to make an unexpected argument. The metaphors are much more powerful and succinct than an embellished or even erudite recollection. It’s like if you hack an established belief to ride your message on its patterns.
I think many folks are missing the fact that Dave's blog is largely targeted towards those in leadership, in which story telling/selling is an _essential_ skill.
"For interviews, it's not what you've done, it's how you explain what you've done."
Ye no. Just no.
Any interview advice that is not some general "behave and for God's sake hide your flaws" or meta discussion how to game them are bad.
"[Example] We needed to remove the cancellation feature because customers were confused by the self-service cancellation function."
Haha ... ye that is a funny example but I don't know if it was on purpose. Show how you are able to delude yourself into doing enshittification is probably a good advice for many positions.
Its great advice if you have no idea what youre doing and have been cheating/faking your way in mostly. When you really dont have any idea, keeping silent and applying what little you know could get you that job.
I've seen people who are pretending to know what theyre talking about say the most crazy shit when asked casually about something they did - like "my UI might be laggy because the server is slow" (the ui was completely clientside and offline). It would have been better if he had shut up because his UI was fine.
Most are not in the position to behave like divas.
You got like 1s to guess what the interviewer wants you to be. Like, if he has dreadlocks you probably don't want to be uptight and stiff etc. So it always depends on the situation of course, but on average "behave and hide your flaws" is probably best.
It’s not good advice. You have two goals during an interview: make someone like you and convey confidence in the stuff you’re being asked to do. “Behave and hide flaws” sounds like the advice of the most utterly fungible candidate for a low skill or entry level job.
You should be trying to have an enjoyable conversation.
Behaving is not something you should need advice for. Yes, you should “behave”. Don’t shit your pants either. But if anyone comes out of an interview and says “well that guy was well behaved” I’m going to have a very unimpressed opinion.
You should 100% be comfortable showing your flaws.
I has different experience during many rounds of interviews, especially for big companies.
Hiring managers want you to be sincere, but would lie to you many times during the process. No one will tell truth like: we are looking for person who likes overtime, will work under psycho manager and with 10-years old legacy application.
this thread is why the tech space is in such a shit phase. dev skills will always be better in the long run. i am not suggesting that you hire a shit person. i am suggesting you do not know how to recognize talent.
