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

221–230 of 394 posts

Re: Red flags I saw while doing technical interviews

#221

Post by dmoy »

cmrdporcupine wrote: post #149
AshamedCaptain wrote: post #140

Earlier quoted context omitted.

If you really believe so, then I think you are failing to grasp how low "low skill" truly happens to be.

Nope, I think lots of people perform 'low skill' in a whiteboard scenario that are not. And the arrogance of their interviewers gets them on HN making very bold claims about other people's skill levels without consideration for the scenarios involved. Don't get me wrong-- I've worked with very incompetent people. Many of them would have passed a coding interview though.

My whiteboard coding interviews now mostly consist of asking someone to write a for loop with one state variable. That's my bar for low skill. If you can't write 6 lines of code in 45 minutes with one loop and one variable, then you and I are going to have problems working on logic problems on a whiteboard on the actual job.

I've interviewed enough people who don't even know the syntax of a for loop for the language that they chose to use.

As a general matter for how the industry as a whole interviews, I agree though; I am no longer a fan of tricky algorithmic or esoteric data structure questions in whiteboard interviews. The problem I find with other people's interviewing questions is that most people are still asking things that are way too difficult, and they don't end up judging anything other than "Did this person just cram hundreds of hours of algorithms questions?" or "Did this person get lucky and happen to know this type of problem ahead of time?".

For better or for worse, my company schedules me for like >90% system design questions now, which I prefer anyways. Start with a very simple problem and system, and then just throw wrenches.

Re: Red flags I saw while doing technical interviews

#222

Post by mberning »

I do take exception with “no clear direction on where the company is headed”. You have to consider who is interviewing you and the size of the company you are interviewing at. I don’t expect a low level hiring manager inside of a fortune 500 company to give some amazing elevator pitch. If they could they would likely be a C level exec. Everybody knows where companies like P&G or Coca-Cola are headed. The candidate might reasonably assume they intend to keep developing and selling new shampoo and drinks.

Re: Red flags I saw while doing technical interviews

#223

Post by claudeganon »

edanm wrote: post #206
claudeganon wrote: post #188

Earlier quoted context omitted.

It’s completely insane if they’re interviewing 50 people per role. The filtering process is entirely broken if they’re doing that many. The most people I’ve ever interviewed for a job is 7.

Do you have some context around that number? E.g. are you in a large company that pre-filters the pool for you? I ask because 50 is not completely unreasonable. I've had positions where we've had to interview dozens of candidates, in our small company. In larger companies, often someone else does some initial interviews though and that filters out candidates who e.g. can't code at all (sometimes - not always!).

7 was at a large enterprise software company. I don’t remember exactly how many phone screenings they did, but it was less than 20. I still thought it was too many.

Like I said, I think if you have to interview that many, your filtering process is really broken further up the pipeline. You don’t know what you want, what the job really is, the or application process isn’t properly structured.

Interviewing large numbers of people is also a huge liability unless you’re extremely consistent and well-documented in your hiring process (something which I’ve found to rarely be the case).

Re: Red flags I saw while doing technical interviews

#224

Post by TulliusCicero »

cmrdporcupine wrote: post #116
Throysksk282 wrote: post #102

Earlier quoted context omitted.

On the flip side, I've been interviewing people with supposedly 15+ years of experience using simple whiteboard questions for a while and I've seen too many people fail miserably at writing basic for loops (a very slightly more involved problem than fizzbuzz, really) for me to simply trust that spending time selling you on the company is useful. Lying on a resume is easy, and even truthful resumes can be misleading.…

I'd fail fizzbuzz on your whiteboard. And I'd be proud of it. Working in this industry for 25 years and almost 10 at Google has not trained me to write fizzbuzz.

I work at Google, and don't know anyone who'd struggle with Fizzbuzz.

That's an extraordinarily simple coding problem, and the usual ones you have to pass to get into Google are much harder.

Re: Red flags I saw while doing technical interviews

#225

Post by Pokepokalypse »

greyhair wrote: post #141
fragmede wrote: post #70

Earlier quoted context omitted.

The way Apple manages to do this is that, to a larger degree than others , the company is run as a collection of different companies. This has pros AND cons but one of the pros in this context is that their hiring is less "work at Apple", and more "work for THIS team at Apple". Hands-down unbeatable for the specific question of role clarity, but it's naive to pretend there aren't downsides to the practice.

This is how Bell Labs was back prior to divestiture, up until the mid 1990s. There really wasn't one huge Bell Labs, there were literally hundreds of hundred person teams run as if they were little companies, but with a huge bureaucracy providing funding, guidance, and all sharing a knowledge pool. If you changed teams, you could find a completely different team culture using completely different tools. And like biol…

similar to SRI currently as well.

Re: Red flags I saw while doing technical interviews

#226

Post by aYsY4dDQ2NrcNzA »

fragmede wrote: post #70
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…

The way Apple manages to do this is that, to a larger degree than others , the company is run as a collection of different companies. This has pros AND cons but one of the pros in this context is that their hiring is less "work at Apple", and more "work for THIS team at Apple". Hands-down unbeatable for the specific question of role clarity, but it's naive to pretend there aren't downsides to the practice.

I’d say Apple is structured substantially less like a bunch of different companies compared to one which is explicitly split into separate SBUs.

Re: Red flags I saw while doing technical interviews

#227

Post by twinkletwinkle_ »

user5994461 wrote: post #218
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…

That's the first thing I thought reading your sentence, cron cannot do seconds granularity (I think the lowest was 1 hour on the last OS I was working with). Why would you ask questions which you know are impossible? That's setting up the candidate to fail.

It's not "impossible", just not natively obvious. The solution I remember using is

    0 * * * * foo()
    0 * * * * sleep 30; foo()
It's not the prettiest but is a reasonable imitation of a 30 second cron.

Re: Red flags I saw while doing technical interviews

#228

Post by claudeganon »

TulliusCicero wrote: post #214
claudeganon wrote: post #188

Earlier quoted context omitted.

It’s completely insane if they’re interviewing 50 people per role. The filtering process is entirely broken if they’re doing that many. The most people I’ve ever interviewed for a job is 7.

It's possible they're including phone screens/interviews there, not 50 total on-site interviews.

If it was 50 phone screenings, that’s still way too many for a single role. Everywhere I’ve worked, it’s been narrowed down to maybe 10 calls and 3-5 candidates. I can’t imagine who has the time to waste on 50 calls to candidates.

Re: Red flags I saw while doing technical interviews

#229

Post by grumple »

edanm wrote: post #209
cmrdporcupine wrote: post #149

Earlier quoted context omitted.

Nope, I think lots of people perform 'low skill' in a whiteboard scenario that are not. And the arrogance of their interviewers gets them on HN making very bold claims about other people's skill levels without consideration for the scenarios involved. Don't get me wrong-- I've worked with very incompetent people. Many of them would have passed a coding interview though.

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 bad. Let the candidate code alone without you watching. Give them internet access. Come back in an hour or two, or let them do it remotely or as a take home. This is more like our real jobs; and gets rid of cutesy "do you know this algorithm?" questions, which many whiteboarding problems are. Instead of going for pure data structure / dp / search / sort algorithms, have them implement things like business rules.

Re: Red flags I saw while doing technical interviews

#230

Post by IggleSniggle »

president wrote: post #9

These red flags are the norm in the last decade that I have been interviewing in SV. Issue is that everybody is in the game to further themselves first and foremost rather than helping the company or the candidate. I have talked to many colleagues and managers who are only looking for people that can be "used" to get them promoted and this mindset shapes how they interview candidates.

I am a career switcher who did code "for fun" and only figured out that I would like my life more if I did it as my job in my 30s. Somehow, I had built my life around the assumption that your job had to be "hard" as in "you need to constantly force yourself to do the work" as some kind of masochistic virtue, and it took me that long to realize that I could actually enjoy my work AND get paid well for it if I just did what I loved (software).

Anyway, to your comment: there are people like this everywhere, in all industries. The more money there is involved in a domain, the more you will find people that are only in that domain for the money. Doesn't mean those people wont have legit skills that can be utilized, but there are some downsides as you note.

Post reply on HN