Paul Carleton tells his story of joining Google out of college, leaving Google for a startup, and how he ultimately has ended up at Stripe, an online payments company in San Francisco where he is an Infrastructure Engineer.

Unlike most of our guests so far, we decided to focus on:

  • how engineering interviews are structured at different companies
  • how Google handles candidates who formerly worked there that re-apply
  • why you should always bring your laptop to onsite technical interviews

For the full text transcript see below the fold:

Audio:

Play in new window || Download

Video:

Max: Hey, guys!

Today we have the pleasure of Paul Carleton joining us. Paul is an infrastructure engineer at Stripe.

You’ve held roles at Google for several years. You left to join a startup called Judicata in the legal space. And then, most recently, you left Judicata to join Stripe, in San Francisco as well.

You went through your job-seeking round most recently, and discovered a ton of tools that you used. And you got exposed to “what are people actually asking in the job market” these days for different roles.

I know this is further back, but I think people are very curious about what is Google asking these days? What’s the hiring bar for getting a job at Google these days?

Paul: Yeah. I did an internship at Google when I was still in college and then converted to full-time. I did the phone screen for the interview, and then had to do some interviews at the end of my internship.

And actually, a funny story about that: they told me during the internship, “You’re gonna get two interviews and they’re gonna be strictly technical questions, the kind of thing that you would see, like in ‘Cracking the Coding Interview,’ basically,” like the Gayle Laakmann book.

They said they were gonna be specifically those questions, or like those type of questions. Because sometimes you get design questions or sometimes behavioral, but mostly just design or the coding ones. And my first one was like that, you know, it was like a linked list, some sort of linked list…

Max: Algorithmic.

Paul: Yeah, exactly. And then the second one, the interviewer said to me, “Oh, why don’t you just tell me about your internship projects?” And I was like, “Oh, sure, yeah.” So I drew it out on the whiteboard and told them all about it. And then a couple weeks later, after my internship was over and I was waiting to hear back from them, they said, “Oh, only one of those interviews counted because the guy asked the wrong question.” So I had to fly out to…because, like, I went back to school and started in school. They had to fly me out to Seattle to do another interview. I actually chose Seattle because I actually wanted to interview at Microsoft and Amazon too.

Max: Oh, my God.

Paul: I ended up having a Monday, Tuesday, Wednesday…

Max: Back to back to back.

Paul: Yeah, with Microsoft, Amazon, Google interviews. It was just a funny situation.

Paul Carleton shares his software engineering interview experiences

Max: Well, one of the things I knew about you that’s kinda…I don’t know if it’s unique, but you’ve interviewed three times between your internship, interviewing for the full-time role, and then, most recently, when you left Judicata, you considered going back to Google and they put you through the same hiring process that any other experienced hire would go through. So what was the most recent experience like and how long ago was that again?

Paul: That was in March. And the way it happened for Google was, once I left Google they had a person called like the alumni coordinator who was in contact and said, you know, “If you are interested in coming back, reach out to me.” And so I did reach out to him when I was deciding to look for my next role, and they said, “Okay, if you wanna come back we have a couple of different options depending on whether you wanna come back sort of at the same level of responsibility. If you think that you’ve progressed in your career, then maybe you can interview.” And I was like, “Sure. I wanna interview more. Why wouldn’t I try to go for, you know, a higher-level responsibility?”

I ended up interviewing again in the San Francisco office. And yeah, it was kind of a funny experience because when people looked at my resume… you know, usually in the Google interview you come down and you sit down in the conference room and they have your resume and they talk about that a little bit, and then they get right into like a technical question. They’d kinda look at it and be like, “You’ve already worked here.” They asked, “Why are you thinking about coming back?” And, “Why are we interviewing you again?” Because it was just kind of like a strange…like, “We know that you’ve already passed this bar, so why are we having you go over the bar again?”

Max: Were they worried that you already knew the questions they’d be asking you, or…?

Paul: They didn’t say that, but yeah, one of the design questions was…I remember it being like, “How to ask a design question,” that was the one…

Max: It’s pretty formulaic.

Paul: Yeah.

Max: Sure, yeah.

Paul: That was kind of funny. But yeah, they’re all really nice about it.

Max: It sounds like the questions they asked you the first time around were the same questions, or similar in nature, with the whiteboarding and the system design type of questions as the second time around that you went through their hiring process or whatever.

Paul: Yeah. Definitely, Google is very much on the whiteboard. The second time around, they were more focused on design questions. So I think I got two design questions and one coding, algorithmic one. Whereas the other time, I think it was all algorithmic.

Max: I know when we’ve previously chatted, you had a wealth of advice and resources that you used in the most recent job search. Besides going and doing interviews and getting the practice of having interviews under the belt, do you mind sharing how you prepared for the most recent job interviews you did?

Paul: Yeah, definitely. I was fortunate…I decided early to save up and take time off in between jobs rather than try to interview while still holding a job.

Max: That can be rough.

Paul: Yeah. You’re trying to explain why you’re gone for a day or a couple hours for phone screen. Anyway, I decided just to take some time off. So I had a lot of time on my hands and I, fortunately, after talking to the Google alumni person, knew that I kind of had a way… you know, I felt pretty comfortable that worse comes to worse, if nothing else comes up, then there is a way for me to go back to Google.

Max: Which you ultimately decided not to do, which we’ll hear that story later, but…

Paul: Correct. Yeah. Sorry, I’ll start…

Max: No, no. You were mentioning how you had a lot of free time and you found, or came upon, a lot of extremely valuable resources for preparing for this round of interviews.

Paul: Yeah, definitely. I had started…in previous rounds I had always gone back to “Cracking the Coding Interview,” which I feel like is the interviewing “Bible.” So I set up a bunch of time and I said, “Okay, I’m gonna spend…” I think I said I was gonna…I wanted to spend 20 hours doing questions before I do my first interview. Because I said, “If I have the time, then there is no reason for me to not do that before I go to this first interview.” Because otherwise, you know, what am I…to not putting this foot forward?

I had started doing that, and I think I saw it either on either on “Hacker News” or something, I remember this site called interviewing.io, which is a site that will…you sign up for it and they’ll pair you with somebody who has interviewing experience at a company that does this kind of typical tech whiteboarding sort of interview, so they’ll pair you, and it’s anonymous. And then they’ll run through a question with you, and then at the end they’ll give you feedback, like, immediately, while you’re still on the phone with them. Then also, they’ll give you written feedback after that.

Max: Is this over the phone, or is it webcam, or is it screen share, or…?

Paul: Yeah, it’s all on your laptop. I think you can you can dial in with your phone, but it was…yeah, it’s like CoderPad. I think they kinda integrate through that.

Max: Sure, it’s an interface where it’s real-time text.

Paul: Yeah, real-time text…

Max: Google Docs, or…sure.

Paul: Yeah, and I think you can execute code, and it kinda depended on what the question was like. So I signed up for that, and actually they were in private beta so they were not…or I don’t know. So anyway, they had a waiting list, and so I didn’t get in it. And they actually recommended me to go to as service called Interview Cake, which is this site. It’s sort of a self-guided interviewing practice tool where it gives you a bunch of questions and it’ll kinda start you off…and if you’ve done technical questions, you know there’s a lot of layers to them a lot of times where there’s like the first… there’s a couple of key insights you need on each of these questions and then you kinda get as far as you can. Sometimes it’s sort of layered, so that way, you know, if someone…there’s always further to go and you aren’t just like halfway through the interview like, “Oh, I guess we’re done.”

Max: I mean this is common to a lot of technical interviews, is have more problems in case the candidate gets through a lot of it very quickly.

Paul: Yeah, exactly. This tool Interview Cake is a tool that basically does that in a web page where they’ll give you the question and then they’ll say… you’ll type in your answer here, and then they’ll give you nudges of like, “Have you check for this thing? Have you checked for this thing?” Almost like someone would do in an interview. I thought it was crafted very well, in a way that mimicked the actual interview experience of the nudges that you would get. And the nudges where you see the question and you’re like, “Oh, I haven’t…oh, shoot, there’s a whole area of this problem I hadn’t really thought about, and I should look at that.”

Max: Well, you were mentioning interviewing.io and Interview Cake, and the thing that you told me before recording that I found really interesting is that interviewing.io’s model is actually–once you feel adequate enough with your interviewing practice–their placement into employers is…they’re a recruiting agency of sorts.

Paul: Yeah.

Max: I guess they might take some recruiter fee for placing people who are now well prepared for interviews and won’t waste employers’ time.

Paul: Yeah, yeah. Actually, it’s really good. I think the way it works is once you have an interview where it has rated you high a couple times…I think you have to have three interviews is the minimum, and then you have to have some sort of rating of, like, they think you’ve done well enough. Then it moves onto this phase of matching. So they’re pretty early [in their existence], so I’m not sure…they may be changing a lot of…

Max: Their model. Sure, sure.

Paul: Yeah, but that’s how it worked when I did it. And yeah, it was super cool.

Max: Something that you told me, also, just before we started recording was about how in your most recent job search you applied to Facebook, and at Facebook they have the author of “Cracking the Coding Interview” on their team as a contractor to help train candidates.

Paul: Yeah. Yeah, it wasn’t that clear to me exactly what their relationship was, and I think this was relatively new because it seemed like it had only been going on for so long. But basically, it seemed like every Wednesday, I think, they would host a session that you can either attend in person or, you know, on BlueJeans, the videoconference. And it was, yeah, the author of “Cracking the Coding Interview,” Gayle Laakmann, giving a slideshow presentation and going through questions. And for interviewing, it was super helpful because it’s basically if you’re an interviewer, what you wish every person you’re gonna interview had spent the time doing. So it seems like they were just like, “Well, we’ll just…”

Max: That’s crazy, man. Why do you think they do that? Why do you think an employer is hiring a consultant to assist their candidates with their interview format?

Paul: Yeah. It seems like maybe they could just change the format to not need that.

Max: Yeah. Exactly, exactly.

Paul: Yeah. I mean I imagine it’s just because that interview format is so common, it seems like it is a pretty common format at least across the companies I interviewed with in the first round.

Max: Yeah, the big ones like Google, Facebook, and you’re now at Stripe.

Paul: Yeah, actually…yeah, I’ll talk about that in a minute. But Stripe, actually, was a very different experience. But yeah, I imagine that they did it just because they wanted to have a candidate put their best foot forward. Because even when I’ve done interviews in the past, there have been a couple times where I’m interviewing someone and it’s clear that they just hadn’t really gone through the format recently. And it’s like a muscle. You know, it’s like if you haven’t exercised recently, it’s not gonna work out well the first time you go out and try to do it in front of people. Yeah, you’re kind of a out of practice.

Max: Well, does Google offer anything like this for candidates?

Paul: They send out like an informational document that pointed you to some resources, but they didn’t offer anything to the extent of, you know, “Here’s the…”

Max: Bringing on, like, a contractor.

Paul: Yeah, like “the” name in coding interview.

Max: That’s goofy, and it’s crazy that this is engineering specific. I think it says something about the job market and engineering that employers, albeit among the biggest employers, are hiring outside contractors to help their candidates train for their interviews. I mean yeah, like you said, maybe the format should be changed. But any idea why Facebook might not be doing this for their marketing candidates that apply for jobs?

Paul: I imagine the interview format maybe doesn’t lend itself as much to the kind of practice that the technical format does. I mean, obviously, I haven’t gone through that at a different…most of the interviews I’ve had are the technical formats, so I’m not exactly sure what would be beneficial. But I do know that, for technical interviews at least, there is sort of this base level of practice or familiarity with the format that is kind of…almost like a leveling effect of, if once you’ve got that base level, then it’s like, “Okay, how good are you past this base level?” Whereas there could be someone that’s really good that just hasn’t practiced enough or hasn’t had experience with the format, and you totally miss the signal on them and that’s kind of unfortunate.

Max: Well, I mean, you chose to accept a role at Stripe and you just mentioned how their interview process is different. So maybe, with not disclosing the secret sauce, now that you work for them, you’re interviewing candidates potentially, and so you know how reverse engineerable interviews are, but do you mind sharing just how they’re different from Facebook and Google?

Paul: Yeah. It was actually really refreshing, and actually it was funny. I had interviewed at another company that was mimicking Stripe’s interview format. So I actually got the same format twice! But anyway, the format there is there’s almost no whiteboaring. The only time I was on a whiteboard was for a system design, and I think I could have done it without going to whiteboard if I didn’t want to. But I like drawing, like drawing the little circles and arrows, I guess.

Max: Sure. Who doesn’t?

Paul: Yeah. But the rest of it, I brought my own laptop and they had coding questions in whatever language I…I chose Python for this. I was coding on my laptop and sharing my screen with them. So I could use an IDE. I could Google things if I wanted to. So very much…yeah, like it was…

Max: When you’re using your own laptop, you have a lot of familiarity with the tools that you use like an IDE or…that’s something I’ve noticed with interviewing candidates is that it’s helpful to lean towards inviting the candidate to bring their own laptop because providing one, as an interviewer, is an alien environment and it lends itself to disaster and a whole lot of wasting of time.

Paul: Yeah, definitely.

Max: But this was over a screen share, you were remotely…

Paul: Oh, yeah. So the phonescreen, it was over screen share, and then I brought my laptop to the in-person interview.

Max: Did they encourage you to, like I just described, or…?

Paul: Yeah, they said, “Please do bring your own laptop. If for whatever reason you don’t have one, we can share one.” Which is, truly, like for me, actually my work laptop was my like, you know…

Max: Only laptop.

Paul: Yeah, it was my primary laptop. My personal laptop was kind of like…

Max: Oh, man, you don’t wanna…

Paul: …old, kinda junky one.

Max Mautner (left) and Paul Carleton discuss why you should bring your own laptop to technical interviews

Max: You don’t wanna interview for a job using your current employer’s hardware.

Paul: Yeah, exactly. Definitely. Like yeah, that would be very bad. Which is funny, though, because generally you set up your environment on your work laptop to be great, and then maybe not so much on your personal laptop. So you do have to remember to go set up your personal laptop in the same way.

Max: But what were the questions like? You mentioned walking through…it sounds like programming.

Paul: Yeah. There were a couple different formats. One of them was a bug bash. That was the coolest one. So you would go through an actual open source project, and this is on like Stripe’s login thing, so it’s…

Max: Public information.

Paul: Yeah. They would have a bug from an open source project in whatever language you wanted it, and you would go through and find…basically it’d be an issue that someone has submitted to the project, and you would have to go through and figure out what the issue was and try to solve it in this hour-long block. Which is very cool because you had to navigate through this code base and if it’s an open source project that has a lot of traction, it’s a big code base, and trying to dig in, it does sort of mimic what you’re doing in your day-to-day job. So yeah, that was one format, which I think was the hardest one because there’s definitely a set point of like, “Did you solve the bug?” I later learned that there’s–like a lot of interview questions there’s a lot of room to judge progress along the way. But at the time it was like, “Ugh, I gotta fix this thing,” you know?

Max: Closing a bug can be incredibly hard on an open source project, I mean besides submitting a pull request to the project. Trying to reproduce the bug, if whoever submitted the bug didn’t share information about how to reproduce the bug…yeah. Even getting your development environment set up for certain open source projects can be tough.

Paul: Yeah, you have to pull the project down. Yeah. They had selected certain bugs that were amenable to this kind of stuff.

Max: Okay. So they had pre-screened what bug you might be working on?

Paul: Yeah. So it wasn’t as, you know…

Max: Jank or “real world”. Okay, so that was one type of interview, was the fixing or closing an open source issue.

Paul: Yeah, that was one. There was one where it was integrating with an existing system. I think they had the system, and they were basically like, “We want you to add some functionality to it.” I’m trying to remember exactly, but that was basically the format where you basically have an API endpoint and you have to integrate some code to interact with that endpoint and do something useful, which is kind of similar to real life coding.

And then… I’m trying to think. I think there was one other…yeah, there was one that was purely system design. That was one where I was on the whiteboard, and then there was another one that was more…it was called “pair programming” and it was supposed to be working together to solve this problem. It ended up–that one looked a little bit more like the typical whiteboarding, but instead just on a laptop. Because it’s pair programming, but your partner in pairing knows all the answers. So it was more…at least that’s how it felt in my particular case.

Max: Oh, for sure.

Paul: I’m not sure if that changed.

Max: Oh, yeah. One thing I’ve been asking folks who come on as guests is about your current employer’s tech stack. So programming languages, frameworks, whatever other technologies you guys are using, because by and large this is public information. If you look at people’s jobs listings they generally include what types of skills they’re looking for, but I think this is an interesting topic for a lot of our audiences. What programming languages are used at Stripe, what database softwares are being used at Stripe, that sort of thing?

Paul: Yeah, definitely. We use a lot of Ruby, and I was coming from a Python background.

Max: At Google or Judicata?

Paul: Judicata was a lot of Python. Google was mostly C++, actually, which coming in was very intimidating because I don’t like C. But it turns out, C++ at Google especially, they’ve kind of taken off a lot of the sharp edges of C++ and it feels a lot like Java, or you know, less scary language. Because I feel like C++, you know, you have like…

Max: Memory management.

Paul: …allocating memory, yeah. It’s like, it can get kind of crazy. But yeah, so…

Max: Ruby and…

Paul: Ruby, and there’s some Go we do…Ruby is the main language we use and then some Go. So for database technologies, we use a lot of Mango. Yeah, that’s kinda our main stack. There is some Scala for data pipeline and analysis stuff.

Max: I’m realizing just now that we didn’t even really go over what type of role you hold at Stripe. So it’s given that you’re an engineer, but what team do you work on there, and what’s your role there?

Paul: Sure. My team is called “delivery”. So it’s an infrastructure team and we’re the interface between the rest of Stripe and our actual servers. So our VMs, basically. So we handle instance management and provisioning these machines, and then getting the code from people’s laptops to the actual machines, and that kind of thing. So ideally they wouldn’t have to know, you know, how the cloud management stuff works and they won’t have to go on the AWS console and type things in. They’ll be able to use our tools and not have to think about that. So that’s kinda my team’s role in [Stripe].

Max: What is the tool chain kind of look like? You guys probably use Git and have some type of continuous delivery, continuous integration pipeline. I don’t know if this is public information, but do you mind sharing what softwares you guys use there, or services if they’re third-party?

Paul: Yeah I’ll have to double-check what is public.

Max: Okay, okay. I mean, are these all services, whether internal or external, that you interact with using Ruby for the orchestration, or is it entirely third-party service where you as a Stripe employee or the people who work with your team on delivering software go to a third-party website and orchestrate things from there?

Paul: Yeah, it’s mostly managed in-house. We don’t own our hardware, so we’re using VMs. So we don’t do any of that kind of super low-level stuff.

Max: You don’t drive down to San Jose?

Paul: Yeah, right.

Max: Got it. Okay.

Paul: Yeah, we don’t. The rest of the stuff is mostly…a lot of places will have cloud-hosted versions where instead of using it on their machines, they’ll license you a version that’ll run on your VMs.

Max: Got it. Of course. So you guys are a payments handling company. Using third-party servers to manage payments data and credit card data is probably a non-starter. So you guys pay licensing fees to these services that are otherwise publicly known.

Paul: Exactly.

Max: Like, running them on your guys’ virtual machines.

Paul: Yeah.

Max: Okay, got it. Sorry to tread into territory that…I don’t know whether it’s public information or not. But I think it’s…

Paul: Yeah. I’m sure most of it is. I just don’t wanna, you know, accidentally say…you know.

Max: Oh yeah, sure. I think one other topic that would be great to hear about from somebody who’s worked at Google, at a startup, and now at Stripe, is how does that delivery process look different from Google to startup to Stripe? Even if we don’t cover what technologies or services you guys are using at Stripe, maybe even how long did it take to deploy software at Google versus how long did it take to deploy software from making a change on your laptop to it appearing in front of customers’ faces?

Paul: Yeah, definitely. At Google I was on Google Analytics, and it was a weekly release that we would do. And you know, I’m sure it’s a completely different process at this point. So yeah, it would take a week, and so if something went wrong in that week you’d have to roll back and then everyone would be mad at you. So I remember on, I think it was Tuesdays, our rollout, and we had our like… I’m not sure what the name…I think it was like a technical program manager. It was this group of people that were managing the release process, basically, and they knew everything that was going out and when things broke. I remember they sat in this particular part of the office, and they were coming out on Tuesday around deploy time, and if they came over to your laptop or your desk, it probably meant you broke something.

Max: There’s gotta be a better way to handle this.

Paul: Well, they were pretty urgently trying to figure out what the fix was. So they’d be like, “Okay, hey, like what…” You know, they’d be trying to figure it out.

Max: Oh, my God, dude.

Paul: But whenever you saw them coming out, you’re like, “Ohhh…darn. Better start looking at what I deployed this week and see.” Because hopefully you were already pretty comfortable with what you were deploying. But if they were coming out, definitely it was like, “Uh-oh. Did I flip the flag this week?” So, a lot of flag-based…a few feature flags, which is…

Max: Where you can turn on a new future just when you want to, and turn it off when…

Paul: Yeah. Google was really big on that. They’ll have a bunch of feature flags, and then you don’t actually have to rebuild the code. You can just turn it of with the flag again and turn it back on. You don’t have to recompile anything. So it’s easier to say, “Okay, this thing broke. Let’s flip it back to what it was before.”

Max: So you were at Google two years, and then you joined a startup?

Paul: Yeah, very different deployment.

Max: How did deployments work at Judicata?

Paul: So yeah, we did a continuous deployment. As soon you pushed it, it…

Max: And passed tests.

Paul: Yeah. You would merge it and then it would get deployed as soon as it passed. Passed, like we would do a UI test after we merged. And then assuming that all went well, it would get pushed right out. So it was like rather than thinking, “Oh, I need a plan two weeks in advance in order to get something out the door,” because you usually have a week in QA, and then a week before like…yeah, so this was instant. It was a very different feeling because, especially, just having so many fewer people. I mean Judicata was, I think, 12 people when I joined. And compared to Google, even just a back-end team was, I think, over a hundred.

There’s many different teams that are working on this overall product, and then it’s there are boundaries into other products, and so it was just this massive organization. And, yeah, just pushing out code was just so much faster. So many fewer processes because you didn’t need as many processes to manage. You know, there wasn’t as much risk of stepping on other people’s toes. So then at Stripe I’ve been joking that I did a Goldilocks thing where I went huge company with Google with a lot of engineers, down to very small with Judicata at 12, then Stripe, which was sort of middle of the road with hundreds but not, you know, thousands.

Max: At a hundreds of persons company, how many employees work on delivery?

Paul: Yeah, my team is 10 right now. It’s funny because at Google the continuous testing environment had a whole staffed team with sub teams, you know, this whole organization.

Max: Well, for those who are interested, Google’s testing blog is really interesting. There’s a lot of really cool stuff that comes out of it. One of the interesting tools I saw recently, and this might not be so new, is doing a UI diff to recognize regressions in CSS. Like, you change something or break something about a button that people need, and acceptance test will detect that that button isn’t there anymore, and maybe it’s the “save” button for Google Docs.

Paul: Yeah, pretty important. Yeah.

Max: That was an interesting innovation in testing, and it might have been an older practice that I just recently became aware of, but the Google testing blog is really interesting. Given that they have a lot of employees that probably have enough time to write blog posts for the rest of us :)

Paul: Yeah, definitely. Yeah, it’s always interesting going from Google to outside of Google where it wasn’t always clear what was a thing that Google did or if there was an open source equivalent that somebody did outside of Google? Or maybe something even Google open-sourced, and it became public.

Max: Are there any best practices that you don’t mind sharing about Stripe’s software development lifecycle that didn’t exist at Judicata or Google?

Paul: I think that Stripe’s at the point where there are processes that were made when it was a smaller company, and it’s growing rapidly. So we’re kinda at the point now where…reassessing a lot of these process and saying, “Which of these still make sense and which of these need to kind of be re-thought from a perspective of, oh, now, this is a very different set of constraints that we have.” So I think…yeah, I don’t know if that’s really like a best practice per se, or something, but just like…

Max: Re-evaluating.

Paul: Yeah, constantly re-evaluating and…I heard this saying recently that was “looking for orange extension cords,” which was this phrase where if you first join the company and you go into their office space and you just saw an orange extension cord running across the floor, like to plug some light, and you’ll say, “This is really weird. I’m tripping on this. Why is this here?” Whereas everyone else at the office has already said, “Oh, I can just step over this. This is normal. Yeah, exactly, like, “What are you talking about? I don’t even see this anymore.” So that kind of thing where, especially coming as a new person to a company, you can provide a lot of value like, “Wait, this should not be here. We should fix this.”

Max: Oh, for sure.

Paul: Yeah, I would say, constant re-evaluating. But also, if you’re earlier in the game, don’t spend too much time over-optimizing too. Because I think it’s very easy to say, “We need this process to be bulletproof.” But really, if you’re smaller…like at Judicata our testing was good but we didn’t devote an entire group of engineers to improving it because it just wasn’t necessary.

Max: Oh, for sure. This is a topic that often comes up at startups is why write tests if no one’s paying you yet? I mean this is not the case at Stripe, but may have been the case at Judicata, is that it’s more important to get features in front of customers than it is to guarantee that your next push won’t break ‘em.

Paul: Yeah, yeah. If nobody’s on your site, then if it’s broken, then that’s not…

Max: Yeah. Would you say that over your career so far that you’ve gotten better at testing or knowing what to test?

Paul: Yeah. I think it’s honestly been a lot of…I think testing is really a cultural thing. It’s sort of like if everyone on your team is writing a good test, then you’re gonna also write good tests. So if you’re at a culture that doesn’t have good tests, then you kinda have to be the one to say, “Hey, let’s write some tests on this.” Every now and then I’ll say, ‘Oh, I’m gonna do test-driven development,” where it’s one of those things…because I really like [strongly] typed-languages because they make you feel… you know, they’re like a blanket. Like, “You’re okay. This is gonna work out.”

Max: That this won’t break in production.

Paul: Yeah, exactly. There’s this appeal of testing and development, “Oh, I have tested everything. I have full test coverage. This is all great. But I don’t know, I think you have to fit the tool to the problem. So I think, generally, writing tests, especially if you’re fixing a bug, writing something that’s gonna say, “Oh, did I actually fix a bug?” is pretty important. But sometimes, if it’s a configuration change to…especially now that I am doing more infrastructure work, some of the stuff is a little bit tougher to test. And I think it’s partially because infrastructure work, the tooling around it is evolving. I think testing around that will be easier as time goes on. But it’s more difficult to…you can just poke it and say, “Okay, it worked.” You know, “I changed the port, and the port is open now, that works.” You know, but testing that is…

Max: Not worth it.

Paul: Yeah, something like that.

Max: One of the things I’m curious about from the style of interview that you encountered at Stripe where you worked on an open source issue and try and submit a pull request is whether you’re expected to write a test to prove that you’ve fixed whatever bug it was.

Paul: The issue, you weren’t actually submitting it to…your solution, you wouldn’t submit to the project because there was generally a bug that had already actually been fixed.

Max: Ah, this has been presented to more than one candidate, potentially?

Paul: Yeah.

Max: Got it.

Paul: Yeah, and it was a problem that would have already been fixed in the library, upstream, and been merged. So yeah, Stripe isn’t sitting sitting on a bunch of bugs that they have a fix. That would be kind of bad :)

Max: That would be pretty douchey, yeah.

Paul: But yeah, I think there was something like, “This bug has been fixed, but just don’t look up the answer or how they fixed it because that’s gonna ruin the interview.”

Max: Sure, sure.

Paul: But yeah, I mean as part of it, you were kinda supposed to reproduce it. I can’t remember if there were steps involved, or, “You should probably do these in this order.” But it was less of like, “Write a bunch of unit tests to show that you did it,” but more, “Can you prove that you actually fixed it?”

Max: And be able to dig down and identify where the root cause of the problem is and…

Paul: Yeah.

Max: Okay, dude, these kinds of insights into interview processes are super interesting to our audience because a lot of people, honestly, don’t go out into the job market that often and get the kind of simple size that you most recently got interviewing with Google, Facebook, Stripe, others. So this is priceless, honestly. I was gonna ask you about what, specifically, might be different about working at a payments company? I totally blanked when I started asking you semi-proprietary stuff about delivery and what third-party services you guys use. But having worked at these three different companies, are there specific security oddities to being at Stripe where you’re handling customer credit cards and payments that you didn’t have process-wise at your other jobs?

Paul: Definitely. There’s different concerns along different companies. At Google, we’re always concerned about PII, so personally identifiable information. So on Google Analytics, we’re tracking people’s traffic across the web. If they put their social security number in a tag, then we’ve gotta get rid of that which I think things of that nature would be something to worry about. And also, we always had to make sure that we weren’t crossing streams of data where we had the Google data of like “You signed into Google,” and we had the analytics data, which is particular to a site. And we can never mix those because that would violate anonymity of someone browsing the internet.

Max: The worry there from Google is the existential threat of the big fist of government coming down on Google.

Paul: Yeah, I don’t remember exactly. Definitely that, but…

Max: I think the regulator in this case that Google’s worried about is the Federal Trade Commission. Because I know the Federal Trade Commission enforces stuff like advertisers disclosing that their content is paid, which is a big deal for Google. If you know the search engine ads, Google AdWords ads and search results have to be distinct from organic results. And the reason that’s the case is because US regulators require it. Although, through A/B testing it’s gradually started to look like AdWords results are almost identical, to the naked eye, to organic ones.

Paul: Yeah. I remember there was a discussion when the color became…it was like it used to be very dark blue, I think, behind…or maybe even yellow around all of the ads that would precede your results, and it has steadily gotten less distinct as well.

Max: Oh, yeah. And in some cases, for some really high cost keywords, your entire above-the-fold search results are paid.

Paul: Yeah. It just looks like credit card…it’s like, yeah.

Max: Oh, yeah. But that type of regulation is different than…like advertising is differently regulated than PII of payment information because there’s a lot of opportunity for fraud, for stealing of direct money, as opposed to indirect money. So what are the PII obligations that impact the engineering team at Stripe?

Paul: Yeah, there’s this whole…the value that Stripe has is that you can accept a credit card and Stripe will handle…or make it a lot easier for you to be what’s called PCI compliant. And that basically means that if you store, like, a raw credit card, like somebody gives you, like, even like a picture of like a credit card and it has a credit card number on it, as soon as you have that on anything, any hardware that you own or manage, there’s like a whole set of compliance requirements. And so what Stripe does is they let you not have to worry about that by the credit card numbers never touching your servers. They go straight to Stripe. But that means that we have all those requirements and we have those requirements for a lot…you know, we have a lot of…

Max: Customers.

Paul: Yeah, a lot of customers, a lot of credit cards that we have to, you know, not leak. You know, obviously not leak, but like not…they all have to be compliant with these pretty specific requirements.

Max: When you started at Stripe was there an onboarding process specifically for educating new employees, no matter what role you were coming on, about these requirements?

Paul: Yeah. I mean it’s pretty core to Stripe’s story, I think, especially from the early days of why Stripe sort of was this innovation is that a company could start accepting payments and not have to, you know, study deeply the PCI rules.

Max: Oh, for sure.

Paul: There’s definitely a lot of…, the onboarding was around the story of Stripe and what PCI entailed and why it was nice to not have to deal with it, and then what that meant for Stripe. Like, you can imagine if credit cards were just flying around and on laptops or wherever, that would be bad. So generally there are tools in place to make it so I don’t have to worry everyday like, “Oh, shoot, did I accidentally get a credit card…does my laptop now have to be under strict compliance?” These kinds of things. So yeah, there’s generally tools around it, but yeah, there was a lot of onboarding describing why this matters and why we have to be careful about these things.

Max: One of the things I’m curious, now that we’re on the topic of PCI compliance and fraud, is if you guys are not solely domestic in the United States, but do you get any exposure to working on international infrastructure problems as an infrastructure engineer?

Paul: A little bit. Yeah, we are, you know, moving money in many different countries and there’s a lot of different banks and banking partners in all these different countries and dealing with all of them is a complicated problem, but mostly that is…

Max: Complicated is putting it politely.

Paul: Yeah. I mean I don’t interface with that directly, so I don’t see too much of that.

Max: For sure, for sure. We’ve covered a lot of ground. I wanna save some for the next time that I imagine us talking. It has been tremendously helpful advice, I think, for people who are considering jobs at any of the companies that you’ve worked at before, or are maybe at Google right now and are considering leaving to join a startup, or just preparing themselves for the job market and interviews and that sort of thing. So dang, thanks. It’s been awesome.

Paul: Thanks for having me. Yeah, it’s been great.

Max: I appreciate it.