On May 21, for the Test in Production Meetup on Twitch, Yoz Grahame, Developer Advocate at LaunchDarkly, moderated a panel discussion featuring Rebecca Murphey, Senior Technical PM at Indeed, and Ben Vinegar, VP of Engineering at Sentry.
The panelists shared about their own backgrounds and career paths, how the scope of front-end engineers is evolving and becoming more operational, how hiring managers like themselves evaluate front-end engineering candidates, and more.
Watch the full panel discussion below.
FULL TRANSCRIPT:
Yoz Grahame: Excellent. Hello. And welcome to Test in Production for May 21st, 2020. Thank you for joining us. Today, we are talking about how to become a better front end developer, or how to find one if you're hiring them. Our guests today are two superbly experienced front end engineers, and with several books, and many, many talks between them. We have Rebecca Murphey, senior technical lead at Indeed.com, and Ben Vinegar, VP of engineering at Century. Thank you both so much for joining us today. [crosstalk 00:00:39].
Ben Vinegar: Happy to be here.
Yoz Grahame: Thank you. Thanks so much. We're looking forward to this, especially you're both so experienced with front end and you've both had already long and distinguished careers, if that doesn't make you sound too old. And to start with, I'd like to find out more about those, what the important steps were in the journey to where you are today. Let's start with Rebecca. Tell us when you started, but what was your journey here like?
Rebecca Murphey: It's been a very long journey. It starts with dropping out of college and working at a newspaper for five years, doing desktop publishing. And took some very winding paths to my first job writing code, which I think I started doing in about 2006. And that was in the very early days of JQuery. I was working for a really small agency that did a lot of Flash ads. And I was like, "Hey guys, we could write this JavaScript instead. On the web." And it was a really exciting time.
I've taken a very winding path. Today, I am a senior technical project manager at Indeed. And I've been there for about four years. Prior to taking on the tactical project manager role, I was in a senior engineering manager role. The technical project manager role was actually pretty new. But as the engineering manager there, I grew a team from zero. Well, one, if you count me I guess. A team of me to a team of about somewhere between 20 and 25 software engineers. Plus product, QA, [inaudible 00:02:22] et cetera. All focused on trying to level up Indeed's front end engineering capabilities.
Rebecca Murphey: Hopefully I can share some of that experience today.
Yoz Grahame: Fantastic. Thank you. That is quite a journey, and it especially shows that people can come from sometimes quite nontraditional backgrounds. Although still, you started in engineering, but doing something quite different than you're doing today. Ben, how about you?
Ben Vinegar: Yeah. For me, the path to front end engineering began with, I don't know, just went to college, studied computer science. I just wanted to make video games, which I think is how a lot of people get into programming early in their careers. "I want to make video games." My first jobs were writing C in assembly. I was working on graphics drivers for video cards, which is pretty cool.
And then I saw a presentation, actually about the same time, maybe around 2005-2006. A presentation on Ajax and Ruby on Rails. It was like a local agency who was dabbling in those technologies kinds of presentation, on campus in Toronto. The University of Toronto. And I was so blown away by what was possible. I think they were showing a demonstration of, Rebecca, if you remember this, like Endless Pageless, where instead of having to paginate and the server, you keep clicking one, two, three, four, five, and the server generates new responses, you just keep scrolling and the browser just keeps refreshing new content.
And for some reason, that blew me away. And I just started getting really into web development. I picked up Ruby on Rails, and the path to JavaScript for Ruby on Rails is that you wrote, even back then, you didn't even write JavaScript, you wrote Ruby, Ruby on Rails, and generated JavaScript to do your Ajax C fun things. And that turned into just started to write JavaScript. I joined a PHP shop, which didn't have these fancy tools for generating JavaScript from the service side. A company called Fresh Books. Worked there.
And then came to the Bay Area around 2010, and really just did JavaScript and front end development this whole time. And then more recently joined Centuries, or went to a management role.
Yoz Grahame: Right. Again, that's quite amazing, doing drivers for graphics cards. Sound remarkably low level compared to jumping up and down, different ends of the sack in terms of complexity. Or is there actually a lot in common there, would you say?
Ben Vinegar: Well, you're plotting pixels. I'll take some [crosstalk 00:05:10] from Rebecca, right? I think that there's ... why did I get into graphics? Because I like to visual ... there's like this sort of visual medium to programming that interested me. And I think that getting interested in web development and front end development, into product design, is sort of related, to some extent. I think that the interests are connected. Maybe the technologies are different, but the end goal, the desire to just plot pixels and good experiences are the same, if that makes sense.
Yoz Grahame: And that's great. It's the theme there, of having a continual ... a thread of principle, of what interests you, of what you're trying to achieve. It reminds me of Brett and Victor's famous inventing on principle talk, about having a single set of concepts that you're trying to achieve through premiere. Rebecca, would you say there's ... the various topics you covered, and I was looking earlier, at the talks you've given. There are so many and they cover so many different things. Can you think of any particular guiding principles or motivations that have carried you through your career?
Rebecca Murphey: I think kind of similar to Ben. The structured presentation of information, and building systems that can help you with that. Even back to my desktop publishing days, and when I was working in an advertising agency and doing desktop publishing there. You had some people who were building things. They were doing it on computers but using tools very similar to what you would use before there were computers. Rulers and squares, and those sorts of things. In high school, I had one of the actual photo cropping tool. Not the picture of it in Photoshop, but the actual one.
Yoz Grahame: Oh yeah.
Rebecca Murphey: When I was doing high school yearbook. Truly, this concept of how do we take these kind of manual processes and turn them into structured and efficient delivery, presentation delivery of information? Yeah, that's been a theme in my career since, I don't know, coming up on 30 years now, before I had a career.
Yoz Grahame: It's amazing too, to that, because it's on one hand, it could be so simple, and yet so continually elusive. We've been surrounded for hundreds of years, with good examples of simple and effective visual communication. And yet we are still, even more [inaudible 00:07:53] examples, of how to get it wrong, and how we continue to get it wrong.
Rebecca Murphey: Yeah. And I think it's been really interesting too, like making getting it right accessible to more people. And that's in a scene, especially in my recent group too, of you shouldn't have to be experts in front engineering to ship decent, at least, user interface. And so thinking about how do we make that possible for people, to be successful, without having to have a decade or two of experience.
Yoz Grahame: Right. And you've both done so much in that regard, in terms of educating, in terms of giving talks, writing books, things like that, to make this topic more accessible. As well as working on ... we were talking about JQuery. Earlier. Both of you have worked on stuff around JQuery. Rebecca, you hosted the JQuery podcast. And Ben, you've written at least one JavaScript, and contributed to several others. And JQuery to me, is one of the best examples I've ever seen, of a tool that takes something that's potentially incredibly complicating, and simplifies it in a way to make it far more accessible. It's amazing, the amount you can do with JQuery, with despite knowing hardly anything about programming, which I think is absolutely to its credit.
Yoz Grahame: It used to be that you could achieve a whole lot in front end with a relatively small set of tools, assuming you knew them pretty well. And hope that's the case, but how do you see front end engineering as having changed over time? Especially what do effective front end engineers need today? Rebecca, start [crosstalk 00:10:02]?
Rebecca Murphey: I think it depends on so much on your ... Ben and I were talking about this yesterday, how I know for me, my understanding of what front end engineering even is has evolved over the years. Not just because front end engineering has evolved, but I've gone from working in a tiny agency, that basically had three people working at it, to a slightly larger agency that had a few more people in it. And then a startup that had a few more people at it. And now, at Indeed, which has ... I've lost track. I think 10,000 or 12,000, working not on engineering, of course, but it's the biggest company I've worked at.
And so I think front end engineering is different, depending on the nature of the organization that you're working at. Not just where you are in your career, but what you need to know if you are at an agency, say building lots of linting cages and micro sites on very tight timelines. You bring a totally different skills than if you're working in Century, with Ben, where you are engineering systems that will be used by other people, and they're never done. They go on forever and ever. And there's no deadline of ... I'm sure there are deadlines. But there's no date when you're like, "All right, on to ..." you know, Century is working on a product that's such a different experience.
I'm not answering your question so much as just saying it's a really hard question to answer, because the answer varies so much based on the nature of your work.
Yoz Grahame: Yeah.
Ben Vinegar: Here's ... if I could jump in, I feel like, one, I'll add one topic that seems to come up, I'm sure Becky knows, boy, wasn't it easier ... like all these tools are so hard. Why can't we just go back to JavaScript and HTML? Let's talk about JQuery. Before JQuery, I was just sort of handwriting JavaScript. And you'd write JavaScript, and everyone was using Firefox at the time. And you were like, "Hey, it works great." And then the moment you put that out there, someone on 9X4 goes, "Uh, this does not work at all." And you spent such a colossal amount of time just writing even special code paths for different browsers.
And then JQuery shows up and it's like, "Hey, what if you didn't have to do that to like a huge degree?" And yeah. It just sort of blew your mind. And that just made everybody's lives a little easier. And I would argue that even JQuery has probably been almost like the inflection point for where people started treating this as a career more seriously, because if it did feel a little bit like you were just slamming your head on a wall all day, [crosstalk 00:13:06].
Rebecca Murphey: I think it's also interesting about back then. I don't know about you, Ben, but when I was working at that little agency, you would write your code and you would open up your FTP app, and drag a file from your desktop into production. And so the active deploying code, I think part of that was the nature of it was a tiny place, and part of it is the nature of so much more has ... we didn't com- we still don't compile, but we didn't compile. There was no build-step. Yeah. So much of what exists in today's tool chain wasn't there.
And so it was easy. It was also, in hindsight, really freaking scary. And that's where there were so many opportunities to make decisions that effected your user's negatively, or broke the site, or whatever. And I feel like some of this is [inaudible 00:14:11] and some of this is just the tools that exist today that just didn't exist then, especially around front end.
Yoz Grahame: That's a great way ... I hadn't thought about that, but that's fantastic, because as Ben said, a lot of people have complained that things aren't nearly as simple and easy to get started as they used to be. But it's not so much that there's more complexity. It's that the complexity has shifted from repetitive toil, which can be messed up very easily, to preemptive configuration and setup, things like CI pipelines, where pack all that stuff, that.
Ben Vinegar: Also, nothing is stopping you from building a website.
Rebecca Murphey: That was what I was going to say.
Ben Vinegar: Like we did 10 years ago. Nothing is stopping you. And yet [crosstalk 00:15:00].
Rebecca Murphey: Frankly, maybe more people should be building websites. Like they may not need to react. They maybe could just write [inaudible 00:15:07] and not even SAS. Just in CSS. And maybe a few lines of vanilla JavaScript. Yeah, I mean nothing stops people from going down that path. But the reason that you don't go down that path, at the scale of Century or at the scale of Indeed is because it's unsustainable and the toil is immense. And it doesn't work at all for collaborative environments, where people are contributing code. And people on other teams are trying to change your code. You need to have confidence that they're not going to break it.
The tooling in the front end ecosystem is complicated, but has enabled us to work at scales, and deliver products that couldn't even comprehend in the absence of that tooling.
Ben Vinegar: Yeah. I'd also say, let me tackle one more time, so many people talk about how [inaudible 00:16:02] accessible the tooling has become, but I think actually, Rebecca, we probably agree, that the tooling has actually only made the whole field and your ability for what you can create so much more accessible. Now, there are less foot guns to shoot your foot off, because we have these incredible CIC processes. We have linting tools. We have typescript and types in JavaScript. And all these things feel like a burden at first, because you have to learn them, but the reality is they just reduce an untold amount of toil in the end.
Yeah. They are saving you from yourself. And again, organization size matters here a lot. Some of these tools do not make sense in certain scenarios. But at scale, it's impossible to live without them.
Yoz Grahame: Yeah. And I can see how ... I'll say I understand why people complain, because you're missing the immediate feedback, when you get started, and you want to be able to just throw something at the [inaudible 00:17:03] and see it work. And that's not a shallow thing. That is a hugely valuable, continual rapid feedback loop that you get when you're learning this stuff. But you can still have that, as you say. Before we move on, just to say to our audience, thank you for joining us. If you have any questions for Rebecca and Ben and I, we're happy to take them.
And continuing on the theme of, as we mentioned, what teams today need, what developers, Ben, to be a front end developer on your team, you've got the various built tools and things like that, that you're using. What else? What are the practices, perhaps over less technical or at least front end specific, are needed to do ... the way we talked about it yesterday, was pushing pixels to production. What does it take to get your pixels all the way to production, that aren't to do with front end specific tools?
Ben Vinegar: That don't have to do with front end specific tools? What are they ...
Yoz Grahame: Maybe some tools, but the ones that are more focused around a large production organization, so the aspects of the pipeline involving working with other people, to do with the version control and [crosstalk 00:18:33].
Ben Vinegar: Oh yeah. Oh yeah.
Yoz Grahame: Things like that.
Ben Vinegar: I'll put an asterisk on this, I could talk about our experience, because Rebecca and I spoke earlier. And so Rebecca is working in a company where maybe they're trying to make it so there's less things that you need to know, so that the opportunity for contribution is more open. And I think every company is trying to do that too. We're trying to do that to a degree.
That's a broad question. I mean, ultimately, knowing JavaScript is pretty helpful. I think where I see how the tooling has changed things is that it's probably less critical. It's less critical to be like a whizzbang front end engineer, who knows all this minutia of how the UI thread works, and how browsers function, because tools like React make it so you ... earlier, we talked about JQuery and we talked about how that made things easier. Advance four years, to 2012, 2013, 2014.
I was certainly doing a lot of work with Backbone. And Backbone was a little helpful as well. But what it still made very challenging was you had to propagate state from your client side application into pixels, into dom elements. And that was a lot of work. And to do it in a way that made really great experiences, you had to know a lot of minutia about the browser, and how it works with the dom, and so on.
And React, why has React and other frameworks become popular? It's because they've introduced a paradigm where you don't need to know that. Sure, you need to know that you're rendering DIVs and spans, and all that stuff, and a link is an A-tag. But if I render 1,000 items, is that going to block the page? Certainly not to the degree that you needed to before. What I'm saying here is I think it's honestly, a focus on programming is becoming more important than just understanding how to be a good programmer. You do good code reuse. How do you lay out architecture and things? And less about the minutia. Rebecca?
Rebecca Murphey: I think I would say it depends. It depends on what job you want. If you want to be working on React, well you better know that stuff, if you want to be working on React. And the team that I work on now, we are building a micro front end framework for use of Indeed, where new people can independently deploy pieces of the user interface, that are then assembled to compose the whole page. And if you want to be on that team, actually a number of people on that team, we explicitly ... we don't need you to know about front end engineering. We need you to know about distributed systems and systems at scale. That's what we need you to be able to think about. We also need one or two, actually incredibly well versed front end experts, to understand where all the dragons are in a system like that.
And so, on the one hand there are those teams, where actually you need that depth and detailed experience, and you've got to just spontaneously be able to spout out how cookies work in strange scenarios, and you just have to have this encyclopedic knowledge of front end engineering, which is really hard. On the other hand, the users of that system, like Ben was just talking about, we are trying to make it so if you know HTML and CSS and can read instructions about which buttons to click, and you are decent at React, then you can be really successful in a system, like Ben was saying, without having to have the deep and nuanced and knowledge of front end minutia. It depends, again, on what path do you want to go down, what skills you actually need to be acquiring, I think.
Ben Vinegar: Would you say that those roles, those are becoming the new staff engineers at a company, in the front end space?
Rebecca Murphey: Yeah. The people I think, who end up in those roles, are necessarily senior. Interestingly about them, they tend to also have non-front end expertise, or at least be able to participate pretty well in those conversations. And so once you describe all the attributes of these people, you are talking about somewhere between staff and principle kind of engineer folks. And so there's very few of them. You don't need a large number of them, even at a company our size.
Yoz Grahame: Would you say though ... because it sounds like what we're talking about there is increased specialization, in that there's more of a focus on certain things, like in particular, each team needs smaller groups of expertise, or smaller domains of expertise per individual. Do you find that ... it's always interesting to ... have either of you been in a position of working at a large organization, where you can be fairly specialized, and then switching career to a much smaller org and suddenly you find yourself having to relearn a whole bunch of stuff you haven't touched in years, because you're the only one?
Rebecca Murphey: I am petrified of that experience. No. I've honestly only gone larger and larger over the course of my career. And as a thought exercise, I sometimes consider what would it be like, even just go back to being an individual contributor at my current company, versus being in a manager role. I haven't had that experience. I've talked to people who have had that experience, who've gone from being executives to being the only coder at their startup. And it's a fascinating journey, but I have not had it.
Yoz Grahame: It's fascinating as well, in terms of in choosing ... there's another aspect of specialization here I want to touch on, which I've seen change in front end, which is with each phase, each set of new tools, we get new things to learn about as a topic in the domain. I mean, there's front end, but then you're talking about Rails. And Rails, famously was the first really accessible framework to be based on MVC, and taught everybody about MVC. And similarly, the different kinds of ways of thinking about structure and things to care about.
And so we've seen other topics as well steadily increasing performance. Things like performance ... sorry, so the increase in priority. Performance is one, that gets more and more focus. Accessibility, thankfully is one similarly, getting focus. And for those, do you find that it's ... where is the balance in how much an individual needs to know in respect to where they are in front end? How much of these different topics does the individual always have to know, and how much can you leave to the experts? Sorry. That was a very general question. I suppose, I wonder if it depends on the different topics [inaudible 00:26:12] question, and where you see those splits.
Ben Vinegar: You brought up this sort of what should you know, what should you need to know. And I think when we're hiring at our company, I don't think that we're very fixated on, hey, does this person have the explicit experience of our stack or whatever. We're probably looking for broader experience and fundamental ability above all. And I think a lot of companies do that, and that's why are interested in that, and that's why, love them or hate them, some interviews are oriented that way.
For example, I know Century is a single page application, written in React. And we did that in 2015. And I'm actually really excited when we get someone who's been working on Angular for a couple of years, or somebody who's working on Amber, because I like unique perspectives that they bring from that ecosystem, because every framework has good ideas. There's a reason why people are using them. They're all a little bit different. And so to actually have people come in and bring what they know is really valuable. Go ahead.
Rebecca Murphey: So many things that I'm wanting to jump in. I didn't mean to cut you off. I think that what you said, about you're not looking for ... that you're excited when you see Angular and Amber folks come in. Yes. Oh my gosh. We explicitly ... I explicitly am never looking for how well you know React. I'm looking for like how did you contribute to your company, how capable are you of evaluating trade jobs and making decisions. And maybe you have been working in an Angular for the last five years. What's terrible about it? Maybe you've been working with React for the last five years. What's terrible about that? I'm wanting to know, if you can see all sides of technical decisions, and be able to evaluate those trade jobs. That's what I'm really, really eager to see with them when I'm considering somebody.
The other thing I'd say is [inaudible 00:28:27]. I need to know accessibility. I need to know that when you need to know accessibility, you're going to take that really seriously, and then get up to speed on it. Whatever it is. It's accessibility, it's performance, it's React, it's View. I need to know that you have demonstrated, that you have the ability to learn new things, when they're hard, because there's still lots of hard stuff in front end. And I would say performance and accessibility are pretty high on that list.
Yoz Grahame: Yeah. And that's a great point because a lot of people say ... I hear this more and more from engineers. And this is really useful advice when it comes to hiring decisions, is that we care less about tons of existing knowledge than the ability to learn quickly. But Rebecca, I think the other point you threw in there, which is I think even more vital, is the ability to make decisions, the way to communicate and to evaluate different options, possibilities, and tools, and then make an informed decision, which you can also communicate well, and persuade people of, is surprisingly difficult and so valuable. Thank you.
What else ... on the topic of what we look for in hires, you've got ... and I know there's a continual ... there's all these people looking to hire front end engineers, but is there are those who are experienced and some make the mistake of looking for people like them. And those who aren't experienced and don't know what to look for. What have you found that is maybe ... you know, the general top advice around ability to learn and ability to communicate decisions and evaluate well. Are there more front end specific skills or qualities that you look for? Rebecca?
Rebecca Murphey: I think that, and this all depends on the seniority of the person that you're looking at. You know, for somebody who is really genuinely looking for a hunger for learning and a hunger for taking on new challenges, I don't really care about the ... if you are interested in front end and have some nominal aptitude for it, cool. I care much more about do you have the tenacity, do you have the initiative. Will you raise your hand when you're stuck or will you go disappear for three days and keep telling me that everything is fine? Not that that ever happens.
I think for junior folks, it's really it's about tenacity, initiative, and ability to learn. And the specifics aren't that important to me. For more senior folks, I am looking for how do you decide things, how do you influence things, what's the last big project that you worked on, and do you understand why you worked on it, and what did you screw up? What would you do differently the next time? What was the business rationale for this? Was it a pet project of yours that had no value to the business, or did you increase clicks on widgets by so many, that you made a million more dollars? I'm looking for kind of product sense as well.
On the technical side, I'm looking for the more senior you are, the more I want to know that you can function across the stack. Not necessarily that you are good at the whole stack, but that you can at least talk about and understand and participate in conversations about the whole step, participate in conversations, like how are we going to get these pixels to production? What are the risks in shipping these pixels to production now versus later, and this way versus that way? And understanding stuff like CICD, and build tools, and how servers work, and how DNS works, and how your whole system is going to fall over because there was an earthquake in this place over here, or whatever.
The more senior, the more I'm looking for understanding operational concerns that can effect the front end, but often extend back into the operational layers of a system. Then I'm also, on the front end side, I'm like do you understand asynchronicity? Do you understand that's ... yeah, you don't usually run into senior folks who are failing at that, but wanting to make sure just do you understand just some general things at JavaScript? That's pretty important to me.
Yoz Grahame: Yeah. The conceptual leap to realize that things don't always happen in the right order that you expect, can be a major one if you don't know how to deal with it. Gets [inaudible 00:33:35]. Ben, how about what do you look for in ... what do you maybe look for, when ...
Ben Vinegar: Well, I'm reminded why ... oh, we may have lost Yoz here for a little bit. But I'll jump in, what I'm looking for. Why I'm reminded why me and Rebecca get along so well, because I think I agree with most of what she just said. You highlighted two things already, like junior folks and more senior folks. And it's like on the junior side, you're looking for talent, tenacity. I really like the word, 'tenacity.' That's going into my lexicon. And I think it ...
I do want to make a point about why whiteboard interviews or interviews can sometimes feel ambiguous, and like why am I asking this, this isn't what the job is going to be. There is a misconception that people, like hiring managers, are looking for you to solve exactly the whiteboard exercise, and know exactly what it is. They're actually trying to understand how you're solving it, and they're trying to figure out things like tenacity. When you see an ambiguous problem, do you get upset and say, "I can't solve this"? Because from a hiring manager's perspective, they're going to think, "Well gee, when I show this person another ambiguous problem, that's probably going to look more real in the future, are they going to have a similar attitude?"
And so if I had a bunch of people interviewing, it's to take those exercises, try your best, and just try really hard, and demonstrate to somebody who is trying to evaluate you, like, "Hey, I'm going to try and meet the challenge. And I might not get it, but that's okay. But I want to at least demonstrate that I'm going to try and meet the challenge." And then of course, we see here, that I agree, that the conversations ... well, you've got more of a career behind you, and there are expectations that you can speak to these very specific things that we need you to do.
I don't know [inaudible 00:35:43] can probably speak a little bit more specifically, about even our interview process a little bit. But what we do have is we do have specific roles open for front end engineers occasionally. And there is a specific track for that role, that includes a combination of take-home exercises, specific interview questions for that. And some of them are experience based. Not trivia, but our expectation of what somebody in a senior level, front engineering role should know. One of those things are like prototypes, or even fundamental language things. Do you know how to manipulate objects in non-basic ways, for example?
Yoz Grahame: [crosstalk 00:36:32]. Ope. Sorry, go ahead.
Rebecca Murphey: I want to say, on the ... I'm just thinking about take-home exercise. I love to see how people engage with a problem that is reasonably constrained, because we don't want to take up too much of their time. It's reasonably constrained, but there's a lot of room for a lot of decisions. And so do they invest heavily in the UI aspect of it, but they got the algorithm for collision detection off of stack overflow? Like how do they [crosstalk 00:37:07] is it okay, do they say that they got it off of the stack overflow? I want to know that.
But also seeing how where they invest their time, I think, is a really interesting ... it's an interesting signal. I wouldn't say it's a hire or no hire signal, but it's a really interesting thing to see, where people choose to spend their time. How much they choose to invest in, say, code organization, on what's ultimately a toy project. And again, there is no right or wrong answer. That's just fascinating to see, and can give you kind of launching points for more conversation about, "I see that you spent a lot of time on this, but how does it behave if I do this weird thing to it? Do you know? Did you try that? Did you experiment?"
I personally love those exercises. I personally also want to find a way, to make them really equitable, I guess, so that you aren't asking for something that is very possible for some people, and very not possible for other people, to complete in their free time. But I love the signal that you can get out of them, just as far as learning more about that person, knowing what to talk about after that. And I'm sorry. That was a lot more words than I meant to say about that, but I [crosstalk 00:38:45].
Yoz Grahame: That touched on so many interesting things. In particular, I think the last one about how do you make this equitable, with these kinds of interview processes and challenges, bearing in mind, that we have very different quantities and qualities of spare time to do this kind of work, and do it effectively. But also, the environment of it's so difficult to get people problem solving effectively in an interview room, because your mind is in a very different state. Your emotions are in a very different state.
And this actually leads into something else I wanted to ask you about, which is when you're on the other side of the table. When you are being interviewed or when you're applying for a job at a company, and a lot of people forget that it's a two way street. You're not just being interviewed. You are interviewing the company, to find out whether you want to work there. In your experience, when you have applied at new companies, when you've gone for interviews, are there things that you now specifically look for or ask about? Ben [crosstalk 00:40:08]?
Ben Vinegar: Not actively interviewing. I feel like I can answer that question more from a place of experiences where I didn't ask those questions, and why I originally regretted it.
Yoz Grahame: [inaudible 00:40:22]. Yeah.
Ben Vinegar: Yeah. I took a lot of them for granted. This is actually a good topic, because I think we can't just go through an interview process ... everyone is so concerned about saying the wrong thing. You're kind of on eggshells. If I ask them a question, will that offend my interviewer, so I'm just not going to even approach it, right? And for what it's worth, if it all goes well, you can ask those questions later for you don't ... you can always ... let's say you have an offer in hand. You can always talk to someone. They're going to be very interested in answering those questions for you. If you don't want to ask them in the middle of the interview, that's very fair.
But some of those questions should be like, "How do I get pixels to production," if I were a front end engineer. I think that's a really good question. What is the process when I make a commit or I make a PR, what happens? Does someone need to approve that? Who needs to approve it? How many people need to approve it? What does CICD look like for you all? What does unit testing, what does integration testing look like?
At Century, we do sort of visual dif acceptance changes, which I've really enjoyed. And I think that that's a little bit more novel now, or probably is more novel, certainly than it was six years ago, when people were adopting it. But it's actually, I think it's made my life easier, to just know, "Oops. I've changed the spacing everywhere, as a result of the change, let me roll that back." And knowing that you have those sort of guard rails, is again, I want to treat those empowering for the developer who joins the team.
If you take all those things for granted and you just join a company, and you're like, "Look, they have a great website, of course they do this stuff," and then you walk in through the door and find out that actually, you're going to have to FTP all your files onto a server, that's going to be a really stressful place to be, and maybe you don't want that job.
Rebecca Murphey: Yeah. I would echo that I have heard that a great thing ... I have never done this and I probably should have, but a great thing to ask is, "What is the process to change a line of text on a website?" And that gets into not just the engineering work, but all the way up. Like whose permission do I need to make a change in the website? What is the decision tree that influences that?
I also will, and if I ever interview again, will ask, "What's the process for buying a 0 book?" Because that can be another kind of ... it speaks a lot ... and that has nothing to do with front end engineering, but it has a lot to do with quality of life.
Yoz Grahame: Oh yeah.
Rebecca Murphey: I think the other thing I would say about this, and I think it's so fascinating how Ben's answer goes to the fact that there's nothing super unique here about front end engineering. Front end engineering has just become software engineering, with just maybe a preference for this side of the stack. If you are really looking for a role that is your job is going to be HTML, CSS, and JavaScript, making sure that the place that you're interviewing with has that job, doesn't just have that need today or tomorrow or next week or next quarter, but that they have that job for the long haul.
And understanding that will there be a steady supply of that kind of work, because we have teams at Indeed, who one quarter they're extremely focused on something that's really UI intensive. And then the next quarter, maybe they're making changes to their data model, or to their logging and infrastructure. It all depends on how different companies work. Like different companies work different ways. My last company, we had a team that was all front end all the time. And so there was a steady stream of work. But understanding that, about how the team that you're going to is operating, and understanding if that intense specialization is really important to you, understanding that there's a path to keep doing that.
On the flip side, if you're looking to ... like you're bringing intense specialization but you're looking to branch out, is there a path to that? Because if you're joining a solidly front end team, maybe not. It's understanding that. I think all this goes to the other thing Ben said, of talk to the hiring manager. Don't just talk to the recruiter. You've got to talk to the hiring manager. And really, my poor boss, I made him have lunch with me so many times before I said yes. I really poked and prodded at is this going to be the right place for me to land.
Yoz Grahame: It's worthwhile doing that, because the thing is, they're asking you to dedicate several years of your life.
Rebecca Murphey: Potentially, yes.
Yoz Grahame: I think it's worth a few lunches.
Rebecca Murphey: Yes. What were you going to say, Ben? I'm curious as another hiring manager, how do you feel about candidates demanding to have lunch with you until they say yes?
Ben Vinegar: Yeah. I think what was I trying to say, is like this is the industry secret, is that we will go have lunch with you.
Rebecca Murphey: We will go have lunch with you.
Ben Vinegar: But I don't like ... you know, I don't want a flood of people to tell me that or to ask me that, but it's true.
Rebecca Murphey: But also, you made the point of offer in hand. This is not necessarily your opening gambit, of, "Let's have lunch." But I think it is. It is, it's a place that you're going to spend a chunk of your day, and it's really important to understand who that person is, what the team is, how they're going to support you, and how the company is going to support you, and understanding what the nature of your work is going to be, because you can make some really bad assumptions about that.
Yoz Grahame: We're coming up to time, but before we go, any particular, immediate red flags for you these days? Because it's interesting, just worth the point saying, something, it's a twitter thread I saw, friends of mine saying of the number of things that you want from a new employer, have they grown or shrunk over the years. And the best answer I saw was, "They've shrunk, but I'm holding them much more firmly." You know, they mean a lot. What are the things that you care about most, that if you saw would immediately say no?
Rebecca Murphey: As a candidate or as a ...
Yoz Grahame: As a candidate. As a candidate, yes.
Rebecca Murphey: As a candidate. I haven't been in this business, in the candidate business, in a long time. If somebody wasn't willing to ...
Ben Vinegar: That's a really tough question for us to answer.
Rebecca Murphey: Yeah.
Yoz Grahame: Okay, let me ...
Ben Vinegar: What I would say is that, listen, a lot of candidates ... you know, resume stage is a real thing, where someone at the end of the day ... I'll give you an example. I think we had 2,000 applications for some new grad roles that we opened up. We had two of those, have to make a lot of decisions at the resume level, for that. It's just if you just do the math there, that's the reality sometimes.
Yoz Grahame: Absolutely.
Ben Vinegar: I don't want too many people to say, "Hey. What? I have to go up against 2,000 people." I'd say this is an outlier. We're talking school season, all that kind of stuff. But there is a reality, is that hiring managers often have to make a decision at the resume stage, so I do think that it is worth putting effort into your resume. That doesn't mean having to go and have a completely unique template for everything that you do, and a whole bunch of emojis, whatever.
But when it comes to the resume, I think one of the most impactful things that I want to see, or that I think hiring managers want to see, is they want to see if you do have previous experiences that speak to the impact, if you're using language like, "I worked on this." That's not going to inspire a tremendous amount of confidence in a hiring manager. And again, if it's a stack of 1,000 resumes, and you see some that are using wishy washy language about their participation of a project versus someone who is like, "Hey, well ..." I'm trying to think of a super specific example of, "I changed ... I drove some project to put all of our static assets onto a new CDN, with a expiry cache that's all of a sudden the experience was twice as fast for users." That's just a made up kind of thing but yeah, Rebecca, look at how she's nodding when she hears something like that.
Yoz Grahame: Oh yeah. And it's the impact, in particular. The [inaudible 00:49:25] impact is so valuable.
Ben Vinegar: Yeah. I personally think everybody ... a lot of people do themselves a disservice. Like they're doing work like this, but they're not describing it that way, or maybe some people want to speak even to the breadth of things that they do, and so they include like 20 bullet points, about just everything they've touched. But honestly, I'd rather have five anecdotes like that, than to ... that make sense?
Rebecca Murphey: [crosstalk 00:49:55] though. It makes tons of sense, and it's very ... we are of the same mind here. But I wonder, how much of that is because of the nature of the companies that we work at, and the size and scale, and that we are product companies? What you just said is so important at a product company. At an agency role, I might care a lot about the technologies you used, and how fast you got stuff done, and what unreasonable pressures you tolerated without blinking an eye. We don't care about those at a product company. At my product company [crosstalk 00:50:31].
Ben Vinegar: But you use different language there, and I would love to see that language, for example, if you came from an agency.
Rebecca Murphey: Yeah. And I think that understanding who your audience is, is maybe the point of this, just thinking about ... and again, talking to the hiring manager if you can, or talking to the recruiter and asking these questions if you can, understanding what does the company care about. That can be really different for different places.
Yoz Grahame: Mm-hmm (affirmative). And so one of the best tips, that took me a long time to learn, was it's okay to tweak a version of your resume that you've tweaked for a particular job. It does not always need to be the same thing.
Rebecca Murphey: And so much of this depends on seniority. I feel like it's hard for me to give advice to me from 10 years ago, because I'm just in a different place. Some of this is really relevant if you're looking for more senior roles, and maybe not so relevant if you're looking for more junior ones.
Yoz Grahame: I think the point you made earlier ... we're going to have to wrap up here, unfortunately. The point that I think is one of the most valuable things to bear in mind is that you're applying not just for the jobs that meets the skillsets you currently have, but also will take you to where you want to be in the future. The job where you want to be, the evolution you've got to be seeing, and that's also part of what hiring managers are looking for, that you want to see people who want to grow, and who want to succeed. You don't want peons who just stay where they're put. We don't want to hire people who don't want to think.
Rebecca Murphey: [inaudible 00:52:09].
Yoz Grahame: Right? Unfortunately, we're out of time there, but I could happily go on for another hour, if we had it. Thank you both so much, Rebecca Murphey and Ben Vinegar. Both of you are on twitter handles, and positions are on the banner at the bottom of the screen there. I strongly recommend following both of these people on twitter. They both ave written some fantastic books and given a whole load of talks. Thank you both so much for joining us here today. This has been Test in Production. My name is Yoz Grahame. I'm a Developer Advocate at LaunchDarkly. Thank you for joining us and see you soon. Thank you.
Rebecca Murphey: Bye. Thank you.
