Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Red flags I saw while doing technical interviews

blog.interviewing.io

Post reply on HN
Print view View original

361–370 of 394 posts

Re: Red flags I saw while doing technical interviews

#361

Post by maffydub »

pnw_hazor wrote: post #153
hinkley wrote: post #104

I sometimes feel self-conscious asking deep questions about morale, especially when I'm on the fence about working at a place and am just being polite in case I need this as a Plan C. There are some questions where if you get the person to take them seriously you may pop whatever bubble they're living in that helps them get through the day. One place, I was not doing so great. I was participating in the interview pro…

Interesting. It seems almost immoral to interview new hires when you know there are insurmountable problems at the company that make you consider leaving. Not saying you are immoral here -- just that it does seem to pose a dilemma. I have not had to interview someone for a company that I want to leave. It sounds like it would suck and require some level of internalized rationalization to go through with it.

"insurmountable problems at the company that make you consider leaving"

Is the problem with the company or that the company is no longer a good fit for the interviewer?

Personally, I've been interviewing people to join the company I work for while also on the lookout for changing jobs and I don't feel it's immoral.

I would recommend my current employer in general, but I'm not sure it's still the right place for me.

Re: Red flags I saw while doing technical interviews

#363

Post by ethbr0 »

tonyhb wrote: post #154
mdgrech23 wrote: post #55

Earlier quoted context omitted.

Would echo your sentiment that the role of project manager, product owner or whatever they're calling it these days needs to be rethought. In my org we literally have a squadron of these individuals which leads to bickering and an in-cohesive product experience.

Been thinking a lot about this - right now I run eng for a pretty broad product in healthcare, and there is overlap between eng and product. In your case, it sounds like you have crappy product leadership. This is _way_ too common. You need a cohesive product vision from the top down (VP/head of product), which they communicate to their team of PMs. The head of product needs to ensure that their team can make the cor…

> Really, I've noticed that at upper management this is literally your job: ensure that people make the right decision, whether they're your team, your peers, or upwards to the CEO.

To expand on this, there has been one defining difference in good companies and bad companies I've worked for.

In good companies, everyone has expertise. Your PM can talk about details. Your director can talk about details. Your VP can talk about details. They do this because it's culturally expected that they know this. So they spend enough time to familiarize themselves and do normal paper-pushing responsibilities.

In bad companies, that's just... not there. If you ask anyone of those roles about details, they don't know and can't speak intelligently.

Consequently, in the former, you get much smarter decisions from all players. In the latter, you get ignorant decisions because there's less shared knowledge.

The strangest thing is that it seems more cultural than training / education. Either the company has this expectation of its people, or it doesn't. If it doesn't, no amount of degree will paper over that. If it does, it doesn't matter if your people are sharp but lack degrees.

There's a famous story from Microsoft back-in-Gates-days, whereby Gates was notorious for his detailed questions in meetings: https://www.joelonsoftware.com/2006/06/16/my-first-billg-rev...

Re: Red flags I saw while doing technical interviews

#364

Post by ethbr0 »

screye wrote: post #71
vlovich123 wrote: post #50

Earlier quoted context omitted.

Of the big tech companies, I've worked at Facebook, Google, & Apple. I've still not quite cracked what's different about Apple culturally that they seem to be more immune to this problem. The only main difference I can spot is I don't recall ever encountering a PM at Apple. To do planning engineers would propose improvements, new features, etc. These were bubbled up. Then executives would be responsible for building…

Yep, I have noticed this about project managers too. I have worked with some amazing project managers, but almost all of them were more hybrid-somethings than purely business-degree folks. Usually designer-PMs or SWE/DS-PMs who drive the vision for the product at large. They make sure everyone in the loop buys into the same idea, is on the same page and stays in sync. However, to do it effectively, the PM must have d…

The key characteristics of a good PM I'd identify are intelligence and memory.

The best PM I ever had the pleasure of working with couldn't code worth a damn. And yet, he could recite details he'd heard from developers 3 weeks ago, and apply the understanding he'd gleaned to current decisions. Furthermore, he had an unvarying nose for bullshit and ability to gently push if developers were trying to make lazy decisions.

Unfortunately, I don't think that's something you can test for or train. Either someone is that type of person, or not.

Re: Red flags I saw while doing technical interviews

#365

Post by username90 »

sobani wrote: post #357
username90 wrote: post #315

Earlier quoted context omitted.

> If companies want to hire experienced senior talent, then streamlining isn't going to be a good idea. They need to recruit them, and that means not alienating them right away. Why would you want to work for a company which has such a hard time recruiting and retaining senior talent that they need to pander to them?

Why would you want to work for a company which has only those desperate-enough-to-jump-through-hoops applying to them?

People who apply to Google aren't desperate.

Re: Red flags I saw while doing technical interviews

#366

Post by danmg »

cellularmitosis wrote: post #343
BeetleB wrote: post #273

Earlier quoted context omitted.

I have to wonder if you know what fizzbuzz is. It's not your typical Leetcode question where you need to know algorithms, etc. It's a lot easier than perhaps the easiest Leetcode problem. Fizzbuzz wasn't designed to test people's prowess in coding. It was designed as "This is one of the simplest possible programs one can write. Can this candidate do it?" While many people may go through their whole career not dealing…

> It was designed as "This is one of the simplest possible programs one can write. Weeellll, I mean it doesn't totally succeed in meeting that design criteria. Fizzbuzz weeds out three kinds of candidates: - candidates who are (currently) unfit for any programming job - candidates who freeze up during the interview - candidates who have never used the mod operator I fault fizzbuzz a bit, because there are candidates…

When I'm interviewing people I'll ask a fizzbuzz level question. Not fizzbuzz itself though. I'll pick something that just has them doing some basic operations with strings and arrays like reversing the words in a string.

I'll give an easy question, but I'll have them do it ssh'd on to a remote machine. I'm more interested if they know how the environment works and how much coaching they need to navigate around.

Re: Red flags I saw while doing technical interviews

#367

Post by Zippogriff »

AshamedCaptain wrote: post #353
Zippogriff wrote: post #242

Earlier quoted context omitted.

I'm 100% sure I've come off in a couple interviews like one of those "phew we dodged a bullet there, guy can't code at all" stories. Meanwhile actually I can and many employers have been very happy with my ability to do so, and I've had a long and reasonably successful career. The problem's not even that I'm bad under pressure, and in fact I've repeatedly been told the exact opposite by people who've worked with me.…

> The problem's not even that I'm bad under pressure, and in fact I've repeatedly been told the exact opposite by people who've worked with me. The problem is specifically about doing a programming performance in front of an audience Sure a "whiteboard interview" basically optimizes for people who can actually pass whiteboard interviews rather than people who can do the job. But to claim that there is a NON-NEGLIGIBL…

I suspect some significant percentage of applicants may not have a disability, exactly, or always totally flub an interview in this way, but may do so often enough that it looks like the level of competence in the industry is much lower than it actually is, if one is taking one's personal experience with interviewees as an accurate measure of that. Add to this that assuredly some of the people confidently complaining about how 90% of their applicants can't write a for loop overlap with the ones generating complaints from applicants that some interviewers are themselves incompetent and asking broken questions (I guarantee you the people doing this think they're great interviewers and getting nothing but signal from their process, and they're probably also likely to exaggerate stories when relating them), then factor in a real tendency to take a 90% OK-to-good signal in interviews and practically forget it happened, taking the 10% bad as more accurate, and I think it's highly plausible the state of things isn't nearly as bad as some believe it is.

Tech interviews are remarkably scattershot in the form they take (outside well-known big companies), and are unusually anxiety-generating, even in the notoriously anxiety-filled field of interviews. Describe what one might (emphasis on might, part of the problem is that it's so often a surprise) expect in a tech interview process to some people outside the industry, and gauge their reactions. I definitely think it's likely they have even worse signal-to-noise ratio than is commonly thought.

[EDIT] Certainly I find it far less plausible that there's an absolute army of people out there, dwarfing the count of actually capable programmers, who are brilliant con-persons but too dumb to figure out that that skill itself is more valuable than programming, outside the top couple percent of programming jobs by comp, and apply it more directly to business roles that actively want it.

Re: Red flags I saw while doing technical interviews

#368

Post by tsukikage »

sumtechguy wrote: post #360
stronglikedan wrote: post #253

Earlier quoted context omitted.

+1 for fizzbuzz. It still amazes me how this simple little test can often weed out a largish portion of candidates early on.

I do not use fizzbuzz but variations that are simple like it. I do not like fizzbuzz for 2 reasons. It relies on a math trick. Modulus math is something everyone can grasp but it is not something everyone knows about. Plus it is easily looked up and gamed. I try to pick something that has a few if conditions and a loop, which is what most people do. Bonus if it can be a 'refactor' style problem for the small walkthro…

One of my goto fizzbuzz-like variations is windowed mean - how would you implement a class with a method accepting and returning a number, such that the number returned is the mean of the last 100 numbers the method was called with.

Some people ask more clarifying questions than others, but in any case a few minutes gets spent on this, we have a laugh and move on with our lives.

Of the failing candidates, around one in three or so spend nearly the entire interview on this or fail to answer entirely because they can't get the maths right.

Is that a "math trick"? It doesn't feel too different to fizzbuzz. It's not complex. It relies on high school maths, and except for very junior positions, for a job where you are expected to solve much more complex problems every day without handholding, even if you can't remember how averages work so I have to hand you the math, not being able to reason through the problem from first principles seems like a pretty big red flag for your problem solving skills to me.

What do people think?

Re: Red flags I saw while doing technical interviews

#369

Post by WealthVsSurvive »

binarytox1n wrote: post #238
cmrdporcupine wrote: post #66

As someone with 20+ years in the experience, red flag #1 for me is being expected to go through a skill-testing technical whiteboard (or similar) coding exercise before even having a deeper discussion about the role and whether there's a fit, etc. I've seen this many times and I find it baffling: I already have a very high paying high quality job, I want you to sell _me_ on the position before demanding I do stressfu…

I'm a hiring manager and I start our technical interviews with coding problems. I have seen too many candidates who can't write code to ever be ok hiring someone who I haven't seen write code with their own hands. I understand that you are highly compensated and may not want to spend time trying out for a new job when you already make so much money, but from my perspective: I have a team of highly compensated individ…

Found the person letting good candidates slip through the cracks. I literally just rescinded my application from a place when given a far too-open as far as choose-your-own-stack take-home assignment. I chose one very, very popular library that had unbeknownst to me, been slightly broken for some time. I fixed the library instead of doing the assignment and submitted an upstream pull. The recruiter's response was something along the lines of: "well, if you're having trouble completing the assignment, maybe you're not a right fit." I verbally handed the recruiter their ass, something more people need to start doing, and walked.

I've also been turned down for telling someone XML wasn't something people needed to really "know" to work with. The stack bias and navel-gazing of recruiters in their vainglorious attempts to prove that what they're doing is useful has reached peak.

Re: Red flags I saw while doing technical interviews

#370

Post by joks »

cellularmitosis wrote: post #348
BeetleB wrote: post #344

Earlier quoted context omitted.

I'm sure there exist jobs where its OK not to know that a mod operator exists, but none of mine were of those kind. I'm pretty sure my experience matches the majority by a pretty large margin. > A fizzbuzz with fewer false-positive rejections might be something like "implement multiplication without using the multiplication operator". While possibly a fair question, this is a whole order of magnitude more difficult t…

> this is a whole order of magnitude more difficult than FizzBuzz Sorry, in my mind the input was restricted to positive integers. My fault for not making that clear. def mul(a, b): accum = 0 while b > 0: accum = accum + a b -= 1 return accum You are correct that accounting for floating point would make this more complicated than fizzbuzz. > But this is precisely the opposite of FizzBuzz. The goal is to weed out horr…

It's even easier to do it with the inclusion of non-integers, though - `prod = a / (1 / b)`

Granted, that may be counter to the spirit of the question, but it's a valid answer lol

Post reply on HN