Live data from Hacker News

Red flags I saw while doing technical interviews

blog.interviewing.io

131–140 of 394 posts

Re: Red flags I saw while doing technical interviews

#131
post #10

Earlier quoted context omitted.

On the other hand, there often needs to be a time limit, or else they will be too late to make an offer to the runner-up (when the leader turns it down). I am not sure what a 'reasonable period' is.

Long enough for you to wrap up your other interviews. I think the biggest issue is when the time limit isn’t moveable. If you’re finishing up interviews next week and the time limit cannot be moved, then that is a problem. Inflexibility from the get-go is a bad way to start a working relationship.

You can always accept the time critical offer and continue interviewing and then jump if a better one comes through.

There is no reason to be nice or considerate to companies, they will drop you in hot second if it is convenient for them.

Re: Red flags I saw while doing technical interviews

#132

I generally agree with the points, but have a few places of disagreement: > Your interviewer is only open to solving the problem ONE way If this is someone you'll be working closely with, it's a yellow flag, but the common complaint you read here about algorithmic interviews not being the best way to evaluate someone for a job, this really just tells you how good this person is at either that problem or interviewing.…

If the interviewer has no flexibility in understanding algorithmic solutions, it means they accept that applicants spend a month or more exercising whiteboard riddles while the interviewer just compares the solution with existing notes. I think there is a valid case for whiteboard interviews, especially when the company needs to optimize code a lot.

Re: Red flags I saw while doing technical interviews

#133
post #117

Earlier quoted context omitted.

Part of that is because of the expectation at Google that you will just move around. You don't really hire specifically into a given team, and that could be disconcerting, for sure. But you are also given enough respect by the company to assume that as a competent SWE you should be able to move around fairly easily to almost any team in the company. When I started (9 years ago) it was stated during onboarding that yo…

Doesn't that put off a lot of very high-quality candidates though? If someone joins because they want to work in an interesting machine learning team, they probably don't want to be potentially moved on to a legacy Java CRUD app. Or is transferring determined more by what the employee wants?

Employees usually get to ask where to go next, and the expectation is generally that you spend at least a year in a position.

But I seriously doubt anyone who wants to do ML is going to sit through a year on the java team on the off chance that they could move to an ML position in a year.

Re: Red flags I saw while doing technical interviews

#135

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.

Which part of fizzbuzz would be an issue for you?

Re: Red flags I saw while doing technical interviews

#136
post #108

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…

"But! But! Our 24yo interviewer has gotta check if you know the _fundamentals_ ... You might have been coasting for 20 years." Agreed, I'm totally confused and put off by this as well.

A lot of people do in fact manage to coast for 20 years.

Re: Red flags I saw while doing technical interviews

#137

Earlier quoted context omitted.

A reasonable period is: You tell them up front your ideal timeline, that you have a couple of other irons in the fire (if you do), and you keep them informed of the progress of those other fires. And they do the same for you. Maybe you can't get a timing that works for both sides together, but that is OK. The pressuring is what isn't.

I've been the recruiter in this position. I think it is unethical to string your runners-up along in this situation. You're essentially taking up their (and your) valuable time with little chance at success. Exploding offers are the least bad solution. Give them 48-72 hours, with a small extension if they are currently talking to someone else.

[deleted]

Re: Red flags I saw while doing technical interviews

#138

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…

Just to offer a different perspective: An employer having too clear of an idea of a role can also be a red flag.

The past 10 years I've often been the first employee - or one of the first - joining or building up the company's security organization. The combination of (1) having a specialist skill and (2) being around very few other people with the same skill, naturally leads to a situation where too much clarity can be a bad thing. If a non-specialist define a security role, they will probably screw it up. And that's okay.

If you've worked in startups long enough you eventually get a lot of experience in how to hire people whose expertise you do not understand. As an employer and employee I enjoy the collaborative process of defining the role around the candidates strengths and weaknesses.

Re: Red flags I saw while doing technical interviews

#139

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 find it kind of shocking that you are a senior engineer at Google and are unable to write fizzbuzz.

Every senior engineer I've worked with including myself is able to write a for loop with a few lines of code in the body, because doing basic coding like this is important when training new grads and doing code review (not to mention when writing your own code).

Re: Red flags I saw while doing technical interviews

#140

Earlier quoted context omitted.

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…

Honestly, I question most interviewers ability to evaluate someone as low or high skill. I honestly don't think the testing works most of the time.

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