Ten years of experience, still failing phone screens • Hacker News Board

Re: Ten years of experience, still failing phone screens

#191

Post by drclau » Sat, Dec 11, 2021, 2:32 PM UTC

kstenerud wrote: post #130

It's important to remember that it's also YOU interviewing THEM. The coding interview is an opportunity to get to know the company culture in a very feet-on-the-ground fashion. How the interviewer behaves and how they expect you to do things reflects upon them as managers, mentors, and in general people you'll be working with for potentially a long time. - If they're forcing you to go against your natural flow, that'…

> It's important to remember that it's also YOU interviewing THEM.

I agree with what you said in the rest of the comment, but I'd like to go one step further with the idea of "YOU interviewing THEM". Let's add some symmetry!

Let's make the interview double the usual time, and half of it I get to ask the other side to solve LC problems that I pick at random, or design systems I made up the day before, or behavioural questions about their past experiences. According to companies, that is the only way to assess if a person is good enough for the job, so I'd like to use the same method to find out if I want to work there.

Re: Ten years of experience, still failing phone screens

#192

Post by codingdave » Sat, Dec 11, 2021, 2:33 PM UTC

> In theory a phone screen is supposed to evaluate whether a) this person would be good at the job being hired for and b) whether it's worth investing another five hours in trying to hire this person.

They also screen whether or not you communicate well, your motivations for looking for work and whether that matches the role and future growth of the role, whether there are any logistical or compensation-based blockers to the role...

Frankly, getting all the deal-killers out of the way is the point of the phone screen. Figuring out whether you can actually do the job, and do it well, is for later phases of the interviews.

I feel like the hiring process is often misunderstood. The first screen is one of two things - if you are working with a company directly, it is just a screening for deal-killers. If you are working with an outside recruiter, it is them trying to understand you to know how to market you to the hiring manager.

In either situation, though, if they are getting into remote coding of algorithms on an initial phone screen, something is really off in their hiring process.

Re: Ten years of experience, still failing phone screens

#193

Post by [deleted] » Sat, Dec 11, 2021, 2:33 PM UTC

ericbarrett wrote: post #21

thr0wawayf00 wrote: post #6

One thing I realized recently while interviewing candidates at my company is that it’s one of the few opportunities that individual contributors like myself have to exert significant power over someone else, and not everyone is prepared to handle it well. Recently, we had a candidate come through that wasn’t a good fit for us (he claimed to be a cypress expert so we asked him to set cypress up in a dummy react repo a…

I still recall an interview I did at a recently public company in New York, for a DevOps position. 4/5 of the interviews went sailingly, with heavy emphasis on networking, scripting, and AWS knowledge. Then the lead engineer sailed in, five minutes late. He gave me an algorithm question straight from the Google playbook (I don't remember the question, sadly), then after I asked for a few minutes to ponder, proceeded…

[deleted]

Re: Ten years of experience, still failing phone screens

#194

Post by aigo » Sat, Dec 11, 2021, 2:34 PM UTC

ericbarrett wrote: post #21

thr0wawayf00 wrote: post #6

One thing I realized recently while interviewing candidates at my company is that it’s one of the few opportunities that individual contributors like myself have to exert significant power over someone else, and not everyone is prepared to handle it well. Recently, we had a candidate come through that wasn’t a good fit for us (he claimed to be a cypress expert so we asked him to set cypress up in a dummy react repo a…

I still recall an interview I did at a recently public company in New York, for a DevOps position. 4/5 of the interviews went sailingly, with heavy emphasis on networking, scripting, and AWS knowledge. Then the lead engineer sailed in, five minutes late. He gave me an algorithm question straight from the Google playbook (I don't remember the question, sadly), then after I asked for a few minutes to ponder, proceeded…

> chatting on his phone with the audible keybord ticks enabled.

That alone is a disgrace.

Re: Ten years of experience, still failing phone screens

#195

Post by zcw100 » Sat, Dec 11, 2021, 2:34 PM UTC

kstenerud wrote: post #130

It's important to remember that it's also YOU interviewing THEM. The coding interview is an opportunity to get to know the company culture in a very feet-on-the-ground fashion. How the interviewer behaves and how they expect you to do things reflects upon them as managers, mentors, and in general people you'll be working with for potentially a long time. - If they're forcing you to go against your natural flow, that'…

I've always thought it would be fun do say, "Ok, this sounds like a fun game. It's only fair that if you get to ask me a question I get to ask you one." I'd be willing to bet 90% of the interviewers would crumble on the first question. I've noticed that most of the interviewers not only select their questions ahead of time but also have to do research so they are sure they know the answers too.

Re: Ten years of experience, still failing phone screens

#196

Post by sdiupIGPWEfh » Sat, Dec 11, 2021, 2:34 PM UTC

bsder wrote: post #134

ljhsiung wrote: post #74

Earlier quoted context omitted.

I recall voicing an opinion that we should record interviews we give candidates and re-review it during the hiring committee, much like we do code reviews. Have the interviewer justify certain beliefs about the candidate with hard timestamps rather than platitudes ("not confident", "wanted to see how they react under pressure", etc. etc.). My comment always gets pushback. Privacy, respect for interviewer ("If I work…

I don't agree with recorded video, but I am now convinced that there should always be an random "observer" (interviewer does not get to pick) who does nothing but watch and take notes along with an interviewer. You can give whatever excuse you want "Adding a new person to the loops," "normalizing the loop level," whatever. But I am now convinced that interviewers cannot be trusted alone with candidates anymore. Maybe…

Isn't interviewing in pairs fairly common? When being interviewed, there's always been two people across from me for the technical rounds; anything 1-on-1 is limited to initial phone screens and final rounds with the bigwigs. When conducting interviews, I've always been one of two, with the exception of one time when no one else was available to join me, which I'd prefer not to repeat.

I would go so far as to say a random passive observer is still a great idea in addition to two active interviewers.

Re: Ten years of experience, still failing phone screens

#197

Post by wiseowise » Sat, Dec 11, 2021, 2:38 PM UTC

disgruntledphd2 wrote: post #171

wiseowise wrote: post #99

Earlier quoted context omitted.

Definitely much more subjective than algorithm interview.

It feels like the other way round to me, can you clarify why you think that a multiple choice questionnaire is more subjective than an algorithmic interview?

> I could absolutely see people complaining about multiple choice questions and how you're more likely to get tripped up by minor mistakes.

Re: Ten years of experience, still failing phone screens

#198

Post by nitrogen » Sat, Dec 11, 2021, 2:38 PM UTC

wiseowise wrote: post #98

tharkun__ wrote: post #49

Earlier quoted context omitted.

What are they interviewing for, low level disk experts? While I agree that "disk" stuff is "low level" compared to a web developer, it's definitely a very relevant question. You might ask it and if the candidate is interviewing for a web developer position rephrase it after getting a blank stare: Why is it bad retrieving 50 users from a REST endpoint like `/api/users/{id}`, one at a time? Oh sure, print-based debuggi…

> Sounds perfectly reasonable to me. Sounds like a mental gymnastics to me.

It's perfectly reasonable to expect a developer to be able to recognize patterns and repeat them.

Re: Ten years of experience, still failing phone screens

#199

Post by ghaff » Sat, Dec 11, 2021, 2:41 PM UTC

aigo wrote: post #194

ericbarrett wrote: post #21

Earlier quoted context omitted.

I still recall an interview I did at a recently public company in New York, for a DevOps position. 4/5 of the interviews went sailingly, with heavy emphasis on networking, scripting, and AWS knowledge. Then the lead engineer sailed in, five minutes late. He gave me an algorithm question straight from the Google playbook (I don't remember the question, sadly), then after I asked for a few minutes to ponder, proceeded…

> chatting on his phone with the audible keybord ticks enabled. That alone is a disgrace.

Please go off in a corner and ponder why such casual ageism is as unwelcome as casual racism or sexism and maybe just stay there until you come up with an answer.

Substitute woman for boomer in that sentence and listen to what it sounds like.

Re: Ten years of experience, still failing phone screens

#200

Post by saxonww » Sat, Dec 11, 2021, 2:45 PM UTC

I read about three paragraphs in and then stopped.

Coderpad tests where you're encouraged not to write tests, can't hit the run button, and can't use reference material? Worthless. Most people - not just the author - are going to fail those, and they are not representative of the work environment, so what's the point?

We use Coderpad for one of the 3 interviews we give candidates. We do a tech screen first, then the coderpad, then a panel interview; the author is right in that it's about a 5-6 hour process overall (for the candidate). The coderpad is as much about watching how you go about solving a problem as it is you getting the right answer, although that certainly counts. We want to see if you pay attention to the question and implement what we asked for (not brain teaser 'gotcha!' stuff, simple stuff like "write a function that does ... and returns a boolean" - a lot of people will have their function print an answer and return nothing, or won't write a function at all, or will ignore other key requirements), that you can explain your approach, that you can think of some test cases, and that you can accept help/coaching if you're clearly stuck. We want people to do it in a language they are comfortable with, and looking up syntax is OK.

Overall I'm not sure how much value we get out of coderpad. It's manufactured pressure, just like a whiteboard exercise in an in-person interview. You can tell candidates what I wrote above, and try to convince them that it's not about getting the right answer as much as how you get at the answer, but that doesn't really work. Some people are not going to do well in those interviews regardless of their ability.