Fork me on GitHub

When y'all are hiring a senior front end developer, how much ops / devops experience do you require and/or expect? I'm asking because it seems like a modern front end developer ought to also know how to setup/manage CI pipelines and perhaps automated deployment, which is likely to involve at least some cloud services knowledge.


And, yes, I'm asking because we are hiring for such a role but it's JS/React, not ClojureScript, so I haven't posted the job spec here -- but feel free to DM me if you want to know more.


It’s true that the CI and deployments can be very different for front (& mobile), I think a deep knowledge of the package manager and the compilation is useful for such a role, and at least some basics about dns / cdn, to help build the pipeline / deployments, I think frontend profiles with true ops skills are pretty rare though.


> it seems like a modern front end developer ought to also know how to setup/manage CI pipelines and perhaps automated deployment The projects I've been exposed to via various means had never put the onus on frontend developers here. It has always been variations of "I [some WUI developer] implement something, run npm test, commit and push, then wait for CI to complete, for PR to be reviewed, and then I merge it". A blissful ignorance of sorts. Whenever a pipeline needed to be implemented, it were either specific people that usually do that or just the most senior people on the project that tend to have a lot of experience in many domains. Nothing that would tie it to WUI itself. With that being said, personally I would of course prefer if a frontend developer I hypothetically want to hire knew how to do it, at least superficially, even if they'll never have to actually do it.


"I think frontend profiles with true ops skills are pretty rare though." -- probably, but with small companies I'd still hope some FE devs wear multiple hats.


It definitely exists yes, i know one who plays with github actions and aws beanstalk, or another that uses aws amplify, both are quick to setup and you rarely touch after that. For small companies indeed it can make sense.


But we don’t look for those specific skills when we search for those profiles at my company, it’s a « bonus ».

Rupert (All Street)22:01:53

I tend to find that backend devs know more about CI/Deployment/Cloud than frontend devs. These things (CI/Deployment/Cloud) also often end up being quite company/vendor specific (e.g. Github Actions vs Circle CI vs UrbanCode Deploy ...) so whilst they are transferable skills the candidate's knowledge may still be limited.

👍 2

That seems like over-selecting based on a rarely used set of skills. Hire an FEE that can set up CI and you’ll be glad they could set up CI once. Hire an FEE that’s great at what they do and you’ll be glad you hired them every day.

💯 3
☝️ 8
😄 2

“we’re not sure how to set up FE CI” sounds like it should be a different category of problem than “We need a great FEE because we’re too small to hire poorly” 😄

👍 1

regardless of frontend or backend, I expect a senior developer to understand how the CI/CD pipeline works. They do not have to write the code for the pipeline, neither choose the technology or the tools, but they should understand the abstract process and be able to reason about it. I expect the same level of understanding from a senior frontend developer with regards to the backend system. They do not have to write backend code, but they should be able to understand it. They should be able to understand when the frontend app puts pressure on the backend and how to prevent that, or how to communicate it before it becomes a problem. I do not think that senior is about the frontend or the backend or something else, but about the understanding, the reasoning and being able to foresee and avoid issues by taking the right choices (design-wise, architecture-wise, technology-wise). So, hands on experience is not required, but understanding and reasoning is. And probably, to be able to do that, one would have to have gotten hands on work at some point. From my experience, the persons I describe are definitely hard to find 😐 While I'm writing this @U0672654J already replied what I was going to say. Usually, when you get somebody that is great at the specific thing they do, you would be glad even if they're missing that part. Do they fit in my definition of senior? Probably not - but who cares? If you can trust them to deliver what was asked, without having to go into an in-depth review, then it's already a win.


so, I guess in the end, it is about prioritizing the skills and putting the weight where it needs to be (in this case, on the frontend stack; not on the CI)


“we’re not sure how to set up FE CI” -- not sure where you got that from @U0672654J?


Oh, apologies if the jovial tone didn’t translate… I’m not trying to cast aspersions, just point out how different the two needs are.


I’m sure that you all are more than capable of setting up FE CI


Yes, and it was all set up along with deployment to AWS by the FE team originally and so we're looking for a senior FE dev who can also take responsibility for maintaining / troubleshooting / tweaking that stuff for the future.

Lukas Domagala01:01:02

I would very much agree with @U8ZE1VBSS that any senior dev should have general knowledge about it and be able to make good big picture decisions in the field. I wouldn’t expect them to be able to set anything up / tweak anything on the spot though. Even in a startup where you are the only person touching that pipeline you do it so rarely that forget half the specifics by the time you are back to it. You should explicitly mention and interview for it though, since it’s sadly pretty common for devs to be missing this part. Especially with pure FE devs.


I am a lead-level engineer who primarily does front-end stuff at a very large company. I will mostly echo what Stephen said above; I think that asking people who do front-end stuff to get good at ops is kinda like asking people who are good at ops to do things like responsive layout or the like… they’re completely different skill sets and managing jenkins or whatnot is typically better left to someone whose main skills are closer to that

👍 3

I have no problem with managing CI pipelines on friendlier services like Heroku or Circle or whatnot, but if you want me to do Jenkins stuff, well, I can do it but you’ll get much better results in much less time from someone else


this tweet of mine was inspired, for example, by those attempts:


ops work and front-end work require specific types of temperaments and its rare to find both of those in the same person


I have to say that makes me a bit sad. The FE folks I've been working with are extremely capable engineers and the tools pipelines they've been working with are pretty gnarly. I don't agree that CI and cloud stuff is fundamentally incompatible with folks who build complex systems using JS. Is that really what I'm hearing from people here?


I mean, everybody tends to become a bit T-shaped with their skills over the course of their career; one area they’re really good at and some others that they can do well enough; where backend work may encourage getting to know the actual mechanics of where and how the backend code is being handled, front-end work encourages getting to know a whole host of other things like design, human interaction, semantics, optimizing for perceived responsiveness and how things run on a computer you do not control, that, to be blunt, most backend people seem to think are both trivial and somewhat beneath them


"ops work and front-end work require specific types of temperaments" -- that makes it sound like you believe that same thing in reverse (that ops is trivial and beneath you)?


Ops, FE, BE, all require attention to detail, and engineering discipline as well understanding the bigger picture of the context of that work.


I don’t believe ops work trivial or beneath me at all; I’m just not the sort of person who could do that sort of work on a daily basis and be happy, much as I know people who are really good at backend/ops type stuff that would say the same about doing frontend work


How long would it take an experienced engineer to pick up CI/CD? Probably not very long.


I still can’t get over the division of time and effort factor… if they’re a front end engineer, they’ll ostensibly spend the great majority of their time working on front-end-oriented tasks. The vast minority should be poking and prodding at CI (if you’re spending a lot of time “maintaining” your CI, your CI probably needs some real directed effort to make that not the case). If someone needs to do something in a very small minority of their time, should you interview focusing on that or should you just state “hey, you’ll need to do some CI work every once in a while… don’t worry, we’ll get you acclimated and you’ll have folks around to help out if things seem hairy”? I am sure it’s a nuanced decision, but again: I think over-selecting for a minority skill set may have you miss an otherwise great candidate for something they would only rarely have to do.

💯 2

I would like to ask here, is Next.js and similar, or more generally React (or alternative) Server Side Rendering considered frontend or fullstack/backend work? Because personally, the word Server is a hint for me, yet I have senior colleagues who would categorize it as frontend. Another thing. 20 years ago I knew no one called senior with less than 7 years experience. Maybe because of where I was coming from, but it does seem to me that people with 3 years of experience being called seniors is a relatively new thing. I even saw 2 years minimum asked for senior positions. I wouldn't expect someone with 2 years of experience to know how to setup a CI/CD pipeline.


I think JS/node has blurred the lines between front and back and that's why I would expect a JS developer who considers themselves to be senior these days to be pretty comfortable with command-line build/test scripts and, yes, I think they should be able to set up and maintain a CI/CD pipeline and be able to actually deploy their apps and therefore to know something about deployment infrastructure/cloud these days...


If you're a "purely creative", focused on CSS/HTML and using JS "just" for UI stuff and no logic then, yeah, sure you won't know CI/CD and/or cloud -- but you're likely also not to know how to automate your tests, etc either. And so to me, that's a designer and not an engineer. And that's fine too -- we all need good creative folks. But that's when I'm hiring a senior front end developer, the emphasis is on developer not designer.


I don't see the blur at all. I see a lot of bad ideas being popular though. Bad ideas in the sense that they complect things that they shouldn't. They do run on node, but this is not node's or js' fault 😄


I was agreeing with you 🙂


so perhaps I’m a bit unclear about what you mean by “ops work” and “setting up CI/CD” because I haven’t yet met a frontend dev who wasn’t serious about automated testing or making sure that managing the sh*tshow that is modern javascript build systems are automated


I don't understand your apparent aggression toward "ops work"...


As I said, our FE team set up CI/CD and deployment to AWS and haven't managed all of that. That's the "ops work" I'm talking about.


So I guess the next question is "what do you call all of that if you don't call it ops?"...


(that's a serious question @U053V4R5N -- I'm finding this whole thread very strange and frustrating)


> I can do it but you’ll get much better results in much less time from someone else Is speed the most important factor? I wouldn't mind people being slower with what they perceive they are good at. Most lead js devs I see nowadays only follow convention, not science and there is no talking to them. > I don’t believe ops work trivial or beneath me at all; I’m just not the sort of person who could do that sort of work on a daily basis and be happy, much as I know people who are really good at backend/ops type stuff that would say the same about doing frontend work Arguments that boil down to "I am different than you, or that other person" are only good for distancing ourselves from solutions. I would say, if you could do only the work that makes you happy and ignore every other work, that would be quite an unhealthy situation. OTOH, I never liked AWS and my 20 year experience wouldn't help me to configure a full CI/CD setup in it just by myself, I would probably make a big mess. Jenkins was way more straightforward 😅


my perspective might be colored by my experiences, which include people who primarily do infrastructure management dismissively saying things like “oh you can just make some changes to our (20k LOC) helm config” or without any kind of warning “we added you to the on-call rotation for kafka, what do you mean you haven’t set it up yet”


First one I experience a lot. The second kind of attitude would be problematic in any circumstance. Expectations need to be communicated explicitly and clearly. Not that js land isn't full of situations and leaders where the out of the box experience is assumed as the de-facto solution and any kind of question is only relevant as long as there isn't some out-of-the-box solution possible, because in case there is, it should be used.


My career growth has also stemmed away from pure software engineering, I work primarily on internal tooling that is often low-resources/high-impact and often am just the person who “runs the project” and simultaneously play the roles of UX Design/PM/UI Design/FrontEnd Dev/Backend Dev


"people who primarily do infrastructure management" -- this is why I think it's a good thing for developers to do more of this -- more "devops", less "ops". Silo'd IT teams is nearly always problematic.


helm in particular is incredibly bad design


meanwhile the attitude I’ve encountered from a lot of the same people is, “Oh you’re just rendering some HTML, how hard can it be” or “why would it be hard to make it work well on both a phone and maximized on my 42” ultra-widescreen?”


I certainly don't have that attitude -- while I may dislike JS and its ecosystem, I am in awe of what our frontend engineers achieve given how complex (and fragile) the whole panoply of browsers and devices seems to be.

Drew Verlee03:01:43

I feel like the question your asking is "how much can i expect to pay" for that additional knowledge coming in? Do you need them to hit the ground running with insights into your specific tooling?

Drew Verlee03:01:00

If on the other hand, they have time to learn that tooling, then make it clear that's part of how they can help the company succeed and you need them to do it. Then make it worth their time to stay so you don't lose their expertise to a competitor.


I think it's less about money than attitude, if I got it right, lots of 'senior' frontends turn out to outright refuse to even discuss the possibility of doing anything but the most conventional thing. It's great if you want 150 people churning out questionable quality code. Not for much else.


Yup, much more what @U0VQ4N5EE is saying than what you're saying @U0DJ4T5U1

Drew Verlee04:01:45

I'm saying if they know it matters and are rewarded for doing it well they can and will learn. A lot of systems wonder why things fail, but the give next to no incentive to have them succeed that users can meaningful track.


My team reviewed 30 resumes today. And that has reinforced what this thread seems to have indicated too: there are a lot of FE devs who have zero experience in automation or deployment... and that's just wrong for me.


@U0DJ4T5U1 Software engineers understand this and know this matters. FE, BE, whatever. That's what a software engineer is.


The easy on-ramp of HTML has produced a raft of FE "developers" who really aren't qualified to do anything.


I've been lucky to work with some great FE engineers. But today reminds me that they're rarer than I'd like.

❤️ 1

My suspicion is that it' mostly the 'labor market' doing things. No one who doesn't want to has to leave, the best people move the least, and those with the least experience are on the market for the longest time, so they will be overrepresented in any list of job applicants. I still believe it's better to hire for long term someone who is willing to learn, independent of anything else, than expect people to know everything ahead of time. Been saying this for a very long time, but most companies don't even consider the idea of directed, prompted knowledge transfers within themselves. Even when large companies do this, it's often just a support track for career advancement.

👍 1
Lukas Domagala13:01:49

@U04V70XH6 I’m curious if you had any applicants that know cljs and if they had the same short comings? I’d suspect that knowing more than one language would be a great indicator for a broader knowledge base in general.


No applicants with Clojure/Script experience, but a lot of JS devs who also have PHP (and still no automated testing etc) 😞


Some with RoR who seem slightly better (but mostly seem to be products of coding bootcamps)