Earlier quoted context omitted.
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 s…
It's also super awkward to talk to someone and get a real good understanding of their experience, how they fit, what they've done, what they'd want to do.... and then find out they can't code. And this does happen. It's much nicer for all involved to do that early in the process and write it off as a formality because it's a humiliation to throw that at someone at the last minute. It's an insulting waste of time for…
Red flags I saw while doing technical interviews
341–350 of 394 posts
Re: Red flags I saw while doing technical interviews
#342Some companies who did feel strict during the interviews actually were really good companies.
The opposite is true, I interviewed a company that seemed open minded and fun.
The interview in appearance was quite enjoyable, but with huge red flags. The CTO was always talking (super fast) and just wouldn't let me speak. I could ask only one question (during 1h) and was rudely interrupted in the end because he had no more time.
The CTO also said something like "If you join this company you will work with very competent engineers, smarter than you". To which I humorously answered while defending my pride, but probably ended up looking like someone full of himself.
Clearly this is not someone I would enjoy working with on a daily basis.
Re: Red flags I saw while doing technical interviews
#343Earlier 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…
Weeellll, I mean it doesn't totally succeed in meeting that design criteria. Fizzbuzz weeds out three kinds of candidates:
- candidates who are (currently) unfit for any programming job
- candidates who freeze up during the interview
- candidates who have never used the mod operator
I fault fizzbuzz a bit, because there are candidates in that last category who have several years of experience successfully duct-taping together libraries to meet product requirements, yet panic because they've never had to find the remainder of division in their language of choice. They might be fine for the rec you have open.A fizzbuzz with fewer false-positive rejections might be something like "implement multiplication without using the multiplication operator".
edit: Oooh! "How many ways can you implement multiplication" would be a much more interesting warm-up/weed-out question! Allows the quality candidates lots of room to shine.
Re: Red flags I saw while doing technical interviews
#344Earlier quoted context omitted.
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…
> It was designed as "This is one of the simplest possible programs one can write. Weeellll, I mean it doesn't totally succeed in meeting that design criteria. Fizzbuzz weeds out three kinds of candidates: - candidates who are (currently) unfit for any programming job - candidates who freeze up during the interview - candidates who have never used the mod operator I fault fizzbuzz a bit, because there are candidates…
> A fizzbuzz with fewer false-positive rejections might be something like "implement multiplication without using the multiplication operator".
While possibly a fair question, this is a whole order of magnitude more difficult than FizzBuzz. It requires more domain knowledge as well (lots of people have forgotten how to multiply).
> Allows the quality candidates lots of room to shine.
But this is precisely the opposite of FizzBuzz. The goal is to weed out horrible candidates, not identify great ones.
Re: Red flags I saw while doing technical interviews
#345Earlier quoted context omitted.
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…
> It was designed as "This is one of the simplest possible programs one can write. Weeellll, I mean it doesn't totally succeed in meeting that design criteria. Fizzbuzz weeds out three kinds of candidates: - candidates who are (currently) unfit for any programming job - candidates who freeze up during the interview - candidates who have never used the mod operator I fault fizzbuzz a bit, because there are candidates…
Re: Red flags I saw while doing technical interviews
#346As 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…
Let me clarify first that 50 interviews include phone screening, where we don't do specific technical questions but rather just poke around what the candidate is looking for and whether they seem able to explain what they have been doing without drowning.
As for the process we use, we are a hedge fund of 30 people, we have no HR, so I directly deal with head hunters. That means the numbers I gave are "raw".
I see a lot of comments arguing whether it's even possible to assess technical skills during an interview, and overall spitting on whiteboard brain teasers.
For the former, really, you need to be in the front row of hiring to understand it. I'm not talking about filtering candidates that can answer library specific trivia or solve red black tree removal on a white board here. I'm talking about senior Python developers that cannot remember the syntax of a for loop, data science specialists that cannot ELI5 the intuition of a linear regression. That's the degree of "low skill level" I'm talking about. I think a lot of people here are biased toward thinking the average programmer on the market should be the same skill level of their average colleague.
This is Wrong.
You are reading hacker news, you are very likely to be passioned and dedicated about what you are doing, you are most likely working in an above average company, surrounded with above average colleagues. Your perception of the average programmer is biased toward your own surroundings.
Now I see that the whiteboard interview seems to be really dreaded. And man, do I feel you. I also used to hate them as an interviewee. But that does not mean they are all the same.
When I do a whiteboard interview, I am perfectly aware that the candidate is obviously stressed, uncomfortable, and not at 100% of his potential. That's why the questions I ask are typically not too intellectually challenging. Some variations of the fizzbuzz mainly, along with a small exercice on recursivity in case the fizzbuzz is too easy.
"Whiteboard interview" should not become a strawman for "24yo fresh grad throws B-tree inversion at you to feel superior". Really, the only thing that should be tested in these interviews is your programmer muscle memory. And from my experience, it does work.
Re: Red flags I saw while doing technical interviews
#347One, wrt the companies I worked for, I didn't feel like they were vetting my technical skills enough; at best it was an hour of chatting and going through some of the code I wrote, but in my head there's just so much more to it. I felt like they were easily impressed. I also felt like I was cheating because I had reviewed so many interviews, so I knew what to look out for.
Second, I initially went in there just to orient myself, to prove myself in technical interviews, but for both recruiters and employers, it felt like going into the process already meant I really wanted to work there. I never felt like I learned enough about the job to make that decision yet (although there is usually a one month grace period where you can quit or get fired without cause).
Third, wages varied wildly. One job that was interesting was right across the street from me, flew through the interviews easily etc, but their offer was at best 2/3rds of what I earned at the time, it would have put me back years. I wonder if their wages were just not that great in general, or if they were betting on me preferring a one minute commute over a decent wage. I couldn't afford to live here on what they were offering so I declined. They did get back to me a few months later, I wonder if they changed their wage structure. I might reconsider if they can go over my current income.
I did find a new job in the end, one where I didn't actually do a technical interview, but where I felt like they actually needed me (instead of just an ass on a seat), like I had a Mission to accomplish. Still working on that, slowly. What also helped is that while I work 4 hours / week less now (I was looking for that), I still earn the same as I did at my previous job - less taxes for a lease car, and income tax laws changed.
Re: Red flags I saw while doing technical interviews
#348Earlier quoted context omitted.
> It was designed as "This is one of the simplest possible programs one can write. Weeellll, I mean it doesn't totally succeed in meeting that design criteria. Fizzbuzz weeds out three kinds of candidates: - candidates who are (currently) unfit for any programming job - candidates who freeze up during the interview - candidates who have never used the mod operator I fault fizzbuzz a bit, because there are candidates…
I'm sure there exist jobs where its OK not to know that a mod operator exists, but none of mine were of those kind. I'm pretty sure my experience matches the majority by a pretty large margin. > A fizzbuzz with fewer false-positive rejections might be something like "implement multiplication without using the multiplication operator". While possibly a fair question, this is a whole order of magnitude more difficult t…
Sorry, in my mind the input was restricted to positive integers. My fault for not making that clear.
def mul(a, b):
accum = 0
while b > 0:
accum = accum + a
b -= 1
return accum
You are correct that accounting for floating point would make this more complicated than fizzbuzz.> But this is precisely the opposite of FizzBuzz. The goal is to weed out horrible candidates, not identify great ones.
This accomplishes both at once. That's a super set, not an opposite.
Re: Red flags I saw while doing technical interviews
#349Earlier quoted context omitted.
!!(n & (n >> 1)), I assume.
Bonus points for the boolean sanitation! Now let me tell you about the candidate that wanted to turn the integer into a character string and then search the string for “11”...
However I understand that may be part of the discussion afterwards.
Re: Red flags I saw while doing technical interviews
#350It is important when thinking about social issues that the VAST majority of the population have very much the opposite experience - they might have to apply to 20 jobs to get one interview and if they get an offer they have to take it or they won't be able to make rent. The knock on effects on that on their work life are enormous.