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

351–360 of 394 posts

Re: Red flags I saw while doing technical interviews

#351

Post by Jach »

joezydeco wrote: post #337
addaon wrote: post #326

Earlier 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”...

Heh, I'd accept it. In screening I used to ask them to implement an isOdd() function for an unsigned int, and after they did it (never had someone fail) see if they could come up with alternate ways. Mainly to see if they're aware of bitwise operators, though it's nice to see they can write loops too. It wasn't a fatal flaw if they weren't (it would be if they couldn't solve it in any way), but knowing is better than not knowing. Anyway one person who didn't know nevertheless amused me by doing a conversion to string and checking the last digit.

After years of asking the same questions to intern candidates and to senior+ candidates, interns did consistently better. There are a lot of "experienced" but not very skilled people out there. They exist already inside ompanies too (Principle level checking in hundreds of lines of code with many classes and tests, purportedly to add logging support to something, but the code was ultimately a NOP as it did nothing) but even if it's impossible to put out the tire fire it's best not to contribute to it.

Re: Red flags I saw while doing technical interviews

#352

Post by Aeolos »

salawat wrote: post #151
opportune wrote: post #93

Earlier quoted context omitted.

My issue with the two “PM”s I interact with the most: Project managers basically do something that the devs, especially dev manager, can handle themselves. It seems like a leftover process for when software contracting was more common. There’s no reason a developer can’t just manage the Kanban board and write a quick report. Product managers can be really good but in a lot of cases they just devolve into stakeholder…

I used to see things the way you do. Then I actually ended up in the position where I took on the responsibilities of a Project Manager in the course of building a department. I see it much differently now having worn both those hats as a generalist. You're tracking two different sides of the same body of work, and there is solid value that a good project manager provides in terms of producing a meaningful skeletal s…

Your experience meshes with mine perfectly.

Especially this is key: > The challenge is as much making sure things are in the right place at the right time, defining what the right time is, and making sure to unblock people as they run into obstacles

> It's a completely different type of work from straight up technical work, and is fundamentally destructive to maintaining the fine grained technical context you need to accurately implement something.

Exactly! Thank you for putting this so succinctly.

Just being aware of what needs to be done and in what order is critical. For that you need a bird's eye view of all relevant pieces, which is almost impossible to do when you are in the weeds.

Re: Red flags I saw while doing technical interviews

#353

Post by AshamedCaptain »

Zippogriff wrote: post #242
grumple wrote: post #229

Earlier quoted context omitted.

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

I'm 100% sure I've come off in a couple interviews like one of those "phew we dodged a bullet there, guy can't code at all" stories. Meanwhile actually I can and many employers have been very happy with my ability to do so, and I've had a long and reasonably successful career. The problem's not even that I'm bad under pressure, and in fact I've repeatedly been told the exact opposite by people who've worked with me.…

> The problem's not even that I'm bad under pressure, and in fact I've repeatedly been told the exact opposite by people who've worked with me. The problem is specifically about doing a programming performance in front of an audience

Sure a "whiteboard interview" basically optimizes for people who can actually pass whiteboard interviews rather than people who can do the job.

But to claim that there is a NON-NEGLIGIBLE number of people who basically become 100% ignorant when under the stress of a whiteboard interview BUT are excellent employees in any other stressful situation is, to say it in nice words, [requires citation].

And if one really has this apparent rather unique type of handicap, then better mention on CV to try to get some empathy from the hirer, or just _train_ to avoid it. Yes, most people do _train_ for the express purpose of passing interviews.

Re: Red flags I saw while doing technical interviews

#354

Post by AshamedCaptain »

grumple wrote: post #229
edanm wrote: post #209

Earlier quoted context omitted.

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

Everyone experiences stress on an interview, and thus may not be able to solve "do you know it" problems that he would have been perfectly solved after a better night's sleep. That is not the problem (we call them "happy idea" problems around here). I really dislike being asked this type of problems and I also dislike asking them for these reasons. Despite the fact the positions I've interviewed for you end implementing "pure data structures" much more than you end up implementing business rules (we build software for engineering: simulation, optimization, etc.). So imagine how low I set the bar between my colleagues.

The problem is when you apparently _forget_ the syntax for a function declaration in a programming language you claim N years of experience in your CURRENT position. This is just absurd. Our you suddenly get completely stuck with counting odd numbers on a sequence or the like. And this happens surprisingly frequently. I just cannot believe you can have this type of anxiety (I am extremely shy myself) outside your first or maybe second interview.

Re: Red flags I saw while doing technical interviews

#355

Post by sobani »

dmoy wrote: post #221
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.

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…

I'm only 90% sure I know the syntax of a for loop in my chosen language, C#. The reason for the missing 10% is that I never write this syntax.

Most loops are covered by a foreach or by LINQ (think: map and reduce, buy nicer).

The few times I actually need a for loop I type: "for" and then I focus on the loop body. If my needs are more complicated, I _modify_ the for loop my IDE gives me.

Re: Red flags I saw while doing technical interviews

#356

Post by nitrogen »

AshamedCaptain wrote: post #354
grumple wrote: post #229

Earlier quoted context omitted.

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

Everyone experiences stress on an interview, and thus may not be able to solve "do you know it" problems that he would have been perfectly solved after a better night's sleep. That is not the problem (we call them "happy idea" problems around here). I really dislike being asked this type of problems and I also dislike asking them for these reasons. Despite the fact the positions I've interviewed for you end implement…

I think my daily driver language (Ruby) has become so ingrained in my mind that it's written out of muscle memory in Vim, and translating that direct connection from thought to Vim into a whiteboard might actually be challenging. You almost never write for loops in idiomatic Ruby anyway, you use an iterator chain.

Languages like C that have a single official for loop syntax are a bit easier to remember, in part because it's a syntax I have previously used on a whiteboard rather than exclusively in actual code.

So if a candidate can't write a loop on a whiteboard, maybe let them try in a non-IDE text editor, or have them glance at a formal grammar for the language as a refresher that won't give away the game to someone who can't actually code.

Re: Red flags I saw while doing technical interviews

#357

Post by sobani »

username90 wrote: post #315
cmrdporcupine wrote: post #110

Earlier quoted context omitted.

If companies want to hire experienced senior talent, then streamlining isn't going to be a good idea. They need to recruit them, and that means not alienating them right away. The process for new grads and interns should be different from senior talent. I don't care about the division of labour. Want to hire people away from Google? Don't be a pain in the ass. People expect pain in the interview process, but not befo…

> If companies want to hire experienced senior talent, then streamlining isn't going to be a good idea. They need to recruit them, and that means not alienating them right away. Why would you want to work for a company which has such a hard time recruiting and retaining senior talent that they need to pander to them?

Why would you want to work for a company which has only those desperate-enough-to-jump-through-hoops applying to them?

Re: Red flags I saw while doing technical interviews

#358

Post by sobani »

nunez wrote: post #336
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.

Like, on purpose? If you know what fizzbuzz is, then you can probably whiteboard it. It’s literally: ``` case $input when $input % 3 == 0: “Fizz” when $input % 5 == 0: “Buzz” when ($input % 3 == 0 && $input % 5 == 0): “Fizzbuzz” end ```

You failed to return the numbers that are neither divisible by 3 nor by 5. Also I'm pretty sure your code will never return "Fizzbuzz", since 15 would already be matched by %3.

It's quite ironic that you had all the time in the world to check your code and the ability to silently walk away when the pressure would've been too high and yet you included 2 obvious bugs in your 'proof' of how easy this is.

Thank you for your time, but I'm afraid you would not be a good match for this position at this moment.

Re: Red flags I saw while doing technical interviews

#359

Post by AshamedCaptain »

nitrogen wrote: post #356
AshamedCaptain wrote: post #354

Earlier quoted context omitted.

Everyone experiences stress on an interview, and thus may not be able to solve "do you know it" problems that he would have been perfectly solved after a better night's sleep. That is not the problem (we call them "happy idea" problems around here). I really dislike being asked this type of problems and I also dislike asking them for these reasons. Despite the fact the positions I've interviewed for you end implement…

I think my daily driver language (Ruby) has become so ingrained in my mind that it's written out of muscle memory in Vim, and translating that direct connection from thought to Vim into a whiteboard might actually be challenging. You almost never write for loops in idiomatic Ruby anyway, you use an iterator chain. Languages like C that have a single official for loop syntax are a bit easier to remember, in part becau…

Even if your IDE would type your entire programs for you, you would still know the syntax of the language just because I am 100% sure you have actually read more code than you ever wrote. And do note that even in C there is not a single official loop syntax -- a while (get_next())-like thing is a perfectly valid loop in C. All of them valid answers -- I used the word "sequence" and not "C array" for a reason.

And if I start showing them an EBNF grammar for the language, now that's TWO languages that you will show you don't remember rather than one. I find this even more absurd; you don't remember anything of the syntax of the language you used at work for years, but you think you can rediscover it from the FORMAL language specification in a whiteboard?

Re: Red flags I saw while doing technical interviews

#360

Post by sumtechguy »

stronglikedan wrote: post #253
sumtechguy wrote: post #195

Earlier quoted context omitted.

This is really why I use the 'easy' type questions (some variation of fizbuzz or something simple). A senior guy will crank it out in 5-10 mins. I then ask a question or two on how to improve it and a mini walk through of what they did and why. I also make it clear I sometimes get people who just can not do it but have the resume chops for it. I then usually spend the rest of the time digging on previous techs they h…

+1 for fizzbuzz. It still amazes me how this simple little test can often weed out a largish portion of candidates early on.

I do not use fizzbuzz but variations that are simple like it. I do not like fizzbuzz for 2 reasons. It relies on a math trick. Modulus math is something everyone can grasp but it is not something everyone knows about. Plus it is easily looked up and gamed. I try to pick something that has a few if conditions and a loop, which is what most people do. Bonus if it can be a 'refactor' style problem for the small walkthrough afterwards. But it is not necessary for that. If I were to make one up right now I would say something like 'given a string reverse the first half and move the second half to the front of the string and return the result'. There are enough little gotchas there to see if they have a feel for what can go wrong and loops and ifs. It also has an advantage that it is not easily looked up on the internet and pre-studied as fizzbuzz has been codegolfed on some discussions. The downside is it would probably burn a lot of time. So you need to budget your time with them accordingly. If I can talk someone into it I try the test out on them beforehand to see how long it would take. I want it to be quick. I just want someone who is competent and can explain what they did and has some relatable experience and can explain what they did there.
Post reply on HN