Need help?
<- Back

Comments (68)

  • plugger
    "Work to live, don't live to work". When you're on your deathbed work won't sit there with you and hold your hand. People are critical, not buildings or computers or networks. If you do choose to go down the path of overwork for recognition (as I did in my early 20s to earn a business visa) set strict guidelines around it and ensure you benefit as much as your employer. No one will manage your own work life balance better than you.
  • gopalv
    This Ousterhout lecture lives in my brain (this one and the one about scar tissue)."A Little Bit of Slope Makes Up For a Lot of Y-Intercept"https://www.youtube.com/watch?v=mE98Is1quwY> Pick a radical idea> Build it over a weekend:What AI has done is that we can do 10x more work a week, while only delivering 2x to production.Right now, there are 4 people (and me) working on the same idea in 5 different ways - we're all training small language models, the goal is to get smaller or fewer active parameters.By next week, we'll have lost on 3 different approaches. I know my approach is a dead-end already, but I'm not ready to give up till the pencils down.The people I work with are great, because they will see the better solution by the end of it, whether they proposed it or someone else did.A couple of them have been in the industry for less than 5 years and I feel like their slope is better than mine, which means I'm going to have a good time when they're fully up to speed :)
  • hypfer
    > As a hiring manager at Anthropic, I stopped asking candidates to do them.Before engaging with this content, one should keep in mind the very specific circumstances, that person is working in.There might be learnings or thoughts that carry over to other businesses, but chances are high that most don't.
  • kayashaolu2
    The heart of the coding interview is to get signal on a candidates’ ability to solve a problem without all of the inputs given to them, see how they and explain their thought process as they do it.Because of AI, what it means to “not have all of the inputs” has changed as anyone can cut and paste a Leetcode problem to a chatbot and solve it.I think we are going to iterate a bit to figure out a better signal than the typical coding interview. For junior engineers, I think coding questions will move towards MBA style problems when someone is given more of an open ended question with a codebase and you see what the candidate does without context to reduce the problem.
  • _ink_
    "work on the weekend for free" aka move the risk (of wasted resources) to the employee. Excellent advice.How about fostering a working culture were employees get a chance of trying out new things during office hours? Especially since AI is rising productivity so much.
  • marifjeren
    The article talks about the coding interview being gone but it is still around. I don't know about the other companies in this post but Stripe still does no-AI hackerrank style interviews for example.
  • arjie
    dy/dt more important than y. Happens to everything. People, organizations, civilizations. One day the world woke up and a country that had only recently had sheep on the lawn in front of the seat of power was defacto ruler of the world.If you’re the big y, that can change too. The big dy/dt is coming.Far called, our navies melt away,On dune and headland sinks the fire,All our pomp of yesterday,Is one with Nineveh and Tyre
  • anilgulecha
    In the new world, normalised interviews are going away, because business value is not normalized. This means that domain based interviewing and signals are going to make a comeback.It would make sense to build your career in a single domain, since your built up expertize will transfer to other companies within that domain.Far fewer switches will happen for seniors across domains.
  • ispq
    While the approach makes sense, I have yet to see a quantifiable and normalised way to replace Leetcode interviews.It’s probably too soon to claim “death of the coding interview”.
  • quantum_state
    This is a very positive development for the field.
  • rbbydotdev
    leetcodes as much as we dont like them. could help to reduce bias. you either pass or fail them at the very least. now too much is being left to hand waving, interpretations can be charitable on the mood of the interviewer, or the opposite.One could even think of: https://en.wikipedia.org/wiki/Hungry_judge_effectAlthough I do appreciate, giving green minds the chance, I cannot help but think hiring managers will read into "A Little Bit of Slope Makes Up For a Lot of Y-Intercept" as an excuse for ageism. Which the industry is already pretty rife with.
  • bob1029
    I've been considering very unconventional techniques for interviews. Like requiring candidates participate in a team based multiplayer game as part of the interview process. Completely out of left field without warning.Assuming the applicant has zero experience with gaming, this would be an incredible opportunity to evaluate how well they cope with uncertainty under pressure and adapt to unusual conditions. If the applicant is already a grandmaster on the ladder, this becomes an excellent test of their humility and teamwork.If the applicant gets shitty about the mere idea of playing a game as part of a "serious" job interview, I think I would have all the information I need to make the right decision. If you can't get a little bit flexible in this new world, I don't want you on my team anymore.
  • jdw64
    Sometimes when I go in to get advice, I always realize that my situation is different from everyone else’s. It’s a good piece of writing, but it doesn’t fit me—though I don’t know how it is for other people.
  • anon
    undefined
  • epolanski
    Technical interviews have always been silly and our is one of the very few industries where they were common practice, with take home assignments and multiple rounds.Just hire fast and fire fast if it doesn't work. Less expensive and better success ratio than this silliness where you get the MIT-bred Leetcode ninja that ends up having negative value between his lack of productivity and terrible code.
  • AdrianB1
    I have a big problem with the "(1) Pick business impact over backlog" part as advice for a junior engineer. It always comes from people that are not only not juniors, but from people that are no longer engineers, but entrepreneurs.A junior engineer's focus should not be to deliver the work that is important. The business impact is the problem and responsibility of management, an engineer should do engineering and not be asked to take business responsibilities. If you design a new car engine, the sales volume and market strategy is none of your business and it is way above your pay grade. A junior engineer is the one that does what is asked to do, in the best way possible. A senior engineer is at the border to business impact, maybe, but even then the lead engineer for the rocket engines at SpaceX is not responsible of the business impact of the company.But some bad people are trying to push more and more responsibilities to people that should focus on their domain. I also see now a push on low level engineering managers to do "organizational work" that usually does not have any meaningful impact and nobody cares about, just to be a differentiator for a promotion to the next level of even more meaningless work. Leave the junior engineers alone.
  • duckstreak
    [flagged]
  • throw20261022
    [dead]