Hacker News Reader

Comment by drchopchop | Hacker News Reader

One big problem is that companies (especially FAANG) are wasting time having very senior devs do Leetcode-style shit, which is a false negative for people that don't balance binary trees and manually regex strings all day. This especially penalizes more experienced / older devs who don't have time to LC grind (of which I'm also one), and introduces unconscious selection bias.

Certainly there are other ways to verify someone can code: code samples, talking through high level language concepts, reviewing existing code, etc.

What people should be focusing on is this - 1) Do you understand enough systems architecture / code techniques to succeed at this particular company? This can be done via mostly talking. 2) Do you have experience that will help us with our company-specific problems? Give them an actual problem you regularly deal with, and get them to attack it.

View on HN

> unconscious selection bias

it's impossible that they don't know about it. the more i think about it, it's that they're either lazy or want to select for age but obviously can't do that in an overt way, so they pick a tool that nobody with a family has time to grind (i.e. 'old' people)

Your comment inspired me to ask a question I've had for a while. My background is not CS, it's computer engineering. So I didn't have any education in the fancy algorithms that you'll find in these interviews. Is that expected or did I miss something?

I also went to school for CE and although we did have some algorithmic and data structures classes, I don't think they were as in-depth as the CS curriculum.

For example, the only time I ever encountered red-black trees was in the context of prepping for software interviews.

I graduated from a CS program 6 months ago, and encountered red black trees in just one of my courses, so your experience isn't too different I think.

And then how often over one’s day-to-day career? It’s farcical.

I am currently in school for ce and I take the same algorithms courses as cs students, I feel like it is super dependent on school.

I have the same background and I think you either missed something, or your degree was much more EE focused. I had the required data structures + algorithms classes as part of my computer engineering curriculum

A lot of CE degrees are EE with just the barest veneer of software to meet ABET requirements.

Mine had data structures and software engineering as CE-specific requirements (along with a dash of microarchitecture and HDL/FPGA stuff), the CS algorithms course was an elective that obviously gave priority to CS majors.

Beyond that, we had a department head that really only cared about shoving as many EEs as possible into the PG&E hiring pipeline.

Compared to software creating a circuit design is a complete nightmare. With software you can get away with a lot of shady things but in EE every tiny detail can matter. You can do very simple PCBs as a hobbyist but it won't even compare to what the professionals are capable of doing. In software we have hobbyists creating extremely important libraries that are used by millions of people.

Depends on how much CS you were exposed to, I guess? Leetcode problems generally involve: DFS/BFS search, memoization, dynamic programming, various types of sorting, hash tables, etc... all baked into annoying edge-case-y problems that are difficult to rapidly solve under a timer when someone's staring at you.

Vast experience in compilers, embedded systems, functional languages, graphics, dev ops, or cloud technologies will be of no use. (Perhaps it will be later, if you get to a systems arch interview step.)

Re-posting a suggestion I made here a few weeks back:

Here's a radical idea (read to the end before you object). The inspiration is a blend of how open source projects recruit developers, and how the 20% Google side-projects used to work.

I work for company A, I'm starting to get slightly bored or interested in doing something else. Without quitting my job, I contribute a few days of code to company B, whose project I find interesting. As I contribute more to company B, I eventually quit company A and join company B full-time.

Benefits of this approach: no interviews. Know what you are getting into. Try different things and what works for you. How can we make this work: legal framework. California, if you are listening, pass a safe-harbor law that prevents companies from exclusive work arrangements, so I can always do a side-gig with company B even if they are competitors. Have company B compensate me, so we don't end up in a situation where company B is abusing job seekers by getting free work done. Maybe a law could say that I'm safe as long as my work for company B while employed by company A doesn't exceed 5% of my salary or so (so I worked for company B for a few days or weeks, not months). Would that work?

Sounds reasonable. Thing is, these companies pay, and this is what they do. So if you want to play there, you have to play the game their way.

Reply on news.ycombinator.com