Why Convex doesn't let candidates use AI in coding interviews

If you want to be a world champion sprinter, you have to love training, not love being on the podium. Who I don't want to have work here. People who just want to come and make some money. Care about building cool stuff and build cool stuff. You will get recognized over time. It's like if you were in a Michelin star restaurant and you tried to hire a chef and they're like, "Oh, well, I have this automatic chopping machine. [laughter] Why not turn that on?" Like, that's not the point, right? Should developers be using AI? Uh, you can probably guess my answer. So, firstly, all right. So, we're here today with James, the Cto of Convex. That's me. And um I'm particularly interested in talking to you, James, today about hiring and what hiring looks like, particularly in the age of AI because there's this theory out there at the moment that when you're hiring, you should allow the people that you're interviewing to have the same tools that they would have on their day-to-day job. So like you wouldn't ask an accountant not to have a calculator. So should you let a interviewe not have AI? So I want to get to that. You might actually ask an account to not have a calculator. Well, [laughter] let's get to that. Let's get to that. But I think before we get to that, let's give a little bit of a background on you, where you come from, your backstory, and how we get to CTO at Convex. Sure. Yeah. My my misspent youth was very academic, you know. So, I spent um all my childhood [laughter] working and studying and doing all that kind of stuff, you culminated in me going to MIT doing a PhD in distributed systems. I worked with this woman uh a woman there named Barbara Liskoff. This woman I work with the very famous Barbara Liskov. Barbara's like a friend of ours. I just call her Barbara, right? But like she's uh you know incredibly impactful important person in in computer science who came up with like you know the Lizov substitution principles named after her and did a lot of seinal work in consensus protocols and and all sorts of things. Um, so I got to work with Barbara for seven years and uh really imbued in me a sense of appreciation for abstractions that unsurprisingly she was the person who came up with that stuff. But like um her she spent a long time in programming languages and I think there's so much we can learn from programming languages cuz programming languages are a design exercise. It's not it's not a mechanical exercise about how to come up with a really clean language that makes complicated things simple. Mhm. And so I think uh it was this combination of an interest in distributed systems and protocols and uh and this programming language aesthetic and sense of abstractions uh was going to go be a professor. That was like the that was the path for me. And then kind of very last minute before that happened I was like h maybe I'll just go see what Silicon Valley was like maybe just for a little bit you know before I moved back to Australia. So I was I was going to get back. We should we should just note that you are Australian. I'm Australian. I'm English. Who lives in Australia? Australia. It's confusing for folks. Yeah. So So I I am Australian. I was always planning on going back to Australia and being a professor in Australia. And then I was like, ah, maybe I'll just come and go to this little company called Dropbox. Uh which at the time I mean was maybe it wasn't a little company. It's pretty small staffing wise. I think there was seven people on infrastructure. um it wasn't considered um outside the company to be like a glamorous place which is weird cuz it was such a cool place right but it was people be like oh you just go to Dropbox isn't that just like whatever like you know like FTP it was just this kind of like naive attitude towards this new generation of companies and then Dropbox was you know the first one of the first unicorn companies there was kind of Airbnb and Dropbox and a few companies at the time so got to be part of that got to be part of uh very lucky to be in a very high ownership environment where um Jamie and I and and other folks on the team built out most of the infrastructure at Dropbox, the storage system and all that kind of stuff. And that's how you met Jamie obviously. Yes. And did very seriously large scale engineering and uh you know we're talking xabytes of data and um you know millions of transactions per second, databases, all this kind of stuff. Um, but the the the real formative thing about being at Dropbox is I got to work with tremendous, tremendous people. And I got to have a have a sense and appreciation of how gratifying, how fun it can be to work with just awesome people who are enthusiastic about what they do. Um, kind people um high ownership people. Never have this sense you don't have to beg someone to do something. Everyone wants to do the right thing, right? Uh and then later on I was lucky uh you know to be the most senior engineer at at the company at Dropbox. And so my job uh was obviously to make engineering decisions but also to mentor the senior engineers at the company uh set standards for hiring set standards for promotions define what it means to be a uh senior staff principal engineer. Um, ultimately we left Dropbox and now I'm here at Convex and obviously like there's the official mission of the company which is to be the the next abstraction layer. It's the API for application development of the future. But the like why did we start a company? Cuz like starting a company is kind of hard, you know, like it's not the easiest job in the world. Started company because I really wanted to build a cool team. Like I and Jamie's the same like when we started Convex, we wrote this um we wrote a document called the founder marriage document. It's pretty cheesy, right? Yeah. Yeah. We really do this. And I don't know if I want to show you, but [laughter] uh we wrote down like uh ranked reasons for us starting a company cuz we wanted to find out like is there compatibility there? And the number one thing for us was to build a team that we're really proud of that can grow um can can graduate out of convex one day and go start uh their companies. Uh that's the number one thing. It's why we're like we have this company, why we invest so much in the people here is cuz that's that's the real reason for the company. Now obviously the nice part of that is it's that's a compatible goal with building a successful company also because the company's made up of people of course. Yeah. So, I guess that kind of ties nicely into like a culture discussion as well is like I spoke to Jamie yesterday and he mentioned that one of the greatest things that he discovered when he went to Dropbox was going from 300 people to 3,000 people that there was a very clear intention in the culture and keeping the culture in a very good place where people want to stay there and you know he was there for seven years and I assume you were there for longer. Yeah. Is that something that you bring forward into convex? Absolutely. Yeah. I think about this. I think it's easy for engineers to get lost in the weeds and want to fixate on details. And you know, I'm a details person. Like we're all we're all engineers, right? But like what matters more than that is the big picture, right? So what matters is um more so than the policies and the rules of how things are done at the company is the kind of people you hire. How you encourage them to be while they're here. What you encourage folks to value, right? So for example, we have a set of um company values at Convex. They're on our website and those values are opinionated. It's not just like, oh, be a nice person and do good, don't do evil. Yeah. Like that's BS, right? like every value is um you could argue the the the contrary and the so there's values around um you know there's companies that are very hacky in what they do right and Facebook was famous for this like move fast and break um I love that value that was a cool value because it said something about who they were and it um guided engineers and how to make decisions all right then later on they ruined it cuz they call it stable infrastructure with stable infra And it means nothing now, right? It means nothing. Uh, so I I love that value. Convex is not at all that kind of company. Convex is a company about like principles and the why and clean compositional, you know, components. And so it's really deep within our culture to ask why is really deep like no one ever does something because they're told to. They done something because they understand deeply what's the point of this work. And so this is this is culture. I think people think culture is like how you have lunch together, right? But culture is about how you make decisions, how what you value. And everyone at the company must be on the same page culturally. They don't have to come from the same cultural background obviously, right? But you have to share in the same set of cultural values here. If someone was a convex and says it doesn't matter why we're doing it, just do it. They're not going to have a good time here. Right. No one is. Yeah. Yeah. So, so I spend and Jamie spends a lot of time with the team and and the thing about culture, it's viral, right? It's not like I have to do it now. Like we establish um principles for what we value, what we care about, how we go about I mean integrity is a very part big part of our culture and you might say everyone thinks integrity is good. They don't. A lot of people have outages and incidents and they just sweep it under the rug. And we don't do that here. We tell people when there's an outage, right? And folks will have seen this. We write postmortems and we're transparent and we're honest. Okay. Yeah. And that's just part of the culture. And if I now tried to do the opposite, the team would call me out. Cuz that's what that's what culture is about, right? Like it's it's it's success. Culture is successful once it sustains itself. And so I have drifted far from the original question about Dropbox, right? But the only way you can succeed in having a having a company grow from 30 to 3,000 and maintain a sense of common purpose is to establish this viral culture and grow in a sustainable way. Yes, I do worry for I mean sure like I mean suffering from success, right? But I do worry about those companies who go through hyperrowth of staff. Yes, it's very hard to scale a code. Open AI, Anthropic, those ones. I wonder what it's like inside those at the moment. Yeah. Now, they they wipe their tears with their dollar bills, you know. So, so they're okay. But no, no, I mean, these companies often times are very chaotic internally because it's very hard to maintain this strong culture when you've just grown so fast cuz there's not that time for for it to solidify and to pass down to new generations. And they've hired people from all these places with these very strong opinions. Oh, we've hired from Google. We've heard from Meta, we've heard from Apple, and now they've all got very strong opinions and they've all got different cultures that they're trying to bring in and force underneath their leadership. And I I can imagine it's it's very difficult to keep that identity. Absolutely. And I think about like in terms of like um significance within an organization, there's values why, what, how, right? In like decreasing order, right? So often times engineers in particular want to debate how to build something, you know, what's what system should we use, what algorithm should we use, whatever, right? And if you're not on the same page about what to build or why you're building it, you're just never going to get there. And and there's I've been involved in plenty of situations in the past. You know, at one point we I had a team where, you know, one sub team thought the most important thing was to improve our API so developers could move faster and one sub team thought the most important thing was to increase reliability so the company wouldn't fail, right? And these teams had different why messages, right? So you're never going to come to agree. And so it was very contentious when they debate what to do and how to do it because there was something wrong higher up the stack, right? And so if you don't if you're not values aligned, if you have two people at the company who just have different values, right? They're coming from different places. One one person thinks the most important thing we should do this. The other person you can argue all you want about how to do it. You're never going to come to commonality. So I I think and Jamie and I very aligned on this, right? We push very much on before we worry about arguing about how to do something, let's make sure we're all on the same page about why we're doing it or what even is important to the company. Well, maybe let's just take a little tangent there then actually then. How how do you deal with situations? Cuz I think is it Jeff Bessos that says um when those situations arise is is it accept and support or something like that? So you have to and commit. That's Thank you. Yeah. Yeah. So, how so how do you as a as a boss decide if these two people have got very different opinions and want to solve the same thing with strong opinions, how do you rectify that? I mean, look, sometimes you just got to put up with it. But what I'll say is that I like working with high achieving exceptional people. I've been lucky to have always worked with high achieving exceptional people. And these people don't do well with being told what to do. So what do you do then? You you can try. I mean and this so this advice is not the advice for everyone, right? Cuz not every team's like this. But if you're fortunate enough to work with exceptional people, it's rare that you can say hey just put up with it. You can try and engineers probably should put up with things some more. So firstly, what I would do is firstly no one ever resolves conflict in a meeting. Mhm. If you get to the point where you disagree in a meeting, then end the meeting, right? There's, as much as we like to pretend that we're rational correctors, we're not, there's a whole bunch of saving face and holding positions and all sorts of things that happen in a meeting, right? So, if we get to a a point of intense disagreement, which doesn't happen very often because we try to be ahead of it, right? Then I'm going to stop the discussion and independently figure out higher up the stack why. what you and I might disagree on what the most important thing for the company to do. It might be you might think that we haven't invested in convex helpers enough and I might think our API is getting inconsistent or something, right? And so the we're arguing down here when we have to have a discussion up here, right? And so I'm and and this is not going to feel weird to people at Convex because this is how we operate, right? that often times, almost always when there's a irresolvable disagreement, it's because you're on the wrong level of the stack. You got to go higher up. Why do you care so much about this? Right? It's like therapy, I guess, right? And you know, sometimes there's not time to to to go all the way up the stack and it requires people to be reasonable and to lean into it. The other thing it requires is trust. I think it did take time for us to build trust at Convex. M early on in the company, especially as we're hiring folks from different companies, some people come in with a bit of baggage, you know, a bit of this anti- leadership vibe and stuff, what's the policy for blah, how do we protect ourselves from whatever? And my answer, unfortunately, is, hey, where does we're you're at a startup. Yeah, we're on this boat together. We're all sinking or or or swimming together. And so, you just got to lean into the trust. And by the way, you're all tremendous engineers and if you want to leave, you'll get a great job somewhere else, right? It's very it's it's it's a we are so fortunate to be in this industry. Um and so I do think my advice to anyone look there's some people have terrible jobs with terrible employees and they don't have the opportunity to do otherwise and that's a very different situation. But if you are a um a highly capable software engineer at a startup, I would say don't play defense. Don't don't don't hedge against downside. Lean in. Make the most of the experience. What's the worst case scenario? You you don't like it and go somewhere else. Y yeah. Yeah. That's the great thing about Yeah. companies you can do that. It's not like a a family. You can't really leave. That's some of the you can you can leave, but no one wants to because it's it's good. you know, but yeah. Yeah. Okay. So, let's segue into um hiring now. So, obviously Convex raised Oh, now some money raised this year and uh very exciting and we are now hiring as fast as we can. We're hiring. Um I guess kind of to iterate on what we were talking earlier, one of the question that I would have is obviously we want to try and hire worldass people, the best people that we can. Um, how do you balance off trying to hire the absolute best which narrows the pool significantly of potential applicants to expanding the pool to maybe less world class, I don't know what the term is for that, but then also keeping the culture um of excellence high. Yeah. I mean uh everyone at convex is either currently world class or aspiring to be there, right? And I think that's the same thing as world class, right? So I don't think we don't we rarely hire based on like um checkboxes. It's not perhaps our job description says must have x number of years of experience. That's not how we actually do it, right? It's not like I'm looking for must have six years of distributed systems experience. I want to find the people with the with the raw ingredients or the experience to make this an incredible place. Right. So firstly, any healthy team has a distribution of experience. Mhm. because there's different kinds of jobs at different levels of difficulty. More senior people want to mentor junior people. Junior people want more senior people to mentor them, right? [snorts] So, we're not always hiring at the absolute top end of the market. Um, also a lot of folks who are exceptionally experienced like my my peers I've worked with, some of them don't just want to chill, right? But to be honest about it, some of them are like, you know what, I just want to chill right now. Yeah. Okay, that's fine. So I'd rather have people who are earlier in their career and it's better having someone up they want to make a name for themselves. It's exciting for them. It's exciting for everyone benefits from right. So um so yes obviously like if there I am looking for the worldclass distributed systems folks and and worldclass Typescript folks but also looking for the people who will be that you know who who want to come to a place that values quality. Mhm. Because not every startup values quality and it's not rational for every startup to value quality either. Some at the end of the day this is a capitalist enterprise right we're lucky that convex is a very difficult technical challenge and so it's rational for us to want to have people who care deeply about technical excellence. That's the kind of company I want to work at myself of course. Um so um I'm looking for people who uh either yeah obviously have tremendous experience or really want to throw down and be that kind of person. Um who I don't want to have work here. People who just want to come and make some money. I mean sure you are going to make money here. Hopefully everyone here is going to get stupid rich one day. One day. That's not the point. Yeah. Um, and people who some and a lot of people don't care about excellence, they think it's silly. Mhm. That's fine. It's just not this not the company for you. Yeah. And so I guess maybe that's a good segue into what the hiring process actually looks like at Convex. How do you identify those people that you just mentioned, you described? Yeah. Um, I think the answer is probably going to be disappointing to some folks is that over time you you get good at evaluating people. I like to think that you do check or you just feel like when you meet them. So there's obviously interview process, right? So so there's there's this is how the process works. Um I think it's a little bit um like an iceberg, right? what people might see of the interview and recruiting process is a very small fraction of what is actually significant about the interview process. Right? So what you see is the interviews. Mhm. That's pretty obvious, right? Now we can talk interviews in more detail. Hey, some phone interviews and and then an on-site interview. On-sites, I think, are very important because you get to see the team. You get to feel who you're going to be working with. Um coding questions, architecture questions, deep dive all around this kind of stuff. What you don't see is what happens after that. And I am very anti- data-driven decision-m in most dimensions to be honest. People might be surprised to hear that. Certainly in recruiting, we don't everyone the in can, you know, interviewers at the company interview candidates. They write feedback up. We don't add all the numbers up and make a decision, right? We take all that feedback. Everyone is obliged and responsible to come up with a decision for what do they think at the end of the day we're growing a company right every person we add to the company is the future of the company right so every interviewer has to come into a debrief we do a debrief as a group you need to come into that room with a decision on whether you think this is the right person to grow the company and then we talk about it and the I start every debrief by saying that interviews or a crude approximation, a crude mechanism for trying to determine who is who someone is and whether we want to have them here in an interview. They're not doing the work they're going to do on the job. It's not a trial, right? It's a window to try to understand who they are, right? And then we talk about the decision as a group and we make the decision in the room and everyone is forced to not forced everyone has to discuss their feedback and then they have we all have to agree with the decision and the debrief is by far the most important part of the process because it trains all the interviewers on what good looks like because if it's not doing good doesn't mean just doing well against the rubric. Were you given the question and did you get the right answer? How did how did you discuss it? Were you exhibiting mental agility? Were you exhibiting good taste? Were you jumping to conclusions? Did you have the ability to step back? Right? So all the interviewers in the debrief get to see what good means. Right? This makes us better as engineers, right? It makes us better at figuring out what what good looks like. And then that goes back into the next interview. Yeah. Right. And so [snorts] all the interviewers here, I mean the interviewers, I say it's the engineers here, right? Get better and better every time they interview a candidate because there's a feedback loop. It's not just like interview someone, write down some feedback and throw it into into into a black hole. It's do this, make a high ownership decision about whether you think this is the person for us and then we discuss it as a group and we refine our mental model. Mhm. And so does it tend to look like you plus another engineer in a telephone interview and then two engineers in an interview whiteboard session and then you all get together at the end and discuss. Is that what it sounds like? Yeah, probably. I mean if someone gets to the debrief stage is probably seven interviews at that point. Seven. Yeah, probably. It's probably two coding interviews on the phone and in person there's probably two coding interviews. Um if they're a senior candidate, I'll do an architecture question. to pose them a architectural challenge and have them design it. And what I'm really looking for is like clarity of thought. There's a lot you can learn from these interviews, but like I love these interviews cuz there's no rubric for that. Yeah. It's not like did you give the correct answer to the question? It's like did you exhibit clarity of thought? Can I throw a wrench into the process halfway and say, well, what would you do if you didn't have that database? Right? And see how you handle that situation because that's that gives you an understanding of how that person thinks. Um, a deep dive. I also love the deep dive interview. Deep dive interview, you talk through a system you've built before. Ah, but I don't care if that system was good. I care about your reflection. How do you describe it? And in particular, this is a this is a a big um very strong heristic for whether someone's going to do well at convex. If you say, I built a system and it works, and I say, cool, but like who used it? And you don't really know or why was the system built? you don't really know, right? It's not going to go well here, right? And this can happen sometimes in big companies. Like sometimes you interview someone from Google, for example, and they just built a big system because they were told to and they don't really know who uses it and why they use it. They don't really care. They're just such a small cog in a massive, they just don't care, right? That's not going to do well at a startup, right? So what I what I really like the people who really stand out in those deep dives one they built something very cool and elegant and not over complicated it really solved the problem but they deeply understand what the problem was it involves some degree of kind of conflict/ difficult decision-m this team wanted this feature we couldn't build it we had to do this this shows the ability to and at the end of the day engineering is not about just writing code right and the thing you got to get away from is Not we're not monkeys, right? It's it's about solving problems. Yes. And that that was something I was going to ask about James actually is that so nowhere in that did you actually talk about like code. So like if you're going to hire somebody for primarily a Rust position, would you test their Rust ability? And if you do, would you pull in would you allow them to use the full tool set that they would normally have? Would you allow them to use AI in So there's a couple of questions in that. Yes. So I mean I think um someone has to be good at writing code right because if they're not I don't like um what happened like you know then they're software engineer they have to understand they have to be good their craft do they in 2025 though or 2026 they do absolutely now and I don't care if they're a good Rust developer they'll figure it out if someone's talented and you're excellent at Haskell I don't know why you maybe you're a professional Haskell developer Jamie yeah cool you'll figure it out you'll be great that's that's that's like the um if you're a great artist, you'll figure out how to use, you know, crayons versus pencils, you know, like whatever. That's just that's just the craft. Now, um but um no, at the end of the day, interviews, like I said, interviews are a crude mechanism we use to understand a person. And it is about I think um building a mental model for someone somewhat unfairly like you don't I don't know them, right? there's referrals and stuff. We only have a limited window to understand them. And so my goal is not to um you know, my goal is to get to the essence of who they are. And the more AI tools and things they're using, the more noise that's putting in the process. Everyone can use Claude. I mean, it's not a particularly difficult thing. We're hiring excellent people, right? Um, and so yeah, if you were I mean it just seems I don't it almost frustrates me I have to explain it, you know, not to you obviously, but like because people in the industry are like, "Oh, well, they should come in and use all the toolkit." It's like if you were at a Michelin star restaurant and you tried to hire a a a chef and they're like, "Oh, well, I have this um automatic chopping machine. Why don't I turn that on?" Like, that's not the point, right? Even if that's what you end up using. Yes. Right. cuz I I want to see the aptitude, right? And and they'll figure out the AI tools. I haven't seen a smart engineer in incapable of using Claude, right? They'll figure it out. Yeah. I want to get to the essence of who they are. Yeah. Yeah. Yeah. I think there's a definitely a difference between the intelligence and personality of a person which sounds like you're indexing very highly for versus their ability to just smash out code which if you if you're somebody who just wants to smash out code then maybe you would use AI and you would use the right tool for the right job like if that chef can work faster with that automatic chopping machine are you somebody that would like prevent them from using that probably not if like if that's faster but you still want to see that underlying that that they are an intelligent chef that knows how to use the knife correctly and uh construct a beautiful meal, a tasty meal. Yeah. I mean, I do whiteboard coding. There's not even a computer involved. Yeah. Because the computer distracts, right? I want to see how they think, right? Um now, I am also pretty against work trials. Oh, yeah. For me, like so, so there are companies out there with very different requirements. A lot of startups need people just to to be output machines, right? But not necessarily architectural thinkers and and and so if if you're hiring kind of young high throughput output machines and you want someone hit the ground running and crank out code, you can maybe do a decent job of having them work for you for for two days and see. But if you want someone to be a deep thinker about architecture, design a database, you ain't figuring that out in two days. At least not in any way that I can't learn in an interview. Right. So more senior candidates, their their abilities don't show up for for many months. Mhm. uh on the job you can you can try to figure out their abilities by asking good questions or or you know but like just watching a senior person you can't as an extreme example you can't hire a CTO watch them work for two days and then know if they're good or not it's strategic right the the the quality of the decisions don't show up for years so it's a waste of time so sure um you can find out if someone's a good fast coder in a work trial but um everyone we hire Eric's good fast coder. We figured that out pretty fast. Just give them a coding question and see. Um, and then beyond that, what I want to understand is how do they think? What do they value? So, I guess the natural question is then how does that I guess goes back to the previous question. So, how does that scale then? Like surely that does limit the speed at which you can hire. Yeah, it does. And we're we're not growing in hyperrowth. So, look, it's easy for me to say, right? I'm not adding a thousand engineers this year. Um, it so you got to scale out the process as you go. And that's why the debriefs are so important because when we're interviewing, yes, we're interviewing candidates, but we're we're um growing our internal muscles around how we evaluate people. Mhm. And solidifying culture about what what goodness, what great looks like. Mhm. And so every time someone and we have folks who have been doing interviewing here for a long time that I ultimately they can make a pretty good independent decision about whether to hire someone. Mhm. So as we go we we build the moderators of the future. So I personally moderate every debrief meaning I personally just am the DRRI for deciding who gets a job. You're the final say. Yeah. But that won't be the case forever, right? Um it will get too much work for me. It's already a lot of work for me as it is. Um but then so you just you build trust and then then but you don't build trust by having a rubric and this is like this is guess comes to the core of how we do things here in my philosophy, right? I'm not going to bring a new person in and say, "Okay, I want you to interview candidates and here's the checkboxes for how you do it. You're going to you're going to get lowest common denominator output of this person." And you're not going to be able to keep the culture going either. You bring someone in who cares deeply. You have them be part of the process. have them understand where it comes from and then they can take over and then you hold them accountable too. You know, you join some of them and if you don't agree with the decision, you tell them, right? And that's how you get better, right? Yeah. Yes. Yeah. Makes sense. So, we talked about AI in hiring, but what about AI in the workplace? What is your current opinion as of December 2025? Should developers be using AI? Is it mandatory? Do you because I know some companies from top down say you're going to get fired if you don't AI problem. Really lame companies. Yeah. Uh you can probably guess my answer. So firstly the interviews don't look anything like the job, right? Because the interviews are are are cultivated to figure out who someone is and and whether they're a good fit in the most concentrated way possible. Then when people get here they operate differently, right? Um and unsurprisingly my answer to this is no. We don't have a AI policy. Well, the policy there's obviously policies about like only use company owned accounts and things for like you know privacy and and compliance reasons. The the policy is you are responsible for your output. That's the policy, right? What a strange thing to say. Yeah, it's pretty easy to write like you I hired you as an engineer. I'm saying this in such a strongly worded way. We all everyone here is tremendous, right? I hired you. You're awesome. Be as productive as you can be. And if you put up some work and it's not good, that's on you. Yes. I don't care where it came from. Well, obviously, you know, within legal within the legal sphere, I don't care how you produce that work, right? At the end of the day, your your job is not typing letters on a keyboard. Your job is not coder. Your job is software engineer. Yeah. Your job is making problems go away. Right. So, this has never happened at Comics, but I've seen other companies where engineers have put up like nonsensical PRs. Yes. And then they've got a code of view saying this doesn't make sense and like oops Chad GBT wrote it right or Claude wrote it on that would never ever ever fly. You you saw this yesterday in in in a meeting saying even with regards to code review I'm not I'm not the biggest believer in code review. A lot of people would be shocked to hear me say that. Sure code review is necessary for compliance and and it's um sometimes code review is necess is helpful to help you grow. Yeah. like you can get feedback from someone else. Hey, I would have architected this differently. The code of view is a is a useless mechanism for correctness and reliability. Maybe for very very junior engineers, code of view is useful. Beyond that, do good work and make it good. And if you're not confident in the quality of your work, write some tests or do some smaller things, right? Um at the end that that's it on you. Mhm. Right. and code of view is a value ad to help you um get better, right? So like and I feel very strongly about this like don't have policies telling people how to do the menial stuff, right? Have highlevel expectations and accountability. Now you have to be willing to back that up. Mhm. At the end of the day, people here are responsible for the quality of their output. If someone was putting up a bunch of trash eventually that person I guess but that's you know we would have discussed that it hasn't happened right and it won't happen so I do think and now again again I have the luxury of working with an an excellent high ownership team it's not always the case for every company but you don't need a AI mandate if you have high ownership people I just say like hey make sure you're as productive as you can possibly be and we have um discussions like you saw the other day about hey here's some tips hey I tried out this new feature um this is making me more productive we can all learn from each other but at the end of the day the quality of works on you and that's that's all I care about yeah I think I agree like incentives rather than mandates you incentivize certain level behavior we expect this kind of quality yeah culture yeah culture correct yeah and how you get to that is up to you so what I'm hearing is that that chef can't bring the chopping machine into the interview but he can he can use ituring Yeah. At the end of the day, if you find a more efficient way of doing something, then do it the more efficient way. I don't care. Now, it has to be a high quality, high ownership. As long as the food that comes out is great, you know, it's the same as you would do with a knife. Yeah. Um, fantastic. So, I think we're getting towards the end now, James. But I guess who specifically are we hiring at the moment or obviously hiring the people that you've been talking about, which is mainly like high level infraers, um, backend engineers, but are we also hiring other kind of roles at Absolutely. So I I'll speak specifically for engineering right we're just hiring tremendous engineers right now there's a lot of opportunities out there and if you're early in your career you've got to decide what kind of field to plant yourself in. Yeah. All right. And you've got to decide the kind of company for you. And so sometimes you might want to chill place with not a lot of ambiguity and convex is not for you. Right. But if you want to be at a company where there is tremendous upside in terms of how much you can grow because one, there's no limit to the amount of ownership you can have here. As long as you're delivering, you can keep owning, you can keep making decisions here. So there's no limit here. But we do care deeply about quality. So this is a place to come and learn how to do things really well. It's a place to learn like, okay, what does good architecture look like? Um, those are the people that are going to thrive here. And then I want to talk to them. right now specifically we're hiring across across the stack. I would love right now some more like deep typescript experts like um library enthusiast people who design frameworks y um because obviously we have the convex API is the most important thing heavy uh and we're always hiring good infra people because we're always scaling and the thing about convex this is not like um I don't you know it's not like throwing engineers uh into encore like firewood right this is leveraged work right so I want people to come in and build the systems to to help a was actually a surprisingly small team. People are stunned to find out how small I didn't know this like how do you have like three people owning like some of this like huge infrastructure um because they design for simplicity and for elegance and automation and all this kind of stuff that this is this is the place for these kind of folks and if you are not one of these sort of senior amazing Typescript person who's been around doing amazing things you're Tana Lindsley or whatever um and you are more on the junior side but you're incredibly enthusiast astic on convex like I was you know um I still am obviously what would you say to would you say still apply like if you absolutely junior person and you're passionate about convex and you would like to to grow and be a part of a rocket ship you know yeah I mean I I always have this philosophy right if you want to be a world champion sprinter right you have to love training not love being on the podium right like the the end goal should not be what you spend your time thinking about, right? So, absolutely you should apply for for convex, but you should be building. Yeah. If you want to be an incredible engineer comics, you should be building every day cuz that's what you want to do. Yeah. Right. And you can be building on comx right now is what you were doing, right? You can be part of the commerce community building libraries, building components uh in our discord, contributing to open source. You may end up working here or you may not and you still benefited so much 100% and also we benefit too obviously right. Uh so I think that that's that's the thought process. Too often I see people talk about hiring and [snorts] jobs and and application about winning a prize or passing a test. Yes. And it's like it seems this singular thing that you just kind of like almost cheat your way like like you know how do I cheat in my interview? How let's look up the answers to the questions. Yeah. Cheat. That's not that's not how you become great. Yeah. It's how you fake it for a while. But that's that's not the top of the mountain, right? And so the the way to really grow over the course of your career is just be doing the care about building cool stuff and build cool stuff. You will get recognized over time. I think both of us have got a bit of grays in our beard. If I I certainly do. [laughter] And I think it to me it's one of those things that you learn throughout your lifetime and it's a more of a philosophy on life. You know, enjoy the journey, not the destination. Yeah. It's not fun to cheat. Yeah. It's fun to love building stuff. Yeah. Yeah. And if you don't love building stuff, go to something else. Find what you love. Yeah. Right. But um if I if I wasn't here, I'd I'd be doing similar stuff. I'd be doing engineering and and so and everyone here is in the same boat. Right. So every day get up, build something cool, learn about, you know, clean design and architecture, all that kind of stuff. And and and let us know. We'd love to to chat and to interview folks. And if you don't get a job here, well, guess what? You you become a good engineer anyway. Yeah. Yes. Yeah. Perfect. I think we'll probably leave it on that, James, but that's a great way to end and uh appreciate you spending time with me today. Thank you so much. Interesting conversation. Cheers. A mode.