Red flags I saw while doing technical interviews • Hacker News Board

Re: Red flags I saw while doing technical interviews

#271

Post by ryandrake » Tue, Sep 15, 2020, 7:55 PM UTC

greyhair wrote: post #150

StillBored wrote: post #23

Role clarity is a huge one in my book. I've turned down numerous offers because when I asked what the specifics of my day to day job were going to be, the answers weren't clear. From the secret FAANG that likes to pretend what they are doing is defense contractor level top secret, and even after your hired you might not know what your actually working on, to the big companies where its clear the hiring manager only h…

The empire building thing is the worst. "We don't actually have anything for you to do, we just have funding for three more people, and we need to hire people for those slots or we'll lose our funding. And our team size is in the second quintile for headcount, so we need to grow a little." So basically hiring bench warmers. I actually encountered that once in my so far 37 years. It was a total wtf moment for me.

The only place I actually encountered this was at a defense contractor where if you did not have clearance, and they didn't happen to have uncleared work ready to staff, then if they wanted to hire you, they'd have to have you do nothing for 6 months while your clearance went through. All other companies I've worked at (including FAANGs) have always had 3-10X more unstaffed work than they could possibly do with their current staff and always had something for new people to onboard into. We'd be constantly giving leadership the bad news: "We'd love to do projects A-G, but only have enough people to do A, B and maybe C."

Re: Red flags I saw while doing technical interviews

#272

Post by cmrdporcupine » Tue, Sep 15, 2020, 7:57 PM UTC

TulliusCicero wrote: post #224

cmrdporcupine wrote: post #116

Earlier quoted context omitted.

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.

I never said I'd struggle with fizzbuzz. I said I'd struggle with fizzbuzz on _his_ whiteboard. Because it would give me anxiety to do it there in front of him, and it's not how I code or think. And this is a person who created a throwaway account on HN just to get into an argument, so I can imagine how the experience would be.

Getting the job @ Google was worth that stress. The original comment I made was to the effect of: before you dump a coding test on me, you better make sure it's worth the stress by convincing me why.

Re: Red flags I saw while doing technical interviews

#273

Post by BeetleB » Tue, Sep 15, 2020, 8:01 PM UTC

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 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 with dynamic programming or most data structures, almost all programming is fairly similar to FizzBuzz.

As an analogy, it's like giving someone who claims to be a circuit designer a basic circuit where he's failing at Ohm's Laws or Kirchoff's Theorems. Or an electromagnetics person who cannot integrate a basic polynomial.

If you have test anxiety that's one thing, but if your reason is "I need time to think this through", it's a huge red flag. Kind of like the person saying he needs to consult a table of integrals to integrate x^2.

I'm against intense Facebook/Google style whiteboarding. Fizzbuzz is at the extreme other end of intensity.

Re: Red flags I saw while doing technical interviews

#274

Post by nickff » Tue, Sep 15, 2020, 8:01 PM UTC

pnw_hazor wrote: post #254

nickff wrote: post #220

Earlier quoted context omitted.

First, I don't care whether it's illegal; lying to people is wrong. Second, the definitions for fraud vary from jurisdiction to jurisdiction, but the course of action recommended here falls under the common definition of civil fraud: >"Somebody misrepresents a material fact in order to obtain action or forbearance by another person; >"The other person relies upon the misrepresentation; and >"The other person suffers…

It is not a lie to accept a later offered better deal. The better offer might never come through. Would you really begrudge someone who left for an opportunity that is better for them? You are mixing up loyalty with persons with loyalty to companies. The former is important the latter is foolhardy.

What would you think if a company regularly retracted offers upon finding better candidates? Opposite side of the same coin.

Re: Red flags I saw while doing technical interviews

#275

Post by nickff » Tue, Sep 15, 2020, 8:03 PM UTC

user5994461 wrote: post #251

nickff wrote: post #220

Earlier quoted context omitted.

First, I don't care whether it's illegal; lying to people is wrong. Second, the definitions for fraud vary from jurisdiction to jurisdiction, but the course of action recommended here falls under the common definition of civil fraud: >"Somebody misrepresents a material fact in order to obtain action or forbearance by another person; >"The other person relies upon the misrepresentation; and >"The other person suffers…

Economic duress is recognized as duress. That the candidate is rejected from the job if too slow, having no job and no income to eat is quite a strong duress. Obviously there would be extra context in practice, whether the candidate has a job, has already resigned, etc... The typical HN commenter in SF already working at FAANG might not be an ideal scenario ^^ Anyway, there's no fraud or misrepresentation, as long as…

Agreeing to provide a service on a specific date, then offering the same service to others, and withdrawing from the first agreement upon receipt of a better offer is wrong. You might not agree with that, but it's how I see things. What would you think if the companies and individuals you interacted with were constantly backing out of signed deals?

Re: Red flags I saw while doing technical interviews

#276

Post by mavelikara » Tue, Sep 15, 2020, 8:05 PM UTC

StillBored wrote: post #23

Role clarity is a huge one in my book. I've turned down numerous offers because when I asked what the specifics of my day to day job were going to be, the answers weren't clear. From the secret FAANG that likes to pretend what they are doing is defense contractor level top secret, and even after your hired you might not know what your actually working on, to the big companies where its clear the hiring manager only h…

What are good answers to your question that you have heard from hiring managers?

Re: Red flags I saw while doing technical interviews

#277

Post by cmrdporcupine » Tue, Sep 15, 2020, 8:05 PM UTC

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…

You have set up a strawman -- I didn't say go hire people who haven't seen code, I didn't even say don't do skill testing questions. The question is: at what point in the interview process do you start dumping skill testing questions at them? And I think as the first gate to pass, this is just awful.

Further there's also a question of what kinds of questions, and how the question is asked, but that is a separate topic.

In any case, as a tangent: Most of the questions asked in these interviews have little to do with the day to day tasks of software engineers. So I'm not sure they give much insight into the performance of software engineers doing software engineering. But they do give preference to the skills obtained in CS algorithms courses, so there is an intrinsic bias towards hiring new grads.

Re: Red flags I saw while doing technical interviews

#278

Post by ryandrake » Tue, Sep 15, 2020, 8:06 PM UTC

song wrote: post #197

NationalPark wrote: post #182

Earlier quoted context omitted.

I felt this way too until I was made to start giving interviews. However low a bar you're imagining, I assure you I've seen "strong on paper" candidates who failed to meet a lower one. I don't know if people are lying, or people cheated through school, or talked other people into doing their work at the jobs they claim to have had, but it's really astonishing how unable to write code they can be. However, the particu…

I was going to write a similar comment when I saw yours. We've recently hired someone who was great on paper, was adept at talking about software/programming and was able to present some code he allegedly wrote and explain it. He seemed like a great fit based on the discussions but we hadn't actually given him a whiteboard interview. Once he joined the company he proceeded to actually be completely unable to write a…

I am constantly surprised at how many Brillant Paula Bean [1] developers are out there successfully interviewing, getting hired and BS-ing their way through jobs. I've always wondered if this is as prevalent in other industries outside of software.

1: https://thedailywtf.com/articles/The_Brillant_Paula_Bean

Re: Red flags I saw while doing technical interviews

#279

Post by cmrdporcupine » Tue, Sep 15, 2020, 8:08 PM UTC

BeetleB wrote: post #273

cmrdporcupine wrote: post #116

Earlier quoted context omitted.

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

Fair enough, I was being inflammatory in my response. I would not fail fizzbuzz.

But I'd probably want to, just to piss off this person (the throwaway account who came on here to argue...)

Re: Red flags I saw while doing technical interviews

#280

Post by binarytox1n » Tue, Sep 15, 2020, 8:08 PM UTC

cmrdporcupine wrote: post #277

binarytox1n wrote: post #238

Earlier quoted context omitted.

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…

You have set up a strawman -- I didn't say go hire people who haven't seen code, I didn't even say don't do skill testing questions. The question is: at what point in the interview process do you start dumping skill testing questions at them? And I think as the first gate to pass, this is just awful. Further there's also a question of what kinds of questions, and how the question is asked, but that is a separate topi…

I did address your question - I ask them to write code first. It may waste your time, but it saves time for my team. You can't code? Ok, the interview is over. Thanks for your time.

There's lots of debate on what kind of coding questions to ask. My questions are more fizz-buzz and less CS textbook. You'd be amazed how many people apply for senior level software engineer roles who can't demonstrate basic programming skills.