Live data from Hacker News

In defense of coding interviews

biggestfish.substack.com

251–260 of 391 posts

Re: In defense of coding interviews

#251
post #216

Earlier quoted context omitted.

Interviewing is assessing how a person would perform, not an actual day to day collaboration. There is a gap. You do not talk like you would to a colleague. You have a limited time and it's more one-sided to even the playing field. It's worth preparing for to overcome the gap. It's like a dance. Your are supposed to lead deriving the solution, interviewer is supposed to follow closely and judge your performance. If y…

I would never change the way I speak to someone just because they're interviewing me. If you're interviewing me it's with a view to working with me on your team a few months later. You would surely want to see the real me, not some constrained version. Maybe it's an age thing, but I'm comfortable enough with my skills and my knowledge that I don't feel the need to put on an act. And remember that you're interviewing…

> Also, I would also be quite surprised if Google didn't allow candidates to Google information during the interview

I did a Google onsite several years ago (probably 7 or 8 years ago at this point). Each interview was just me in a room with a whiteboard and a person sitting at a table across from me with a notepad. No computer present.

I suppose I could have dug out my phone and Googled, but that feels unprofessional to me, moreso than if I had access to a computer.

Also the part I got stuck on was coming up with the trick needed to solve the problems. Most I was fine, but one in particular would have taken some decent searching to find something equivalent if I just Googled, and would have taken some time to grok the answer. Also that guy was not very forthcoming with hints or information when I asked him, so I doubt he'd have appreciated a Google search.

I don't remember the exact question, but it had to do with converting a 3D city model into a 2D skyline by drawing a single line. I got stuck on trying to visualize how to deal with partial overlapping models and irregular building shapes and ran out of time.

Re: In defense of coding interviews

#252
post #178
post #55

Earlier quoted context omitted.

Some people are ready to trade dancing for a lot of money and a resume that will open them the doors of where you really want to be.

Are they the people you want to hire?

In my place? Absolutely not, but we designed the interview process to try to avoid that.

Re: In defense of coding interviews

#253

Earlier quoted context omitted.

Ya know, I've heard this repeatedly over the past 15 years, but I've never actually encountered this mythical "senior programmer who can't code." Never worked with one. Never interviewed one. Never met one at a meetup. I think it's just a boogeyman used to frighten hiring managers.

Be grateful! They definitely exist. At my last company, I joined as their lead developer and discovered they already had another developer in the pipeline they were thinking of hiring. They thought the guy was super senior, and when I read his CV sure enough he came across that way. He emphasized on his CV that he was not only a Java expert but an expert on the internals of HotSpot itself. Probably he'd been saying t…

> They probably don't think of it as lying. They just write down every possible thing they've ever thought or read about and exaggerate, gambling that they'll never be called on it.

Well, job postings are infamous for listing a ridiculous number of "requirements" that aren't really requirements. Those who are familiar with hiring know that job postings themselves are lies and encourage people to ignore the requirements and apply anyway. Even the people who work for the hiring company say this! So it's a two-way street. There are already perverse incentives created by the hiring companies. And we also know that resumes are screened for specific buzzwords. You may not be recruited or interviewed unless unless your resume has the right buzzwords.

Re: In defense of coding interviews

#254

Earlier quoted context omitted.

I think this person has a better idea because your spouse scenario, while realistic, can easily be detected while you discuss the code being presented. You may have good intentions but what do you equates to "I don't trust you, bro/sis". Not a great way to start a relationship imho

> can easily be detected while you discuss the code being presented. That is possible of course. But if they wrote the code together, and know they will question later, you could teach the other person all the trade-offs etc. I could see myself doing that with a bad developer and get them through such an interview. > Not a great way to start a relationship imho Well, you could take the benefit of the doubt, and then…

> But firing is always such a big decision.

Isn't that why managers get paid the big dollars, to make the big decisions?

The whole rhetoric of the tech industry — taking risks, creative destruction, etc. — seems to completely fall apart when it comes to hiring, where everyone turns fearful and ultraconservative.

Re: In defense of coding interviews

#255
post #45
post #20

Earlier quoted context omitted.

But many senior candidates actually can’t code anymore. Also, typically the point of these questions is to see if the candidate can solve a novel problem not if they can use a hash table.

Then tell your company to not to reach out to recruit senior & experienced candidates if you aren't sure if they can code from looking at their experience, github, etc. I'm personally very tired of answering recruiters & hiring managers for specialized roles, then the interviews end up being some unrelated CS quiz, mostly from people with less experience than I have.

I once had an interview that told me to “design Twitter”. I drew some diagrams on the whiteboard, and the topic of the database came up.

I asked “do we want to have consistency or availability for this?”, to which the interviewer said “I want both”, to which I said “umm, I’m pretty sure you can’t have both, CAP theorem and whatnot”. We spent two minutes arguing which led to me taking out my phone and pulling up the CAP Theorem Wikipedia page, and eventually the interviewer begrudgingly admitted I was right.

I surprisingly did get an offer after that interview but I found it a little annoying to be interviewed by a person with less experience than me who I have to argue with because his understanding of computer science is wrong.

Re: In defense of coding interviews

#256
Stop defending whiteboard interviews. We know [1] that they are inherently biased against certain groups and have a very large false negative rate.

It amazes me how many people will defend the current interviewing process and then openly admit that the majority of their engineers could not pass the same process without spending dozens of hours preparing.

[1] https://news.ncsu.edu/2020/07/tech-job-interviews-anxiety/

Re: In defense of coding interviews

#257

Earlier quoted context omitted.

I would never change the way I speak to someone just because they're interviewing me. If you're interviewing me it's with a view to working with me on your team a few months later. You would surely want to see the real me, not some constrained version. Maybe it's an age thing, but I'm comfortable enough with my skills and my knowledge that I don't feel the need to put on an act. And remember that you're interviewing…

> Also, I would also be quite surprised if Google didn't allow candidates to Google information during the interview I did a Google onsite several years ago (probably 7 or 8 years ago at this point). Each interview was just me in a room with a whiteboard and a person sitting at a table across from me with a notepad. No computer present. I suppose I could have dug out my phone and Googled, but that feels unprofessiona…

Did you pass the interview?

Re: In defense of coding interviews

#258
post #211
post #195

Earlier quoted context omitted.

> preparing for the interview

Not sure what is wrong with preparing for a challenging interview. What is the point you are making?

You mentioned that it is not about Competitive Programming/leetcode stuff but a daily real world work. So how do you prepare? Just continue doing your daily work?

Re: In defense of coding interviews

#259
post #258
post #211

Earlier quoted context omitted.

Not sure what is wrong with preparing for a challenging interview. What is the point you are making?

You mentioned that it is not about Competitive Programming/leetcode stuff but a daily real world work. So how do you prepare? Just continue doing your daily work?

You prepare by making sure all your bases are covered. In my daily work discussions, for example, I tend to be very hand-wavy about concurrency, calling everything “locks” and hoping people understand that I can dig down into the details when needed. When I’m interviewing I don’t want to just hope, so I review my concurrency primitives to try and make sure I won’t put my foot in my mouth.

Re: In defense of coding interviews

#260

Earlier quoted context omitted.

Scrum does not mean "no freedom" or "no autonomy" it just says lets think about what we're going to do and try to follow a plan for the next week or two. Of course the individual software developer should be the one responsible to forming, adapting, and updating this plan (and it definitely should contain " collaborate with stakeholders, build prototypes and get feedback etc,") (of course, there is some level of 'com…

Sanity check: Would your manager complain if you stopped doing Scrum? If yes then you don't got that much freedom. If no, then I can see it being fine. It can work fine if nobody outside of it depends or uses the Scrum process, but then the company isn't doing Scrum, just the team doing it internally. This lets the team adapt and stop doing Scrum when it no longer fits their problem etc, that is the agile way. My poi…

In every Scrum team I’ve personally worked on (admittedly not a huge sample size), it was OK for a senior engineer to say that their work for the next two weeks isn’t scrum-able so they’re going to mark themselves as having no capacity this sprint.
Post reply on HN