Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Coding interviews are stupid (ish)

darrenkopp.com

Post reply on HN
Print view View original

321–330 of 679 posts

Re: Coding interviews are stupid (ish)

#321

Post by damontal »

arcticbull wrote: post #81
speeder wrote: post #51

Earlier quoted context omitted.

What kind of job pay 400k? Even when I worked as C++ guru at BMW and was hired as very senior my before taxes compensation was 40k (year).

You can make double or triple that in total compensation at the staff or principal level in the Bay Area. I'm not saying these jobs are easy, or easy to get, but yes, they exist, even in this market. The reality is the biggest drop-off in recruiting is at the very top of the funnel. Your basic phone screen and first technical screen -- before you get to a full panel. Once there you have way more, qualified, applicant…

You can make millions as a famous actor in Hollywood. So what? That doesn’t describe the average actor’s situation.

Re: Coding interviews are stupid (ish)

#322

Post by pseudalopex »

paulddraper wrote: post #294
xandrius wrote: post #289

Earlier quoted context omitted.

So you're saying that someone wasting their time studying leetcode to pass a stupid game is a good indicator? I would almost believe the opposite: if you actually pass those tests with flying colours, it shows me that you believe you needed to do that to be hired, while someone who's actually experienced would never in a million years step down so low.

I didn't state my personal opinion above, but yes I have seen leetcode aptitude to positively correlate with day-to-day problem solving.

I have seen Goodhart's law.

Re: Coding interviews are stupid (ish)

#323

Post by pseudalopex »

jjtheblunt wrote: post #320
hintymad wrote: post #239

Assuming that a company does not look for candidates who are naturally good at ICPC-type of questions or geniuses who can come up with amazing algorithms in a matter of minutes, there is actually a different way to do coding interview: just give a high-level description of a sophisticated enough algorithm to a candidate and ask the candidate to turn that into code. I think it strikes a good balance between depth in C…

What is ICPC?

International Collegiate Programming Contest

Re: Coding interviews are stupid (ish)

#324

Post by josephg »

theideaofcoffee wrote: post #246
gardenhedge wrote: post #237

Earlier quoted context omitted.

How do you end the interview? To me it seems like that might be awkward.

I'm not op, but I have had to do this a few times because of the same reasons. You pause, take a breath and kindly say "thank you for the opportunity, but at this time I don't think this is the right fit" and leave it at that. No need to embellish, or add extraneous detail or think you're being awkward because they will do the same thing if they don't want to go further in the process with you. It's just business, tr…

If I’m considering ending the interview, I’ll instead critique it on the spot. It’s more interesting for everyone. If they pass me over, that’s fine - I’m already considering walking out anyway.

“Hey, can I stop you there for a minute? This interview style isn’t really working for me to the point that I’m considering cutting the interview short and heading out. Here’s why …” - and then have that conversation. Some people will take that badly - and that’s fine. But I have no idea what will happen next after saying something like that. And that makes it an interesting direction to take it.

Re: Coding interviews are stupid (ish)

#325

Post by mewpmewp2 »

josephg wrote: post #311
xandrius wrote: post #289

Earlier quoted context omitted.

So you're saying that someone wasting their time studying leetcode to pass a stupid game is a good indicator? I would almost believe the opposite: if you actually pass those tests with flying colours, it shows me that you believe you needed to do that to be hired, while someone who's actually experienced would never in a million years step down so low.

I believe skill at “leetcode problems” is predictive of general programming skill. Someone who can solve leetcode problems can almost certainly learn css. But, clearly from reading comments here, not the other way around. Personally I love leetcode style problems. They’re fun. And useful - I use this stuff in my job constantly.

I would be scared you are overengineering and optimising things though. I have seen people implementing complex paradigms and weird optimisations instead of writing simple code just to make sure they are perfectly optimising.

E.g. optimising client side code where N is likely never to be above 300, but instead of few simple lines, write a complicated solution to make sure it can scale to billions and beyond.

I would take any problem solving energy and spend it on side projects instead of doing leetcode. I do like those exercises, but I enjoy building new things more and which gives me practical experience which I think is more important.

Re: Coding interviews are stupid (ish)

#326

Post by Paul-Craft »

pseudalopex wrote: post #313
devbent wrote: post #288

Earlier quoted context omitted.

>I still don't get why such questions are even asked as most jobs I've ever had not even remotely touched those and I've touched quite a few industries, technologies and types of companies. I've had to work on tree traversal stuff multiple times in my life, anything low level GUI related will work with trees a ton. I've also had to work with hash tables directly, and with memory caching layers. I really should learn…

> I've had to work on tree traversal stuff multiple times in my life, anything low level GUI related will work with trees a ton. How many times did you have to write tree balancing code with no reference materials?

Bingo. You forgot to add "with someone literally looking over your shoulder," though.

I've written AVL trees, B-trees, red black trees, and a bunch of other things people have named here. But, right now, without looking at any references, I couldn't even tell you how to balance an AVL tree, much less sit down and write out code for it.

Re: Coding interviews are stupid (ish)

#327

Post by josephg »

mewpmewp2 wrote: post #325
josephg wrote: post #311

Earlier quoted context omitted.

I believe skill at “leetcode problems” is predictive of general programming skill. Someone who can solve leetcode problems can almost certainly learn css. But, clearly from reading comments here, not the other way around. Personally I love leetcode style problems. They’re fun. And useful - I use this stuff in my job constantly.

I would be scared you are overengineering and optimising things though. I have seen people implementing complex paradigms and weird optimisations instead of writing simple code just to make sure they are perfectly optimising. E.g. optimising client side code where N is likely never to be above 300, but instead of few simple lines, write a complicated solution to make sure it can scale to billions and beyond. I would…

Skill gives you the gift of choice. You know how to write it either way around and it’s up to you to decide. Being able to correctly decide when to hack something inefficient together and when to optimise is another skill issue. It’d make a good interview question, that.

Re: Coding interviews are stupid (ish)

#328

Post by markwkw »

godelski wrote: post #310
xandrius wrote: post #257

Earlier quoted context omitted.

I still don't get why such questions are even asked as most jobs I've ever had not even remotely touched those and I've touched quite a few industries, technologies and types of companies. To me, the value of a software engineer is to ask questions, make hypotheses and be able to iterate quickly. Balancing trees, leetcode and other algorithmic stuff on the spot sounds like bringing the dreadful education system struc…

> if a senior person can't in 30/45 min of talking with someone figure out the general experience level then the problem is them, really. This is why I've always been so confused. Why is the software engineering interview wildly different from the traditional engineering interview (seniors sit down with candidates and discuss how to solve a relevant proxy problem the team is currently undergoing (has the side benefit…

Mechanical engineering interviews seem to do the same as software: "Engineers always ask about beam bending, stress strain curves, and conservation of work. Know the theory and any technical questions are easy."

Basically an equivalent of simple algorithmic questions. Not "real" because it's impossible to share enough context of a real problem in an interview to make it practical. Short, testing principles, but most importantly basic thinking and problem solving facilities.

Re: Coding interviews are stupid (ish)

#329

Post by ok123456 »

inerte wrote: post #136
ok123456 wrote: post #52

I've found that asking them to review some obviously bad code with glaring errors and problems is more informative than asking them to solve some random DSA problem. Candidates who can code well can point out code that has obvious problems. Just ask if this is good or bad, and if it is bad, how they could improve it. This demonstrates competency and doesn't make the interview seem like a grind but instead more like a…

Just got be careful with the “how to improve” part. In my experience as an interviewee sometimes it becomes a regular algorithmic interview. A couple times I found some N+1 queries or inner loops and was asked to “fix it”, which might just turn into leetcode. The best code review interviews are the ones where there is a healthy amount of actual code, with a handful of functions and classes, some badly named variables…

Leave it open-ended and include code with multiple levels of bad so it's not just a quiz. I used real C code that research scientists had given me. If they look at it and say there's no reason this should be in C and in a dynlang instead, that is fine. If I hand them C code where the entire program is a 1000-line main function, with lots of repetition, hard coded file names, and fixed-sized string buffers, and all they tell me is the indentation is icky: that's a negative signal.

Re: Coding interviews are stupid (ish)

#330

Post by sanderjd »

josephg wrote: post #303
devbent wrote: post #288

Earlier quoted context omitted.

>I still don't get why such questions are even asked as most jobs I've ever had not even remotely touched those and I've touched quite a few industries, technologies and types of companies. I've had to work on tree traversal stuff multiple times in my life, anything low level GUI related will work with trees a ton. I've also had to work with hash tables directly, and with memory caching layers. I really should learn…

Yep. In a project I’m working on at the moment (collab text editing), I’ve implemented 2 different b-trees, a skip list, 2 custom file formats and a dozen or so algorithms which do various graph traversals. I get that this is uncommon, but if you scratch beneath the surface, most software (browsers, databases, compilers, OSes) are full of this stuff. Even while I was consulting stuff like this would come up. At one c…

> But if you ever want to go deeper, you’ve gotta understand data structures and algorithms.

I don't think this is quite right. I think it's more like:

If you ever want to go deeper, you've gotta be able to recognize when the problem you're solving fits a pattern for which good data structures and/or algorithms exist, and you've gotta be able to find, understand, and apply good reference material.

Solving this "knowing what you don't know" problem is the best and most important role of formal education, in my opinion. It's not as important to know a topic as it is to know that it exists, and some of the basic terminology necessary to get started researching it further.

Post reply on HN