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

231–240 of 394 posts

Re: Red flags I saw while doing technical interviews

#231

Post by thaumasiotes »

Zippogriff wrote: post #203
megiddo wrote: post #84

Earlier quoted context omitted.

I'm with you on this. 20+ years. My usual MO is to walk away from interviews that have jump-scare whiteboarding or require a quiz prior to an actual interview. I recently broke my own code at an interview and was rewarded with complete nonsense. Never again.

My new rule after my last job search is that I don't interview if I don't know enough about the interview process to be more than 50% certain I'll come off OK in it. Not that I'll get the job, but more than 50% certain I'll at least look alright. The FAANGs practically (sometimes, actually) give you a study guide, at least. Lots of smaller places act like knowing anything more than the names and titles of the people…

> The FAANGs practically (sometimes, actually) give you a study guide, at least.

The study guide is hundreds (thousands?) of pages. How is that helpful?

Re: Red flags I saw while doing technical interviews

#232

Post by user5994461 »

xtracto wrote: post #185

> Your interviewer is only open to solving the problem ONE way Haha, I've happily been in the "interviewer" side of this two times: One time, as part of a DevOps interview I asked the candidate to run something in a POSIX OS every 15 seconds using a cronjob (that was the general idea). Crontab granularity is only in minutes, so you have to use your head or Google to get a Cronjob answer. The interviewee however told…

For reference, that init.d solution is extremely dangerous, speaking from experience ;)

init scripts are run sequentially, each init scripts MUST terminate quickly AND leave no child process, otherwise the init sequence is frozen.

If there is a while() loop in an init script, it will freeze the init sequence. If an init script starts another program without daemonizing, it will freeze the init sequence.

High chances are that you missed either or both of that in the solution. The init script will work fine while you test locally in the shell but it will blow up startup on the next reboot.

Re: Red flags I saw while doing technical interviews

#233

Post by renewiltord »

Galanwe wrote: post #107
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…

After being on both sides of the interview situation for quite a while now, my feeling on this is more nuanced. The thing is, when you look for a job, you will often go for 5 to 10 interviews. On the other end, when I'm looking for someone to fill a position in my team, I will interview at the very least 50 candidates. That is to say, all things equal, the interviewer has most likely more incentive than the interview…

Here's the funny thing. I've worked with recruiters where the candidates they supplied needed the tech screen upfront and recruiters where the sell call upfront was useful.

Honestly, the latter guys are absolutely fire to work with. I think recruiting is like security engineering: 90% of the guys doing it are total rubbish so you just assume that's what it's like. But that last 10% are super good, and the top 1% are really freaking good.

I remember when I first encountered a recruiting pipeline put together by a guy who was good at it. Literally every person I spoke to was a good engineer. We did tech-screen them, but only after the initial call where we talked to them about their interests and our company objectives.

Literally every one of these engineers knew:

* What sorts of problems they wanted to work on

* What stage of company they wanted to work at (seed, series-A, ..., big established company)

* What risk they were willing to take

* What sort of team they wanted to work on

This may not be scalable at Google/FB where you're hiring commodity L3-L5s a lot.

Anyway, I was very impressed. Also, the fact that almost every one of them didn't bat an eye at the tech screen. You read some of the comments on HN/Reddit and you see that these guys are a cut above the standard dudes.

Like, just the social nous. Way off the charts. On HN, people talk about an interviewer mis-sizing the problem: "Haha, so I told him I'd do it on a single SGI UV 300 with 3 TB of RAM. The interviewer got stuck. I got him.". These guys are like way better. If you mis-size, they'll just be like "Ah, okay, so you can get this done on a single machine these days, they have a lot of RAM, but that's trivial. AWS has the u24s for 24 TB or something. So let's say the problem is even bigger or that we want the other advantages of clusters" and they'll take it away. No chip on the shoulder. No insecurity. If some constraint doesn't make sense, they'll say "Okay, if we were doing this in prod, I'd push back on that, but let's say it's the case" and just go on.

We didn't convert everyone - not everyone wants to work in our domain or wants to deal with the quirks of our team or whatever, but that's life. It was way more enjoyable as an interviewer.

Re: Red flags I saw while doing technical interviews

#234

Post by TulliusCicero »

noodle wrote: post #165
vkou wrote: post #113

Earlier quoted context omitted.

That's because FAANG has a hiring department, that's responsible for hiring. They also each have ~2,000 engineering teams, some of which may or may not have headcount. And once someone is accepted, teams with open headcount look at that person, and make an offer. The shortens the time that it takes to fill headcount, because there is a constant pipeline of ready candidates. This also means that you won't get yanked a…

Sure. I mean, I get the reasoning/justification behind it. But I'm generally not interested in jumping through all of the toxic tech interview process hoops without first knowing what's at the other side; I've learned that lesson the hard way. And I think that probably filters a certain type of talent away from FAANG companies.

I work at Google, and it's definitely true that when you're interviewing here, you should be thinking more about the company than a specific team. I mean, ultimately specific teams matter, but transferring is generally pretty easy here, not to mention common.

Re: Red flags I saw while doing technical interviews

#236

Post by Pokepokalypse »

Wohlf wrote: post #200
hrktb wrote: post #92

Earlier quoted context omitted.

It can be great if you have things you want to do that most companies don’t come up by themselves. Basically if you’re in a “Shut up and hire me!” mode and will self-manage and come up with what others also need to do. I find it tiring, but some people thrive in these roles.

I enjoy this, the problem is often that key people don't actually want to change, or the core issue is somehow intractable.

Story of my entire 25 year career, right there.

That said; I've tended to look for small companies, or companies that are in startup mode, where roles do not seem very rigid, and boundaries between teams are not so impenetrable.

I tend to be miserable where roles are rigid, or the culture does not encourage cross-fertilization between teams.

Re: Red flags I saw while doing technical interviews

#237

Post by edanm »

grumple wrote: post #229
edanm wrote: post #209

Earlier quoted context omitted.

I don't know how many people saying otherwise would constitute sufficient evidence in your mind, but add me to the list of people that disagree with this sentiment. I've had candidates who couldn't code a loop. Not "did something suboptimal", I mean literally couldn't write a single line of code. I've had candidates who seemed incredibly accomplished when talking them, who showed amazing looking demos and could talk…

I've frozen in interviews and been unable to think on simple problems just due to anxiety (which I've never experienced at work; if I can't think, I just say, "let me think about it" and I get back to the person in a bit). Other interviews I've completely demolished - solving problems that were supposed to take 30 minutes in 2 minutes, for example. I think the type of problem and structure we use for interviews is ba…

I wholeheartedly agree. Note that my second example was exactly that type of interview - we leave the candidate to code alone, technically sometimes in the same room as us but sometimes in a separate room, but either way with only a few "check ins" every 15-45 minutes depending on how things go. They have internet access, a base file and console session open that can run the file, and an editor already set up (not necessarily their editor of choice, though we've had people install an editor at the start of this process).

In this scenario, having someone literally be unable, in 2 hours, to replicate the first example code of some library, when they have access to almost identical code in the docs, is a pretty good filter.

Re: Red flags I saw while doing technical interviews

#238

Post by binarytox1n »

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 individuals who are evaluating a candidate for potential hire and I don't want to waste all of their time if the candidate can't even write a simple algorithm to rearrange the characters in a string.

Since it sounds like you're pretty happy where you're at you have the freedom to choose to participate or not. I am guessing that the only way to pull away a candidate like you is by referral anyway, so I am guessing there's not actually a problem here.

If I am getting someone via referral, then interviews can focus on what you find valuable - I can sell you on the role, I can ask you personality questions and make sure there is goal alignment. If I have someone to vouch for you. If you're a stranger? You better believe you gotta write some code.

I think that if you take a step back and ask yourself if you'd really like to work at a place where they hire people who they haven't seen code, you'd probably rather choose to just write some code for 30 minutes in an interview.

Re: Red flags I saw while doing technical interviews

#239

Post by jrochkind1 »

eertami wrote: post #100
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…

> I've still not quite cracked what's different about Apple culturally that they seem to be more immune to this problem. ... Really? I do not get that impression at all after Catalina and Big Sur. Every release these days seems to have more problems than the last. I'll put up with macOS until High Sierra is unsupported and then I'm done. As an Apple employee commented here last year, "I am awed by the fact that we ma…

I'm not sure you're talking about the same "this problem" as the thread you are replying to.

Re: Red flags I saw while doing technical interviews

#240

Post by mcguire »

"Not enough clarity about your role"

:-) Back when I interviewed at Google, this was their signature. If they made you an offer, it could be to work on any team, anywhere. Their choice.

"Consistent lack of interest or low morale from interviewers"

And this is why I never got a research job. Telcordia Research, 2004. The only group actually hiring was really doing product development. Everybody else left in the big, empty building were the people who hadn't already escaped.

Post reply on HN