• 1 Post
  • 98 Comments
Joined 5 years ago
cake
Cake day: May 24th, 2021

help-circle






  • I’ve been against live coding in an interview for years. But now with AI it’s something I’ve brought back into interviews, and it is to be done without AI. I refuse to hire someone who can’t write a function by hand, let alone can’t think through a problem on their own. I don’t really care if they get the right answer or even if the code works. I just want to see that they are capable of thinking through something and writing something reasonable.

    I’m not going to force anyone on my team to not use the tools day to day, but you’d better understand what’s going on and you’d damn well be able to do your job if there’s an outage. I’m also not going to have my team beholden to the whims of some LLM provider if they choose to change pricing or limitations.









  • If you’re truly honest about wanting to improve your skills then do not use AI!

    Just write code. Any code! It doesn’t matter. Spend the hours problem solving and debugging and banging your head against the wall. That’s how we all learned and gained experience. But also reach out and seek help about specific problems you can’t solve.

    For a project idea, how about a program that uses the Lemmy API to scan resent posts for Python topics. It’s something that can start basic but can be expanded upon. Start simple by just scanning posts from the last day. Then expand by adding a configurable date range, scanning several communities, multiple topics, presenting notifications, etc.


  • Agreed! I think both linting and type checking are extremely important to Python, but it’s also an extra step that far too many people just don’t take. And honestly, I used to get tripped up sometimes with setting up Python tooling before I started using uv.

    Unfortunately I also have to work with the occasional Python script that someone just slapped together, and that’s something far too easy to do in Python. It does kind of remind me of vibe coding. Initial velocity seems high, but if you’re not thinking about it, long term maintenance tanks.

    That’s not to say Python is bad, and there is certainly a lot of good Python code out there too. But it’s a language that does make it easy to make a mess, which will probably be compounded by LLMs.




  • That’s a terrible take and its desperately trying to draw an equivalence where there isn’t one.

    I’d argue that the slop code creates more drudgery with having to constantly babysit the LLM. Never mind a new blog post every week about how your “agentic workflow” from last week is all wrong and you need even more infrastructure to wrangle the LLM. It’s worse than the way the JavaScript ecosystem used to be!

    Reading someone else’s code is challenging, but at least with a person you can ask them questions or debate.

    I guess I’m just someone who finds reviewing someone else’s work tedious, though a necessary part of the job.