Kyle chats with Jesse Tomchak, formerly a software engineer at WaveSeven Consulting but now at ClickUp. They talk about the YOLO vibe of JavaScript, overcoming imposter syndrome through teaching, and bouncing between startups and consulting. Bonus: A spicy take on lambdas! Why do they exist?!
Episode notes:
When this episode was recorded, Jesse worked for WaveSeven Consulting, which provides business advisory and project delivery support for media and entertainment companies.
He now works for ClickUp, same as previous Stack Overflow Podcast guest, RJ Tuit.
Read Jesse’s hot takes on his blog.
You can connect with Jesse as Jtomchak on all the socials.
TRANSCRIPT
[intro music plays]
Kyle Mitofsky Hello, hello, and welcome back to We'll Be In Touch, a podcast about job interviews, career development, and software engineering. I'm Kyle Mitofsky, a Senior Software Developer here at Stack Overflow, and today we'll be talking to Jesse Tomchak, software engineer at WaveSeven. Hello, Jesse. How are you today?
Jesse Tomchak Hooray! Hello! I'm so happy to be here. I love this show and podcasting in general, so I'm super excited.
KM Thank you so much. We're super excited to talk to you today. Why don't you just kick off by telling us a little bit more about yourself and maybe broad strokes how you got into tech and what your perspective on being a developer is. That's a big piece to chew off right off the bat.
JT So let's see. So I went to college and I have a degree in Fine Arts in photography, which, I'm sure at the time everybody told me was not a career job, like, “You can't make money in photography.” So think back like 2001-2002. So digital is starting, but all of my classes were still in film. I am that old. We had a digital class, a single digital class. These were G4 silver door era CS. We're looking at Photoshop 3 maybe, so this is sort of setting the scene. I did that and, surprise, not a lot of jobs out there for film photographers. Oh, it's so weird. So I randomly got a job at the Apple store while I kept bartending and serving and I was like, “Oh, the Apple store's a cool place.” The iPod Mini’s out, the iPod black and white, and then working there for just a couple months they’re like, “You should do Genius Bar stuff,” and I was like, “Sure, that sounds great.” So now I'm fixing computers and I'm like, “Oh, this is even better,” and writing scripts and imaging computers and doing command line stuff. A couple years later the iPhone comes out– 2007-2008, and it's like the world is different. And I was like, “Okay, I'm going to make apps.” So back then, for the younger viewers, I had to drive to the bookstore, physically go into the bookstore and get a book on iOS development. And so I started Objective-C, doing my own reference counting, no background whatsoever in programming, and I just wrote out the entire book piece by piece and made a couple apps and eventually got a job doing iOS development. So I was at U-Haul doing iOS development, learned how .NET works, because that's the stack they use on the backend. So it's like, “Hey, we have these things that you're in charge of now,” because everything is .NET, they're like, “We don't really make APIs, so if you want to call it from something that's not our server, you have to branch your own APIs.” It's like, why? They're like, “Well, because everything's session and cookie based.” They're like, “Well, I can't really session and cookie base from a mobile device, so what do you give me?” App developers at this time will remember you had to stand up all your pieces yourself because nobody else cared. Everyone else was running model lists like Rails or .NET or Symphony or something else and they're like, “We don't API.” It wasn't ever a need for that sort of thing. So I went from big enterprise to little startup, and little startups are great and you have to wear even more hats. So now it's like, “Well, now you have your APIs, but you're not moving fast enough,” and it's like, “Well, okay.” So then React Native comes out and it's like, “Well, we can build in React and we can write this faster and we can deploy without the app review in process.” So now we're pushing out bundle code over the wire live and this is amazing. We're moving at light speeds ahead, and that is how I found the web platform. So I came from over here and then moved backwards and was like, “Oh, well I could do this on the web too, and then we could write this way.” I taught at a bootcamp for several years because I was like, “JavaScript is weird.” There are rules to programming and JavaScript has none of them. It's just like, “YOLO JavaScript. It runs on everything.” I was used to XCode and the IDE and the very strict like, “Apple will give you this every year. They will give you a gift and you will like it and you will work within those gifts, those confines every year.” And then the web was just like, “Oh my God. You can do whatever you want. You can deploy it here, you can deploy it here, you can deploy versions and A/B test and you can use VS Code or Sublime or anything you want. It's all open.” I was like, “This is amazing.” So I just kept pushing into React and Angular and Ember and Vue and anything that was web-centric was just so refreshing. Back end stacks and Next.js and the meta frameworks, and so fast forward a couple years through consulting and other small startups. We worked together at a consulting firm for a little bit, and then I went to another startup and worked in Mastodon space. So we forked Mastodon and wrote an iOS app, and then I wrote a bunch of Ruby back end to create custom threads, custom feeds and algorithms to help curate some of it, and so that was a lot of fun. And so then I was big into Ruby for a couple years, and that brings us up to today. I'm working through a consultancy at AWS Prime Video and we're doing internal portals for standing up stacks. So you're going to build a web app and that web app is going to call cloud formation and cloud formation is going to build stuff and come back through the event bus and be like, “Hey, I'm all done building this now.” So it's very technical based, it's very microservice-y, there's stuff everywhere. Nobody keeps this stuff in their head. It's just a spattering of different teams doing different things. And this week I wrote YAML code, all I've written is YAML code. I don't even know if it works yet because I have to give it to the other team to bless.
KM You're handing off these YAML files.
JT Oh no, it's really good. So it gets even better. In my YAML is a cloud formation trigger function that is just copy/paste Python in YAML. It just says, “Zip,” and then I just copy my Python code and then I just give this to them and say, “Hey, will you see if that runs?” I did that yesterday and now I'm waiting till later today to be blessed to see if it actually runs.
KM I have maybe way too laser focused a question, but I have personal stake in it. Whenever I'm writing a YAML file and I need to include a script or a Python or something, the thing that is always missing from that is any type of syntax highlighting or anything. Do you have any advice there? Is there anything that you do to fix this?
JT I've been in this world for months now, and here's what I figured out is the workflow that has gotten me the best speed or bang for my buck, is to go into any AWS account that you've got and just create a blank Lambda– Python preferably because it has the virtual env, and Node is great, but this one I'm working on has open SSL calls and you can't copy binary SSL into your Node project. But Python has this really cool virtually env export binary, and it's just like, “Oh yeah, let me just wrap all this up and dump it into a thing for you,” and I was like, “Cool.” Get it all typed. I know it's awful, but the code editor in the Lambda run function, write it all there, deploy, deploy, deploy, deploy, run a test like “I have a test package” because it's a cloud formation, like cloud formation create, cloud formation delete. I run those in this thing constantly. I think my deployment number is like 84 right now. I've been working on it for like a week. And then once it's all done you just download the zip and then reference the zip. So I give them the YAML and then the zip file and say, “Here you go. Do whatever you want with this. Put it on an S3 bucket. You do whatever you want. This Lambda runs.” Ideally, I don't ever get caught on the Lambda. If it's smaller, like if you're not using open SSL, then I'll just copy and paste it in zip pipe and I'll just paste it right there and then just invent it a little bit until it's not mad at me any longer. But I will always go into that Lambda function and just write it all there and then copy and paste it out.
KM I love the narrative arc of you getting your start needing to kind of make APIs because no one's thinking about APIs, everything's a monolith. And now doing so much work in Lambda where an API is the easiest thing in the world to spin. If you want an endpoint on the web, you can have one in a couple minutes. APIs are trivial to spin up now. There's still work to do to implement them, but that's a great arc for your career and moving things closer to the web, closer to iterating more quickly.
JT Do you want my super spicy take on Lambdas?
KM I do.
JT They are an absolute abomination.
KM Okay. Defend it.
JT The work that I just laid out is all in service of running this thing. Right now, it runs in a bash script and it takes, I don't know, two seconds, but in order to run it has to have an EC2 instance. So the reason that I'm doing all of this is because there's what they call a dangling EC2 instance, because once it stands up and they run it, they don't have cloud formation to remove it so it just hangs out. And I was like, “Why don't you just have a server that you can run stuff on?” and they're like, “Well, because who's going to monitor it? Who's going to do this?” You just need one task server. So I have worked for a week to take what is essentially six lines of cURL code into an entire Python project to do the exact same cert initialization. And so when we think about Lambdas, the Lambda itself on its own in isolation is fine, but now think about all the things around it that you need, especially in AWS when we're talking about megabyte limits. How many times have you worked on a large Node project and you're like, “Well, I can't include that package because it's over the limit. I'm looking at you Twilio. It's just too big.” So now you turn around and you take five days to manually write your own dedicated API to hit the three things that you need. And now there's SSR and there's the serverless framework, and you can use a whole bunch of things to dress it up, but how do you run it locally? Serverless frameworks used to have offline local plugin, which was sort of good mostly, but you couldn't actually run the whole app. The environments don't match. And so the effort that I have put in over the last few years to work around the edges of Lambda to add an SSS queue and then get them to communicate, and the microservice infrastructure is a part-time job, whereas I would say most apps can just live on an EC2. DHH has, for whatever your values is about him, he's got this idea of just put it on a server and just let it run. Why is all this orchestration happening when you've got just this one thing over here. For all the pain and frustration of return event and step functions and other things, if you just have a server running your code, you have access to all of these things like long running code, like background tasks, batch emails, things that apps out of the gate do, running them in Lambda is an exhausting task. Now the other side of the coin, people are going to be like, “Well, but Lambdas are great if I have a blog and I just need to rebuild the thing and do the thing.” Yeah, a one-off function is great, but an application built of Lambdas is an awful task of maintenance. The maintenance cost and the connection cost I argue is greater than the business logic, which means you're not building new apps, you're constantly framing houses. You're not actually building any houses, you're just constantly setting up framework and putting up drywall and then you're out of effort. All the houses look the same now. My analogy kind of fell apart there for a little bit.
KM I get what you're going for. I'm trying to think if it's like setting up houses or like setting up tiny little things that aren't quite houses. If a server is the house, Lambdas are setting up lots of little apartments or–
JT Blanket forts.
KM Sure, sure. It's quicker to set up, but it's hard to scale them or there are certainly challenges there.
JT And so let's say the scale thing is always something–
KM Well, sorry, I should say scale kind of horizontally across. If you want a million blanket forts, you can get that really easily with Lambda versus on your fixed house that has walls and constraints and a size to it.
JT But even then I would push back and say I feel like we've solved that problem too. I am not what I would call an expert at DevOps, but even I can blindly get through a load balancer and move that one instance into four instances behind a load balancer and take on 1,000x traffic. Now, am I on the front of Hacker News all of a sudden and I need 10,000x traffic? That's a special case and you can deal with that. We've got plenty of caching and other things if you've got Redis. What is it that you're doing that you need at any moment 50,000 instances of your Lambda, not to mention the billing for cost, the billing for ingress, the billing for bandwidth, the billing for inner bandwidth. The project that we were working on at Mammoth, we had like a $400 AWS bill and it wasn't doing anything ever. There was some stuff in S3. That wasn't even where our Mastodon was hosted. It was hosted on OVH on a VM, auxiliary stuff was on AWS and it was still an egregious amount of money. So that's my spicy take. I'm tired of deploying individual Lambdas over and over and over again to no avail.
KM Great spicy take. Let's change gears a little bit and just kind of talk about, you kind of mentioned when you were talking about how you got into tech coming to now, lots of different technologies that you've touched or worked on over the course of your career. How do you kind of balance specialization in a niche technology versus kind of having this very broad stroke or understanding multiple different technologies? How have you personally balanced that?
JT This is actually one of the reasons why I left the startup and went and taught at a bootcamp. I had a real deep feeling of imposter syndrome. I was a jack of all trades, I could do a lot of things okay. I could get things done up, but I didn't have a deep knowledge of any of it. I could piecemeal it all together and this little part right here, I'm not exactly sure how it works, but mentally I could brute force a working solution. Was it elegant? No. Was it performant? Absolutely not. But it worked. I could get part one done, but two and three were beyond my capabilities at that point. And so I felt a real need to, I don't understand at a deep level enough about JavaScript and the ecosystem and the web and the dance to explain it to somebody. I had read Kyle Simpson's little books, You Don't Know JS. I had read them all and I thought, “Kyle goes out and teaches and he is what I would consider a foremost expert in the language itself and the heuristics around it,” and I was like, “I'm going to go teach.” So I got a job at– it was Coder Camp and then it became WashU University, but it was a ground bootcamp. So people would come in and we had six months and we would be in the classroom for three months, for 90 days. We would go from, “This is a webpage. It's made up of HTML, it's got JavaScript, it's got tags, it's got CSS, file systems, your code editor, basic JavaScript syntax, CSS, syntax, libraries, React.” We would bring you all the way up to React and build, at the time it was create React app with, it must have been a Node back end. But in three months we would get you from “Hello, world,” to auth, apps, hooks– hooks were starting there, but events and how to save state and how to push state up to the thing. And then they would go to do groups and do a capstone, so I would work in the classroom for most of the morning and then the afternoons I would work with the groups on what their projects were and things like that. And then after about 18 months, I had all sorts of questions. People come in because we would have to go over this as a keyword in a JavaScript, like, “What is the relationship to this?” And people are like, “What?” So you distill it down into the four possibilities of, at the call site, we're going to look backwards, we're going to see what's happening in all of this stuff. And you get these questions of like, “Well what about in this scenario?” and I was like, “I don't know. Let's type it up.” I had it ready to go. We would just type it in and be like, “I don't know. Let's see what happens. What do you think's going to happen?” You'd be like, “Oh, that's not supposed to happen.” And then I would have to find out why so that I get to explain to everybody else why that happened, and it was usually the next day. It'd be like, “Okay, so I worked on this last night and this is why JavaScript did what it did.” It's always doing what it's supposed to. As soon as you understand that, you're not arguing with JavaScript anymore, you're learning about what it's doing. It's never wrong. I'm always sort of doing it backwards. So as soon as you internalize that, life gets a lot easier. And I learned so much, different ways of going about it and different ways of talking about the ecosystem and how things go and how to put things together and beginner questions, things that we don't really think about much anymore. Kyle had always talked about all the JavaScript he had forgotten is more than a lot of people ever get to. I think he got a lot of static for that, because humble bragging, but he's been working on JavaScript for like 20 years. That's a pretty easy thing to be like, “Yeah, he's probably forgotten a lot more than most of us ever know about the core language,” which is really small. But to go through those over and over and over again, the beginner steps and go back through it and start from zero, really gave me a deep understanding of that. And then you start to get the itch of product building again. You're like, “Okay, I want to really build a product and really get into that.” So from that deep knowledge, you focus on what you do really well and hope the people around you can fill in where you lack. So even to this day, I'm very upfront with that I'm not great at CSS. CSS and me, we sort of butt heads a lot. If you give me a Figma, I can get it done. I don't enjoy it, which means I don't deeply understand it, and I put those in that order specifically. It's that I don't enjoy it so I don't want to understand it. It's my own personal blocker. CSS is a language like anything else. It's got the ones and zeros and the lifting. It does this internal thing that's really cool. I don't care, so I'm very upfront. CSS, not a strength. Other people in the group love CSS and are super good at it. Great. We mix really well together. So you have to be able to work with your strengths, and obviously there's things that we don't like that we have to do like AWS Lambda configuration and YAML. Nobody loves that, but we have to do it.
KM There's the saying, ‘See one, do one, teach one’ when you're learning something, and the last step of that is teaching it. It's not sufficient that you just do it. If you really want to get to the last level of comprehension, teaching is going to kind of be the thing that gets you there because as soon as you have to talk about something, it forces you to say, “Did I really know this or was I just kind of copy and pasting a lot of the stuff?” And so I like that as a way to kind of combat imposter syndrome, kind of ground your understanding of these technologies in kind of what is also helpful for other people kind of getting into the field and kind of handing off the torch in that way.
JT And bootcamps, this was, so think about like 2016/2017. Iron Gate, Galvanize, there was the boon of bootcamps. And maybe I was looking at it through the lens of someone who was on the ground, but there was a huge coder camp style, everybody could go to coder camp. And I'd originally come up with the thinking of everybody can code, you can come in, you can work through it. I have changed a little bit in the sense that everyone can code if that's what they want to do. I don't think everybody needs to know how to code, but it was very selfish in the sense that I wanted to be there to get better. Without a CS degree, I really feel like it was important that other people without CS degrees, because at this point it's really hard to get into the industry. I feel like things have shifted a little bit to where hiring in as a junior level doesn't happen as much anymore as it did maybe 10 years ago. Certainly, I don't have any juniors in my house while I'm working remote anymore, so maybe I just don't see it. But people without a CS degree, I feel like have in my day to day been vastly more curious and not open to not understanding what is happening. The people with CS degrees, they didn't learn Git 10 years ago. I hope that's changed now.
KM Oh, as in that wasn't part of the regular pedagogy?
JT It wasn't part. So people we hired, we had several juniors come out. This was probably 2017. I was working at USAA. We hired several juniors right out of school. Out of four, none of them used Git in school. They had no idea about version management. They all had their degrees and they could all do a byte array and a binary tree and they all knew n+1, fundamental CSS stuff. Not a single one of them had any notion of version control and that just blew my mind. That is fundamentally like, “Okay, we're going to start a project and then the first thing we're going to do is version that project.” Git and knit is literally the second thing you do.
KM Yeah. I wanted to take and synthesize your last answer, I think maybe a previous answer, from the quote from Ratatouille: “Anyone can cook, but only the fearless can be great,” and that's kind of maybe how we see stuff. Even anybody can do CSS, but you've got to be a little either fearless or enjoy it to be really great at it. You've got to really embrace it and get into it, and then, boy, then you can be great at it. But it does kind of take that next level of that you've got to get your hands dirty a little bit and be fearless, as Gusto said. Moving on to kind of a different area– can you tell me about something you learned recently? This could just be like a language feature or an API that you came across recently. Just what's something that you've come across recently and figured out?
JT So for many years I've wanted to work in Elixir. For those of you who have never heard of Elixir or don't know a lot about it, Elixir is a language built on top of Erlang, and Erlang is an older, concurrent language built specifically for telecoms out of the Erickson Labs. So think Bell Labs for AT&T and Unix. Erling is the Erickson Bell Labs version in Europe, but it is a phenomenally distributed, fault tolerant language that runs in a VM, Beam is the VM that it's called, and it's meant to fail and restart itself just perpetually. Think about upgrading phone boards in the ‘80’s. They can't not be on, there's no rolling upgrade. If it fails, it has to turn back on immediately and it has to be recoverable in all senses and shapes and forms. So that's when it was initially cut. Elixir is a Ruby syntax-like version that runs on the Beam that runs in conjunction and calls Erlang under the covers. So now that we know what that is, I have enjoyed this idea of fault-tolerant, small, distributed language, and Elixir is easy to look at, easy to read. Phoenix is the web framework. It's easy to stand up. It's so fun to work in. I'm not very good at it. It's also very functional, which is where I originally came to it, which I have since left the idea of that it needs to be functional. It just needs to work. The pipes are cool, but classes are also cool. That's my other hot take. Classes are fine, everything doesn't need to be functional. So I work in it mostly like a side project. I will always be like, “Oh, I'll do this in Elixir,” and then I always hit a point where I can't figure out something that is either, I don't know how to debug, I'm not skilled enough to run into the debugger and find the line and do a break. These are the things that I'm just not skilled at. And I recently rewrote a side project from Elixir into Ruby, into Rails, and used the Kamal to deploy it. I had it up and running and I had rewrote most of it in a couple days and had it on a VM deployed with SSL certs and everything in three or four days. My big takeaway is that Ruby and Laravel as stacks are so productive compared to the 10,000 papercuts that we experience in JavaScripts. It was deeply satisfying to just write up the business logic in there and then, “Oh, she's done.” What I will say is that the project I was working on– this gets back to your question of, “Well, what was the new thing?” I was calling the Whisper transcribe and it was streaming back the response. So I would give it a two-hour podcast and then it would stream me back the response. Now, you can wait till the end of it, but the specific reason I was streaming it back in chunks is so that it would show up on the page nicely as it progressed. And also, if you deploy on fly.io, your interchange, I had Whisper running on this instance internally next to my app, and if you aren't talking back and forth, your proxy connection gets dropped so you have to keep that open. They're like, “Oh, just stream back the response and as long as there's traffic, we'll leave your proxy open.” But after I think 10 seconds it closes the proxy, so you can't hold connections for a timeout response, because these transcriptions that are taking two hours would take about three or four minutes on the larger, because they have GPUs too. So you're streaming this back and it would stream about halfway through and then it was like, “Okay, I'm all done.” And from the Elixir side I was like, “Well, where the hell did it go?” And you’d do it in cURL and it works fine. The whole two hours comes back. And you do it in Elixir and it's doing the thing, doing the thing, random drop. And I didn't have the toolkit to debug. I was using the library and I knew how to go into the four and pull these chunks back, and I could see in my head how this would work in Ruby or in JS of like, “I can debug here. I can break point here. I can see the chunks.” In Elixir though, I couldn't figure out how to find the termination. I was missing a layer. I was up here and the stuff was happening here in the library. And in Axios, you can go in there and be like, “Okay, just give me the raw data. I've seen the payload. I know what it looks like. Just start spitting me HTTP loads.” And I couldn't even get to that point. I'm sure it's in there, and this is not like, ‘Elixir is terrible. I couldn't do this.’ No, Jesse is terrible. He couldn't figure it out. He was sailing up here. I took it in Ruby and as I copied it over I was like, “Oh, you have to keep the live connection open longer and it's not pinging back,” blah, blah, blah, blah, blah, and it was like a 20-minute problem. I spent weeks in Elixir trying to debug this. I was in the forums and trying to give them information like, “Oh, you can get in here and debug it,” and I could never get down far enough. In Ruby and JS it was like a 20-minute like, “Oh.” And now it's 20 minutes today. 10 years ago Jesse would've had the same problem in all three stacks. What I learned was to use the tools you know, and this was a side project, it had no value. But I recently did a proposal for a client and I was like, “Look, we could do it in this stack in Remix and it will be like three months.” They were like, “Well we have some other stuff in Python and could you use that?” And I was like, “Sure. It'll be six months, because I don't know Python.” It was easy enough for me to make that delineation between, “Look, I can do it in what I have or you could pay me to learn this other thing.” Go with what you know, that's my distilled. Go with what you know. When people pick their tech stacks and they're like, “Well what should we build it in?” it's usually irrelevant up until the point when it’s like, “What does everybody on the team know well enough to work in?”
KM Well, that's where contracting is a particularly difficult vein of software development, because oftentimes a good answer is, “Everyone knows it. We're going to do it in this technology.” That's not always the case you have in contracting. If the client's still forming opinions and you get a greenfield contract, sure you can kind of steer them in the direction of the combination of what I know, what we're bringing to the table with the whole firm, with whoever gets assigned to it, and also what's a good fit for this project. Maybe can you talk a little bit more about you've been both a consultant and also worked at a startup and where you see the differences between those in terms of pace or just in vibes, what the difference between those for you are?
JT I love the startup life so much, and if you pull up my resume, you'll see every other job tends to be a startup, because mentally I can only do it for about 2+ years and then I'm fried because it is so intense. I look at it like this– the startup is amazing in the sense that there are no barriers, there are no processes, there is only go. There's only do and go and build and forward. No task should take you more than a day. Get as much done as you can by Friday, and build it so it doesn't fall over on you Monday. How much testing did you write? Well, we don't have product market fit, so I did zero testing. Which testing framework did you use? The mouse. I just clicked and, “Does it work? Great. It works in the eight scenarios I can think of, and I'm onto the next thing.” It's really just a sprint to the next sort of iteration and iteration and iteration. I'm sure looking back on most of the startup code I wrote I'd be like, “Ugh, what is happening here?” Performance is not the goal. Get it working, get it stable, and then we're sort of moving on. Unless it's so egregiously slow, I wouldn't consider it stable. Unless it's a user problem that cannot be fixed with brute force or money, then it's onto the next thing. And consulting's very different. It's very much a white glove approach of, “This is not my code. Someone else is going to have to maintain this for many, many, many years to come, and ideally we want to keep these contracts going so they don't curse our names in a year.” We don't want them to be like, “Ugh, can't believe I have to go back into Jesse's code again. It's such an integral part and it's so awful and nobody wants to touch it.” We've all had those projects where there's that file. Nobody wants to touch that file because it always breaks and it's so brittle and it's so fraught with dragons that nobody ever wants to go in there. You don't want to make those files. You want to come in with a lighter touch and offer ‘it depends,’ and you also usually have most times more runway as far as time and resources and accountability, leniency. I look at the consulting often if it's staff augmentation as like, “I should write some code up front and then not much afterwards but be involved in all the reviews and the help and the feedback cycles.” When we do consulting for marketing where it's like, “Hey, we need this thing spun up for a marketing thing and then it's going to be there for six months and then it's going to go away.” That's more startup mode where it's like, “Okay, we can build it, we can deploy it, it can hit their campaign, and then it's gone.” Other ones where you come in, I had one project where we went in and they're like, “Our Cypress tests don't run well. You've got 90 days to come in and make them better and show us how to make them better.” It's like, “All right, well here's what we're going to do. You're going to give us the first month and we're going to come in and get the lay of the land.” We sat down with the teams, we looked through the thing, and then we wrote this whole list of, “Here's the low hanging fruit, here's what I could probably do in the time left, and then we're going to make these two blocks here for presentation time.” All those groups we talked to, come back, sit with us, and we're going to be like, “This is what we did and you guys should probably keep doing this.” Now, ideally you're banking on the fact that this was the start time of Cyprus and then what you brought back was lower so that you could show that slide first and be like, “Look, I know what I'm doing. See, now you can listen because I have the data.” So you bet on yourself a lot with those projects, but that's the sort of different mentality between the sprint, the rush, the build, the scaffolding, the circus standup where you can stand it up, fold it all down and move on versus the village where you're putting in roots and farming and there's a little more like, “How far away from the river do we want to be so we don't flood or drown?” versus the circus who's like, “Who cares? We're not going to be here next week.”
KM Sure, and some of that may even cross-cuts whether you're consulting or whether you're on a dedicated product company. What's the shelf life of this code? How long is it going to sit around for? Because that informs how much I need to put into the rigor of it. I know sometimes I will be writing a script just for myself just to automate a thing. Its shelf life is four hours, and I find myself out of habit just renaming variables so it's elegant the way that I would want it and making sure I use const or let instead of var and it's like, “Ah, it's not going to matter. I'm deleting the whole thing in four hours.” And sometimes I kind of have to remind myself to not put in that sort of craftsmanship when you're used to doing it in the context of maybe a job that's going to have you PR review this and someone's going to leave that comment and it forces you to kind of do that maybe too much and it's good to know what mode you're in, and if you don't have product market fit, the mode is survival. The mode is, “Let's do this quick.” All right, so the last question is this: what advice would you give to someone preparing for a software developer interview today?
JT So one of the things that has served me exceptionally well over the years is, when I was young, when I was 15, you could get a job, a full-time, W2, joby job. And so I went out and I applied. We went to the mall and we went up and down the mall and got resumes, paper resumes, and we took them all home and we filled them all out and then we went back and dropped them off and asked to speak to a manager. I see you smiling, you may have some recollection of this process. At the end of the day, I got a job at a retail clothing store called The Buckle, and it was commission based. So I got a flat $2 an hour and 3% of sales. That's not important. What is important is that over the ensuing years of customer service of working at retail, working in bars and restaurants, working at coffee shops, there is a learned skill of talking to people and reading the room and understanding what the objective is. I think we both work with a lot of people who maybe have never had a customer service-facing job like this. We derogatorily call them ‘soft skills,’ but they're really just life skills.
KM Sure, of course.
JT About talking and replying and asking probing questions. Those are the sorts of things you hear. When preparing for a job, the first thing I will do is go put in my resume, read through it, and they're like, “Oh, booked on Tuesday. Okay.” So I go find the company site and I go find anyone who works there. I will go on LinkedIn and just scrape and find anyone who works there and just ping them blindly and just be like, “Hey, I have an interview with your company. I see you've been there a couple years, do you like working there?” and just leave it at that. And I'll usually pick four or five. Most of the time at least one person will respond and just be like, “Oh, that's super rad. Good luck. I really like working here. I've been here for three or four years. It's super fun, the tech stack,” blah, blah, blah. Find other people in the company, find out what they do, what charities they do, do they do a 5K run for Turkey Trot, or what do they do outside of work? Whether you talk to someone from LinkedIn or you go to the career page or the charity page, what you're trying to do is get a larger picture of this company so when you sit down with someone and you talk about them and they say, “Do you have any questions for us?” you can say, “Yeah, I have a ton of questions about your tech stack.” So one company I interviewed recently, they were using Dart. For those not familiar, Dart is an alternative language that compiles to JavaScript that Google made and still makes. They had a huge piece in Dart. And so my question, and I only learned this from some LinkedIn probing questions and then they had no open repos, but I'd figured out that they have a lot of Dart stuff here and I don't see anything about Dart listed. I was like, “So tell me the story about the technology Dart that you guys use,” and they're like, “Oh, okay, well, so this is our first thing. We're trying to get rid of that. We're not writing any Dart here. You don't have to worry about that.” And I was like, “No, no. My question is why?” You want to know what brought stuff in, so engage them in questions that they deal with day to day like, “Have you been writing Dart? Why are you still writing Dart? What are we doing now? Why was that decision made? Was it recent, because that sounds terrible, or was it a legacy decision that we're all recovering from?” Find out about the company, find out about the person that you're interviewing with, find out how long they've been there, what their life trajectory is. It gives you a real insight and really brings down the barrier between interviewee and interviewer, because you are going to be going there, you are going to be working there. A cliché you hear is, “Well, you are interviewing them just as well.” Then ask them probing questions and pull that down and make it feel like, “Look, I'm really good at what I do. Tell me why I should come work here. Is it fun? Is it interesting? I'm not looking for work colleagues. I have a family. I have little kids. I need to be gone at 3:30 a couple times of the week. Who has kids? Who doesn't have kids? Who's on the team? How big are they? What are the off-site parties like? Are they cringey or are they at the karaoke bars? Is everyone out drinking till 2 AM?” If that's your jam, cool. That was my jam a long time ago. That is not my jam anymore, but I'll meet you at 6 AM for a run and a cup of coffee. Find out if there are people that you're going to work well with before you get there.
KM I also think that sometimes it can help break through the noise too for you as a candidate to bring up kind of interesting things when it shows that you've researched them. But I truly value when it is the case that candidates are interviewing you as well, and when I get questions, they're often very similar. They're all of the same vein. It feels like the sort of thing where if you said, “What are the top 10 questions to ask at the end of the interview?” that's a lot of the questions I get. And to be fair, the questions I ask are pretty standard things too, but if somebody says, “Hey, why are you using Dart?” not accusatorily, but just out of curiosity–
JT Yeah, talk to me about the decisions that were like, “Do you know why you guys started with this?” And one question I asked a guy once was how big are the teams? And he goes, “Well, it's tough to say.” And I was like, “Do you guys subscribe to two pizza teams?” And he was like, “What's a two pizza team?” And I was like, “Oh.” So we had this great conversation about two pizza teams and then we talked about what to put on our pizzas. That was a sort of disarming conversation that the rest of the interview went swimmingly. Disarming them I think, because we've sat through interviews, both you and I, and we ask a lot of the same questions, and it's the enjoyable conversations that I mark and come back to of like, “Oh, I would definitely work with Kyle. He was totally fine. He sucked at CSS, he did the rest of it really well, bear Flexbox froggies,” but I would hire him.
KM Awesome. Well, thank you so much, Jesse. For anyone else who'd like to find out more about you or what you're up to, where can they find you on the interwebs?
JT You can find me at jessetomchak.com. That's where I randomly blog. I am @JTomchak on Twitter and I am JTomchak on social on Mastodon and Threads. I’ll tell you what, put in JTomchak, because I'm on LinkedIn and everywhere else and you can find me at all the places because it wasn't ever taken anywhere because I got lucky.
KM Great. Well, we'll do that. Jesse, it's been great talking to you. Thanks for your time, and we'll be in touch.
[outro music plays]