55 replies

1. Kevin Yank 3 min later

   @zachleat Bit of a false dichotomy. Given those choices, I’d say A. But I’d actually merge them into

   C: “It’s more important that you have a solid foundation as a web developer than knowing about any specific framework, but we have standardised on React. If you don’t already know it, you’ll get to learn it here.”

   1. Zach Leatherman 21 min later

      @sentience a unicorn rancher! 😅

      1. Eric Amodio 2 hr later

         @zachleat @sentience I'd go with a different C: “It’s more important that you have a solid foundation as a web developer than knowing about any specific framework, but we unfortunately use a lot of React. If you don’t already know it, you’ll have to learn it to maintain and optimize while helping us avoid it as we move forward.”

         1. Zach Leatherman 2 hr later

            @eamodio @sentience well said!

2. Philip (is looking for work) 6 min later

   @zachleat Using Cobol makes it easier to hire Cobol developers.

3. Private reply 10 min later
   1. Private reply 12 min later
      1. Private reply 13 min later
         1. Private reply 14 min later
            1. Private reply 17 min later
               1. Private reply 19 min later
                  1. Private reply 25 min later
      2. Private reply 1 day later
         1. Private reply 1 day later
            1. Private reply 1 day later
4. Falcon 24 min later

   @zachleat whichever is more honest about your hiring decision I think. If you go with B, I'll be focusing my discussions (and strong points) around React. If it's A, I'll focus less on React during the conversation

5. cthos 🐱 25 min later

   @zachleat what are the expectations of the role?

   Does the organization doing the hiring expect you to be productive immediately or in several weeks?

   Are you a contractor being hired for a specific duration?

   Should you be expected to know where the foot guns are in the framework the team is using?

   What level of experience?

   This kinda feels like “do I want someone who speaks Latin right now or someone who knows proto-Indo-European who can learn Latin”.

   1. cthos 🐱 26 min later

      @zachleat I mean I index really heavily on capacity to learn as a hiring metric, but it sure is nice when we have a shared dialect already.

      1. Zach Leatherman 28 min later

         @cthos and what should that shared dialect be, ideally?

         1. cthos 🐱 29 min later

            @zachleat Web Components, obviously.

            1. Zach Leatherman 30 min later

               @cthos haha, this is my point—kinda.

               A: “It's more important that you have a solid foundation as a web developer than knowing about every framework”

               B: “Lit—we use Lit—you should know Lit”

               1. cthos 🐱 39 min later

                  @zachleat sure but that doesn’t invalidate any of the other points I made, does it?

                  Frameworks are abstractions we’ve built on a foundation. We can operate at the level of the framework, we did that because it’s useful. Frameworks have their own quirks and dialects, (Hell, so does WebKit vs Gecko) and if I’m running a project that speaks that dialect, who’s going to have a better time integrating if they’re junior? Senior? Principal? Pretty sure the answer changes depending on the context.

                  1. Zach Leatherman 46 min later

                     @cthos I think we might have gotten off track—might be useful to circle back to the original point: Are you saying that you would prefer B in some cases?

                     1. cthos 🐱 1 hr later

                        @zachleat yes, depending on the context, seniority level, needs and demands of the role, and overall team environment.

                        1. cthos 🐱 1 hr later

                           @zachleat related hypothetical: say I’m hiring a senior cloud architect. We primarily use AWS. Should I hire someone who has never architected a system on AWS before? There are enough nuances of the platform that I can’t just pick up someone who has sysadmin experience and expect them to guide other teams on AWS usage.

                           I think you’re talking about the inverse of “there are more people who know AWS so we should use AWS”… which is definitely one of the factors that go into a plaform decision.

                  2. Private reply 1 day later
6. ijk64✅ 33 min later

   @zachleat A

7. Alex Russell 34 min later

   @zachleat So I've had this out with many hiring managers over the years (as you might expect); the operable logic is worse than you might imagine.

   Some actually think "it's easy to hire for" and "we need to move fast" will not meaningfully impact product quality in ways that will come back on them.

   Others simply don't understand that a bad version of their service means that their product thesis can be totally muddied in the slow waters.

   1. Alex Russell 36 min later

      @zachleat Still others *just* got done replacing "old timers" who were "expensive" because they would push back on absolute lunacy from JS slingers. These "not team players" were seen as a liability, and despite the escalating expenses involved in keeping the JS folks happy, questions about costs were never actually re-examined.

      So the *idea* of quality got written off in order to change the guard. How could it ever be re-asserted from within that new crew?

      1. Zach Leatherman 37 min later

         @slightlyoff Reminds me of client-side A/B testing frameworks—how merely the introduction of a large client rendering tool tanks your site performance, which ruins any result you get from both A and B

      2. Alex Russell 41 min later

         @zachleat In the worst cases, the "success" of the "big rewrite" (note: I'm in the room, which means...yeah...it did not go that way) was seen as reason to continue down whatever path was most in vogue among the junior engineers they'd previously hired.

         This becomes self-re-enforcing, as the product and engineering managers have abdicated responsibility for the product to engineering dogma.

   2. Danny Blue 37 min later

      @slightlyoff @zachleat I recently worked with a recruiter to look for more "web dev" skills even though the position was for a "react developer". he said more candidates are making it through the tech portion of the interviews.

      1. Danny Blue 41 min later

         @slightlyoff @zachleat give me a web developer with no react experience over a react dev any day. (react === any framework)

8. λ Calrissian / MatthewP 38 min later

   @zachleat I was seeing so much of this, especially in the Web3 job advertisements that people were sending to me, which seemed like an interesting monoculture

   1. Zach Leatherman 39 min later

      @mattpodwysocki when you say “this” do you mean the former or latter?

      1. λ Calrissian / MatthewP 53 min later

         @zachleat This meaning B, apologies for not being clearer

         1. Zach Leatherman 55 min later

            @mattpodwysocki ah, no worries!

   2. Brian LeRoux 💚 1 hr later

      @mattpodwysocki @zachleat hehe a friend of mine felt web3 adopting react en masse was a bullish signal. I respectfully disagreed. 💀

9. Stephen Belovarich 58 min later

   @zachleat

   A, but set expectations in the job rec about which stack the candidate needs to ramp up on.

   I’ve explained to so many people JavaScript is a pre-req to React and without a solid foundation in JS the employee won’t be able to solve problems, then be ignored because the managers were convinced they knew better. They kept pushing back saying the candidates only needed to know React. There’s a fundamental lack of understanding how the web platform works at management level.

   1. Zach Leatherman 1 hr later

      @iplayitofflegit “There’s a fundamental lack of understanding how the web platform works at management level” oof luckily it’s been awhile since I’ve worked at a company like that!

      1. Stephen Belovarich 1 hr later

         @zachleat yeah it’s not like that at every company but been my experience where there’s a lot of Java in the stack. 😑 hoping not to contend with this in my next role.

   2. xmlns="Dan" 1 hr later

      @iplayitofflegit @zachleat that's very dependent on the job and company at hand.

      I know jQuery, I know VueJS, but I've never needed to learn JS. There are a simply massive number of Devs who are working on enterprise apps that in the past would have been done (faster) in VB6, Just a bunch of buttons on some navigation bars and tables displaying data. Don't need much of anything fancy for those.

      For anything client facing, sure, but even then not everyone is making figma.

10. xmlns="Dan" 1 hr later

    @zachleat I don't know React, but B is the job description I'd apply to if both of those were put in front of me.

    B is low risk compared to A.

    A could be anything, including a home-grown frankenstein version of React invented by Carl who has since left the company.

    1. Zach Leatherman 1 hr later

       @divclassbutton fascinating

11. Andrew Douglass 1 hr later

    @zachleat that’s tough. A is probably better for the recruiter to focus on, but B is important once you get there.

    I had one job where specific libraries were The Way to solve specific problems as determined by a committee. Including keeping libraries pegged to version ranges across projects. It was nice to know that you wouldn’t switch between moment and date-fns depending on developer whims. BUT it was a Fortune 500 in an industry I hated.

12. McNeely 3 hr later

    @zachleat as a candidate I will go with A (and that's nothing to related to my opinions on React) simply due to the the fact that acknowledges that you are there to solve problems and create solutions rather than putting the focus on HOW you do those things. Having said that I'm definitely going to ask the tech stack very early in the process.

13. elle mundy 4 hr later

    @zachleat definitely A. B sounds like a horrendous mercenary dev shop that i want no part in

14. Mike Aparicio 5 hr later

    @zachleat Both interviews will only consist of JavaScript questions. 😅

15. Johan Halse 9 hr later

    @zachleat the “easy to hire” argument is so obviously broken. Unless you purposely set out to tank your velocity, you probably want to staff your team with harder-to-find people! If you do it right the search is going to take just as long whether the tech is hip or not. It’s only a good argument if your company is in ship-something-meh-and-cash-out mode.

16. Jay Cruz 15 hr later

    @zachleat I don’t buy the premise that someone that’s actually good at React, would be bad at Web Development. Like there are certainly people that are bad at React, but that’s usually because they are bad at Web Development in general. Just wanted to add this input to the convo.

    1. Andrew Walpole 15 hr later

       @jaycruz @zachleat Anecdotally, a few years ago, I had to deal with a contract dev doing a gatsby site for us, and the react/gatsby part was decently done, but then when it came time to style it all up, they didn't know how to do CSS (everything absolutely positioned 😓, no responsiveness, etc). It was quite rough to untangle it all. That was the first time I really concretely saw that folks were learning web dev via a different path than html/css basics first.

       1. Jay Cruz 16 hr later

          @walpolea @zachleat Have you heard the news? 😀 https://css-tricks.com/the-great-divide/ For many years Web Development was mostly Backend Development and Front End was closedly tied to Web Design. But ever since “real programming” was brought to the client side, and Node happened, Web Developers that specialize on client side, don’t need to be experts in HTML and CSS any more. They don’t make websites and webpages. They can be real engineers now that build uis 🌝

          1. Andrew Walpole 16 hr later

             @jaycruz @zachleat Four years later this article is still spot-on 😩

    2. Zach Leatherman 16 hr later

       @jaycruz For sure, that makes sense to me. And in a larger sense I wouldn’t frame someone as “bad at web development“ either—“inexperienced” feels more productive

17. Private reply 1 day later