Hacker News Reader

Comment by lnsru | Hacker News Reader

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.

View on HN

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

Engineers are treated like robots.

And yet, the majority seems to oppose unionizing despite calling themselves tech workers. Puzzling, how often people act against their own interests.

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.

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.

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

It's not a statement of fact that we know whether a union for software engineers would be good for these workers. The jury is still out.

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.

I so wish I could contradict you, but in my own experience good coding skills, even after years of experience, seem to be a rare gift.

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.

Being able to code well is more easily measured than "softer" skills.

If you can't code, it's immediately obvious.

Being a good HR person or Inclusivity Officer is much more subjective.

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.

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.

You lost an opportunity...

https://aphyr.com/posts/341-hexing-the-technical-interview

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.

But it’s not traditional storytelling like in role playing games. It’s some small made up lie for every possible special situation in the interview.

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.

Well yeah of course. Even the article didn't think story telling is appropriate for technical interviews; its the behavior ones you tell stories in.

you are 100% right

Nobody cares about anything except that coding question that is given during the interview

Even if you have an impressive portfolio of dev related work - the only thing you are judged on is that leetcode task during the interview

maybe at the vp/em level - where the job is talking it might be more appropriate

Reply on news.ycombinator.com