Landing Your Next Developer Job

React. React. React. React. React. React. React. React. Okay, so hi, everybody. The goal, well, the topic of this webinar is finding your next developer role. And so, what we've been looking at, I don't know if you can put the camera on me because everyone is looking at Phil and I'm the one talking. People like to look at me, I've been told. You can do the intro. Yeah, okay. Back. There we are. Oh, no. Okay. Back to me. Cool. I guess I'll do the intro. Yeah, so the idea of what we're doing today is more of a kind of a workshop about, like we were talking about developer roles which are just front end, back end kind of roles that plug gaps between teams and kind of help companies work smoother and the different roles that that might exist and what the responsibilities are and that's why we've kind of got a kind of a mixed crew here. We've got Sadek who's currently getting us all set up. We've got Francois W. who's more in terms of business. Yeah, business operations. Yeah, and Nouha something very similar. You can maybe explain that a bit better yourself. Yeah, so I work with a team called developer experience. So we do something between developer relations and developer experience. So work on how much the product works well for developers and trying to bring as much feedback as we can to the product team to try to improve both the product and the documentation and everything that's around the product. But we'll look a bit more into it. Yeah, that means that because Luha does that sort of role, she works very closely with myself who is on the education team. Yeah. And we kind of try to bridge the gaps that exist between the developers and us here at Prismic. We try to get that information as quickly and as efficiently as possible to you, the users, so that we can make that process as smooth as possible. So that's what we're going to be talking about. So, it's all those different roles that you may do and what exists in it, and then we'll move into what we've learned in our process of hiring and also the people that are being hired, the things that we've learned over the years and how can we give that information to you and answer any of your questions that you have in regards to any of that stuff. So, we selected some of the job posts that we think might be relevant to you, but this is more meant to be a discussion, so if you have any question feel free to ask and we can also talk about these roles and answer any question that you might have about any other role. So, Daria shared with you a little type form, I think today, asking you which roles you'd be interested in knowing more about. And so the first ones that we'll be talking about are Solutions Engineer, Documentation Engineer, Developer Experience, and Growth Engineer, which are the ones that those of you who answered wanted to know more about. So, we'll look a bit into these. Each person will explain what their team is doing when it's a role that is related to their team. And then, of course, you're free to ask any question. So, should we start with Solution Engineer? Let's go. Let's go and talk about Solutions Engineering, Solution Officer. Saadiq, Saadiq is joining. So, no, the meeting is not specific for Prismic. We're talking about jobs in general, jobs that are also related to some of the stuff that we're doing, but it's not specifically about us, it's about the job in the industry. Yeah, I'm waiting to get a camera on me, but the thing is the idea is, I mean, I'm, and so basically I'm a developer and I felt that sometimes, ourselves we stereotype ourselves too much, and especially the industry gets to stereotype us into like, okay, developers mean write code for like 24 hours, seven days a week, and that's all about it, right? Code, code, code, code which I find that is not true. Absolutely not true. I mean, all the developers that I knew, they did something else in their life, right? They did music, they had guitars, they, my sound, I should speak here, yeah? So, they did something else. They had their, they were passionate about music, about image, about video, about so many different things that that was putting them into some kind of category and I hated that. And I was always thinking like I'm a developer but I can understand a product, I can understand this, I can do more, why should I be in this role? And front end or back end, I didn't like that kind of choice. It's too much, too few for me. So, myself, I evolved into different roles and I'm a software architect and I got more interested in the product and then I became a CEO and all of these kinds of things. But now, in the company, when we're doing this, when we're doing Prismic and building Prismic, we're discovering that there's so much horizon for developers and not as horizon as in things that will be paid less. Actually, things will be paid as much or more, but you need to have some skills and it depends who you are. Some people have some kind of good communication skills. Well, that's great. Developer plus communication or developer plus finding solutions or developer plus growth. This is something that Francois could talk about. Being that person that would care a lot about the business, about how it goes and how can we get more adoption and it will be about numbers, but still a developer, you need to do so much software to get this right. Then you get all about relations, people that can build good relationship, content creation, writing, so many skills that a developer is at the center, of course, at the center, like a company like ours, for instance, it's at the center of everything. But there's a big horizon of, spectrum of jobs. And the idea is let's talk about these things. Maybe people are not aware of them because I wasn't aware that they existed. I don't know. Right now I can maybe right away say like 10 roles in the top of my head that today we have in developers. So this is the idea.

Let's talk about these, explain what they are, and what's important about them. And then maybe you will find, like, oh, this looks more or less like me. I like that. I want to know more about it. Right? And some roles are really related to who you are and what you like to do. So we try to also touch a bit on this and try to give you a perspective on the personalities with whom we work. And for you, it will maybe be a good opportunity to see which one could be a good fit for you. And so just to answer Juan's question about the fact that maybe this is related to Prismic. I don't think it's related only to Prismic. I think it's for all kinds of product companies that have their product, but also have lots of different rules related to selling the product and talking about the product. So the idea here is not to sell Prismic or anything like that. This is certainly not the idea. The idea is we thought let's share what we know about these kinds of different jobs and let people know that they exist and that they can search about them. This is the topic. Yeah, we also interviewed a lot of people for these kind of jobs. So we learned not only about how we do it, but also about how other companies do it and what we should develop.

So maybe we can start. So yeah, I saw your question, Prabhu. Would it be possible that you post it on the Q and A so that I don't miss it? But yeah, of course, we'll touch on this. Prasad, do you wanna go ahead with solutions engineer first? Yeah. So that was the most requested one during the poll that you ran yesterday or today, I don't know when, but about this discussion. So solution engineer is kind of a really wide role and depends a lot on the company you're working for. This is a role designed for SAS company, especially technical one where you are dealing with developers in the sales process, meaning that developer are going to buy or use your product, but also work with less technical products that are not meant for a developer, but that have some kind of technical implementations. Try, for example. It's not meant for developer, but there is a huge technical. They are used by developers at some point. Yeah, exactly. So it's a role that is starting to be a lot more present in the industry, especially in SAS as a whole, company like Tridio with Datadog having a huge team of solution engineering, but the real question here is what is the solution engineer? And as I told, it really depends on the company. So I can give a lot of examples of what it is, depending on the company. And basically, the main point of the solution engineer is to help sales team to sell the technical product to engineers. So it's working a lot on the pre-sale cycle and in some companies, it's also part of the onboarding and also on the post-sales processes. So in the case of Prismic, for example, the solution engineer is working during the three phases, so the pre-sale, onboarding and the cruising, so the post-sales. And they're doing a lot of technical stuff. At the beginning in the pre-sale, there's going to be a lot about custom demos, how to build a demo that is going to relate to the prospects the lead needs. Also helping during the proof of concept because a lot of these highly technical products have a proof of concept phase at the beginning. Should I talk in this one? Yeah. All right. So I'm just going to move a bit. So working on proof of concept, we're basically trying the product in the real life scenario to see how it's going and how that product can help the prospect achieve what they want to achieve. So that's a highly technical profile, but there is also a huge part of the role that is about business. No, no, go ahead. Which is about business. And that's, is also a customer facing type of role, meaning that you are going to talk with customers a lot on a day to day basis, in the pre-sales, especially where you're going to learn more about the leads, about the potential customer, what they want to achieve with the solution. And then a big part of so, is understanding an ecosystem, because if you take the example of Tribe, Tribe is going to be part of a huge ecosystem in the company. If they want to use a payment system, they will have to integrate it in the framework. So you need to understand how the framework works, how you can integrate that in the framework, how are they going to push the data, maybe in all the solutions. So that's where comes the solution engineer name. The fact that you need to solve problems and find solutions to customer problems. Something that it makes me think of, is that it's close to like the work a developer could do in an agency. I know that some of the people you interviewed are like developers who were working in agency, so they have experience thinking about all the different solutions that they want to integrate and make recommendations for clients. So it's kind of similar role, except that you don't really do the project, but you just give advice on what's the best way for the implementation and maybe it recommend specific tools for them. And be more like some kind of consultant. Yeah, exactly. It's being the consultant in the sales process, so bringing value, not trying to sell, just trying to sell by bringing value to the prospect. And that's a really, a more and more demanded job on the market because we realized that having this kind of profile in sales cycles will help close more deals because we are bringing value. So it's like developers, but still they need to be able to sell, right? Sell in the sense because most of the time, solution engineer are going to be... Yeah, I'll continue. This one might change. We are working with account executives, account managers, so these people are going to handle the whole communication, the whole closing, how to make an offer and everything, while the solution engineer is going to bring the technical knowledge to just help close that deal. So they are more seen as a valuable contract material, more than the salesperson. So as you mentioned, we saw a lot of success when people coming from agencies because in a product like Prismic, for example, you are seeing a lot of different use cases and also we integrate with a lot of different solutions. So having that agency background give you the ability to first understand the code, understand the frameworks and as well the ecosystem. So that's a bit about how a solution engineer works. As I told you, it really depends on the company and the size of the company. When you're working in a smaller company, the scope can be super large. As I told you, it's about pre-sales onboarding and also helping customer success to basically bring value in post-sales process. So when the company grows, we see more and more specializations, this type of profile. So people that are going to be more focused on only pre-sales or only working on the sales cycle with a count executive. Other who are really specialized in onboarding and others more specialized in post-sales. So after the implementation of the products, So what you mean is that like if someone goes to a large company and tries to join as like a social engineer, they might only work on the very first moment where the client is trying to decide if they want to use the solution.

Exactly. I don't know if it's Stripe, I don't know if you looked, but like companies like Stripe, they have you work on a very specific moment for people, Exactly. For clients. Exactly, because it's a lot about structure and how you are going to create processes to help the customer evaluate and also see the value of the product. So at some point you need to be specialized also because in the sales process in a product like Stripe, for example, you see so many different use cases that you need to be specialized in bringing value in this use case at the beginning of the cycle. So that makes a lot of sense. Then it depends on the company is the big question about like how much coding is involved in that type of role. And that's also depends on the product, depends on the company. If you take a product like GitHub, for example, they sell professional services, meaning that solution engineers are also going to work on the on-boarding of a big customer with GitHub, and there, they are going to code a lot, they're going to basically being almost like consultant because it's professional services. And then there's some company like ours in Prismic where we don't do that much code in the solution engineering. It's a lot about the product, about how to model the content for the users. So it really depends also on the opportunity and the company. So there is no easy answer to that. I guess it depends, but- And so just to sum up, like what will be the profile for whom you'd like recommend this kind of role? Is it someone that is a beginner? Is it someone that wants to develop, I don't know, his business sense and try to learn how to sell a product and how to make a product as is it like an entrepreneur or is it just someone who is like more of a salesperson but who knows things about development? Yeah so this is definitely not a role that you're going to learn at university. There is no degree of solution engineering or anything. So it's something that we see most of the time people coming from a different background who can be like full stack developer who wants to go into the business side and that feel that that's a nice place to learn about the business and also use the technical skills that are really valuable in the deals. And there is also on the other way people coming from the business side who have a technical acumen and want to basically learn more about the code and also bring business value and technical value in the deal. So that's the two main type of profile that we see in this kind of roles. Also sometimes like project manager coming from agency they have a lot of technical understanding and depending on the company sometime you don't have to be a super skilled developer in the sense that you don't need to write a lot of codes. It's really about understanding ecosystem and understanding the solution and especially the use case. And in some orders you really need to have that big technical knowledge to basically write code because sometimes about building demos, highly customized demos, as I said that can be super technical and a lot about codes. So it really depends. What we saw basically is that the most successful ones are the one coming from the developer background because it seems like it's easier to come from the technical and non-the-business than the other way. But it's really our point of view. There's no truth there. It's, it depends on the product and it depends on the company. But that's basically the two, the two kind of profile of people who are doing solution engineering. This is definitely the kind of role where you need to have some kind of experience. It can be technical, it can be business because you are in front of people with a lot of experience with complex use cases, that need complex solutions. And that's something you need to basically learn while doing code or business. So that's more like a intermediate or senior level position, even. It's pretty well paid, right? Yeah. Because you were close to sales. Exactly. That's the kind of role where you're close from the money because you're basically closing deals with account executive, account managers. So, and also the fact that there is not a lot of people who have that skill set. Being able to code, understanding the technical side of it and as well being able to have communication skills, business understanding and empathic because that's the biggest traits, I guess, for somebody who wants to be social engineers. Basically being able to understand deeply what is the needs in the problem that the customer is facing. So that's a really rare type of skill set on the market and also why people are well paid. So yeah, communication, technical and business, that's the three main thing that are most necessary in that kind of role.

Okay, we have questions also about freelance jobs. So maybe we touch on them. For your question, Juan, about benefits is something that we're going to talk when we go to the second part about the recruitment process and also how you should make a decision on your next job.

Okay, so now that we talked a bit about solution engineers, maybe we can go to documentation engineers and look at what Phil's team is doing. Yeah, sure. So like Nouha said, I don't know how we'd officially class ourselves, whether it's documentation engineers or developer support engineers, but either way, what we do is mostly focus on the client side of things and trying to bring success to users who are using the product. So there's a strong need for someone in that position to have some sort of, at least an interest in being able to teach people, wanting to help people get the best of what they're doing.

So, we have to concentrate on trying to become experts in the user side of whatever product you're working on. So if you're here at Prismic, we have to understand that people are building a lot of different kind of websites with a lot of different kind of technologies. So we kind of have to stay on top of kind of the new technologies that are coming out and also then think of how that relates to our product. So our product in that case is slightly different and some companies where you might be solutions to documentation engineer and you've only got really one technology to concentrate on. Yeah, for you, you have like 10. Yeah, we have to think of all the front-end technologies and how we can best document that for all of the users who might use that. And so that's the teaching side of things comes in. And I can say that everyone in our team has some teaching experience, whether it's myself, I taught a bit of English, Levi taught a bit of Marz and some of the ones that are gonna teach and I know that definitely for sure.

So it definitely- Some did some teaching as well, right? Yeah, yeah. Everybody, Paulina, Priyanka. Maybe not, did Perez ever do some teaching? I don't think he did, he's on the troubleshooting more, right? And that's one of the things that we can also expand about like troubleshooting problems and understanding, but that's something different. But for the education part, I think it's like if you, like if you think that, I mean, it's important, like I was for instance in my preer job and I really liked getting people to understand simple ideas or like even complex ideas in a simple way. You know, you might have a passion for that. You find yourself all the time going and explaining things and trying to illustrate and you're interested by seeing the aha moment in the person where they say like, I understand, oh, I get it and you're satisfied, that satisfaction is important because it means you will get a job where you'll get this kind of satisfaction more often. So it's not a hobby anymore. It's not something that happens rarely. It happens all the time, right? So that's part of the essential part of being a teacher and being in an education team. Of course there are other things but that's an essential part, right? Yeah, but it's definitely. Someone has asked me in the past what's the most rewarding part of your job and it is actually when you see people get that success at the end of it and you can't be like, okay, they've got it. No, we've got it, we're there. And then you can have become invested in people's projects when you're helping all the time with that. And that's what you kind of have to think about. What's the simplest way I can explain these things and get people to that success? And so there is opportunities then if you want to go and explore maybe user experience and design like that there, you can go and understand the analytics of how people are maybe interacting with your documentation. At what point do they get into that aha moment as Siddharth described? And so there is opportunities then to work with other teams and to move in the different areas. And that's one thing I would definitely say that this rule brings in terms of opportunities that you have to partner up with other teams in the company that you're working with because you need to understand the different aspects and be able to communicate that as quickly as possible. Right. And I liked something that we changed about this recently is that it used to be something that we would do like, oh, here's a feature, let's document it. Yeah. But I like how features are getting and products are getting more documentation oriented or education oriented, right. Like from the start of the design of a functionality or from when we have an idea of something, we have someone from the education team with us so that they're thinking, they have a different focus than us. They have like, oh, how can I explain this to people if we end up implementing it? And you're so much in contact with people that use the product that often they would tell us, oh, but I don't think that it speaks to people what you're doing or like something like that. So it's very important, this connection that you have, not only for, it's like, here's a functionality, please go and document it, but it's more like, okay, I'm early in the process. And while we're doing the thing, we're writing documentation and we're changing the functionality so it's understandable. I feel it's also, it's a very important part that we started doing like maybe a year ago. Yeah, because like we're constantly in a position of gathering feedback from users. And so it's not a one way street, it's a two way thing that's happening, we're kind of the middleman between the user feedback, the information that developers are putting out and the communication between the two. How can we best put forward what the users have seen from something and what they want and then kind of make those connections with the developers with what they're creating? So it's kind of a position where you're connecting with everybody and you need to teach and you need to learn constantly as well. So that's a very important part of it. And then like Francois said, the coding part is very important in the sense that you need to, it's not like a full developer position where you're just coding all the time, but obviously you need to stay on top of frameworks and you need to be able to then create a sample project or a website and something like that where you can quickly give full coding examples of how to use your product and how to use it well. But like I said, that documentation part is very important and then your written English needs to be something that is very important too, because not only are you trying to create articles that are succinct and explains often quickly well in a short space of time because you have to think about users time in terms of, okay, they need to read all of this, but they don't want to spend all day doing that. You need to explain it so they get the point that they can build their project and they reached success and that's something that's always in the back of your head. We're not here just concentrating on what our product is. We're concentrating on what the user's projects are, their websites, their applications. How can we get them to the success quick enough? Yeah, and also there are some like engineering, like building basically, because as you said, you have to build samples and stuff like that, but also build in a documentation itself, right? You have to develop the documentation, make it searchable, make categorization. There is a lot of, like how can we build our documentation in the best way so that people can learn from it more easily? How can they find their topics easily, what topics are related and what topics are more advanced? What should we start with? All these kind of things are very interesting issues, engineering issues, right? It's still engineering, like a lot of engineering there. We're constantly thinking, how can we improve that process, make it more efficient, that a lot of the documentation is kind of writing itself and is being delivered in the fastest, most efficient way to the user and are they interacting with it well, or are they getting to a point where there's a blocking point where they've gone, okay, everyone seems to do okay for the first three steps, then they drop off and then they don't learn anything and then we have to give one-to-one support to help out with that.

And do you think it's a good position for someone who is more like a junior and wants to get his or her first developer job? I would definitely say so. I know that it's definitely helped me. My technological skills that I've given up wasn't. Maybe you can talk a little bit about your path into that, if you would like. Yeah, no problem. Into the education team. Yes. I was doing. Because I honestly, I find it inspiring, and that's why I think maybe some people find, OK, is it a mountain? Is it too hard to jump into a role like this? Well, I don't know. For me, I see it as a different road to go on an opportunity, because I did try doing some development jobs in the past. And I didn't get a lot of enjoyment out of only coding all the time. And it's a personality thing. It depends on your personality type and what you prefer. I knew I needed some sort of customer-facing, client-side stuff where you would be able to talk with people, because I had done similar roles in the past, in terms of selling things, a bunch of different roles. But I did work with some development, and then I worked a bit with WordPress, where I didn't have to do so much development. And then I did some English teaching. And it all kind of came together just when I arrived here in Paris, and I met the team.

Levi reached out to me. And I was very clear from an early point that I don't want to go back into full-development stuff. I want stuff where I can use the other skills that I have gained in other jobs. And that made it possible for me to do this job better, I think. So that's the one thing I've always said to a lot of people, don't worry about if you've worked at McDonald's or you've sold phones on the side or something. All those skills become relevant someday and depend on where you go. So you need to find something that matches you. You worked at McDonald's before? I didn't work at McDonald's, I sold phones. You sold phones. I don't think people want to buy food from me. I don't trust that. Like I said, selling phones are something that actually was very similar in the sense I had to educate people about what was in the product that I was giving them and why it matched them and how they could use it, etc. That at all, it all falls in together.

I'd like to know from the people that are listening to us, what do you think? Because we still have quite a few roles to talk about. So far, do you find yourself in one of the roles that we talked about? This might change when we present the other roles. Or maybe you know the other roles. But if you can write in the chat a little bit about what you feel now and if any of these correspond to you or you feel like, okay, that might work for me or I'm not sure, please let us know. And then we can describe others and see if you change your opinion.

So can we recap, yeah? So we talked about the solution engineers? Okay, it's not my area, so I will try to recap. Solution engineers, so they work with more of a sales team and contribute for everything related to setting the product and the value of the product for developer roles. Can you hear me? Yep. And they're more like people who act as consultants. I'm checking, I think it might be the wrong way. Okay, is this one better? Okay, actually Phil has the best mic. So yeah, I was saying, they work as consultants, they're here to sell the value of the product, so they're in the middle between doing some kind of agency work, where they're consulting and trying to recommend the best solution, but also doing some kind of business role where they want to also see and have a strategy to show that the product has lots of value. And so they're more experienced people, if I understand well. Yeah, I would like maybe to come back to this one because I think it's also related to the company and the product, because I said it's for more experienced people, I guess in smaller startups and smaller company, it makes sense to have the experience. But I know that nowadays in bigger company, they have a program to basically have people junior joining as solution engineer and to grow in the role in these kinds of companies. So it works for both. For junior, it's better to go in a bigger company with a solution engineering. So any type of big SAS, and then for people with more experience, intermediate or senior, it makes more sense to go in a smaller startup where they're going to do a lot more than just following the processes. It's going to be about building processes, about all that stuff. So I like this idea. So basically you're saying two categories. One, you could go into an earlier stage where there will be a lot of things to learn and it will not be like following a concrete process, or you're more, you want to get into some already set up company later stage, right? Yeah, exactly that. Where there are processes, you follow them and you're more, there's more stability, more, I don't know... How you call it? Order in place. More processes. More processes. Exactly. So I think Joanna is more on the solutions engineer team. Yeah, seems like it. And what you described as a career may make a lot of sense because you have that marketing background in the IT company. So working on a tech product, especially if it's something for marketeers people, you're going to bring a lot of value because you understand the ecosystem. You understand the needs, maybe more than somebody who was a developer before. So I guess you have an interesting profile for that type of role. Cool. And so if I want to sum up the documentation engineer one, it's more, it can be like a beginner role for someone who wants also to have some kind of communication or like connection with the community. And it works really well for people who have some kind of teaching experience since you're gonna be teaching people and writing the documentation for them. Right? Am I right? Yes, you are. And you need to have very good English, I suppose. Yeah, but to go back to that point that you made about the beginner part of it, what Sudeik was getting at with my story is I came in with a very low level of technical skill because I had kind of backed away from the industry and didn't really know if I wanted to continue. But when I came in and I found the right team that were helping me grow and letting me ask stupid questions and it was a kind of a nurturing environment where I could actually learn for the first time instead of just turning up. I really then grew into the role and learned a lot of technologies and maybe it's just the way my scatterbrain works that I learned a bit about one technology, learning a bit about the next and jump around all the different front end technologies that were there. I learned a lot very fast and grew really into the role and I know if I went to search for another role tomorrow, if me and Sudeik had a big argument, for example, I could find at least a better job than I could two years ago. So it is a good opportunity. I didn't think of that. You have a question from, it's for, I think, for you, François. How can someone who has just graduated become a solution engineer, being less experienced with a candidate like this be considered relevant to develop solutions?

Yeah. As I told previously, the experience really depends on the structure and the organization that you're going to join. For example, if you think about a company like Salesforce, they have hundreds of solution engineers, so they have the whole program for graduates to join the team and to grow into the role. So it really depends on that part of the thing. If I take a company like ours, Prismic for example, we don't have that organization yet. We are building the solution engineering organization, so we're looking for people with more experience. So it really depends on the company, but in bigger company, there is definitely room for juniors to join and to grow into the role. So that would be the best way to maybe start a career there, is to go in maybe bigger company, starting series D I would say, it would have at least a structure of a social engineering processes so that you come into the role and you learn it from the existing clients, with existing processes and everything. And then after that, you can jump to another one and go into a smaller company or a different company and also build stuff if it's what you'd like to do. Yep. So maybe it's time that we go to my part, developer experience. So developer experience. It's a very wide topic and you can put a lot of things in developer experience. So basically what it means and where you will find the developer experience role is for products that are made for developers or at least are used by developers at some point. So I think for instance, if we take the example of Stripe, I imagine that Stripe has a developer experience team and most developer experience product have. And so the role of a developer experience team is to be the voice or make the relation between the community of people who use or might use your products and the people inside of the company. And so they bring the voice of developers, of users inside of the company when it comes to... When it comes to... Sorry, I read the comments. So when it comes to the product, so for instance I know that some people in my team, they go to the dailies of some product teams to just make sure that everything that we develop is relevant to developers, but they also work very closely with Fieldsteam to make sure that the documentation is also very relevant to how developers want and learn. We also work online for things that are more related to relations. So giving talks and trying to present the product to people and getting their feedback so that we can take that then to our product team. So we do lots of things, but the idea is it's really something that is made, I think for people who are passionate about technology and but also have very outgoing and like to talk to people and to bring back feedback to the team. And it's also for people who have a lot of empathy that don't think that their own ideas are the best, but more like try to understand what people want and just bring it to the rest of the team. So these are the people that we have in the team.

I disagree on maybe one point. Go ahead. I mean, kind of disagree. But I mean, outgoing might mean a lot of thing to other people. Like we have people in the team that not exactly the outgoing, but they like to have friends in other frameworks and know about what's happening, their new stuff and then do something about it. And then like, you know, we will know what's happening in next community or in the next community or in Gatsby and Next and React. And then we will say, okay, we have turn up to this. We have to do something about it. So that's not exactly like, okay you're not talking to the outside, but you like to have relations. We have to be approachable. Like people should feel comfortable talking to you and giving feedback and think or feel that you truly want to get their feedback and to help them. And you're not just trying to sell your product. Actually, like for us, our focus is not to sell the product for the team. It's more like to improve the developer experience so that in the future, we get more people signing up, like recommending the product and then staying with it because the products will be good and they will know and understand it right away. I mean a lot of companies, it's funny how, when things get like a bit fashionable then like companies jump into this and like, oh yeah, we should hire developer experience and then developer experience, a person will ask them, what should I do? Oh, you should go and talk about the product and you know, all of that. Which is good. I mean, if you like to talk and you like the product and you're not spread the word, that's a great thing, but developer experience, the term has experience inside it. It's like a user experience. It's more, let's learn, let's learn. It's about learning from the community, learning from people and then doing something about the experience about it. So this is a very important thing.

Yeah, yeah. Marcin is saying, I think each company should have something in a kind of manifesto where the path and the roles that can be taken on a given path would be described. Everyone could then manage their own career in that company more easily. Yeah, absolutely, absolutely. Like for instance, you could see like someone that is starting by being a developer experience at some point being interested to be a solution engineer because I like to see more, talk to clients and understand their problems and help them solve them. And I want to work one to one instead of one to many. Okay, nice, you can do that. Or people who are in the product team who at some point they get tired of shipping features and they want to be more exposed to the community and they switch to something more like developer experience, things like that. So that's happened as well. Or like, oh, I joined but now I really like this growing business and revenue and these kind of topics. And I want to spend some time on that because I want to combine the business skills with the engineering skills that I have and I want to develop myself there. Yeah, there is a place for that and it's a very important role in the company. So yeah, I like this suggestion that there should be some kind of a way of describing what are the opportunities how can you move even inside the company. Yeah, I think also there's a question about how do I progress that they don't get in one role and then I'm like trapped in them or like at some point I get bored of doing the same thing for years. We touched on that a little bit after when we talk about the recruitment process but it's important also for you before you join a company to ask yourself what you want to get and what you want to develop. Like if you think you want to become a manager it's important to say it and to try to develop this so that you can become one. Some people don't want to become a manager they just want to explore topics. So as soon as this is explored they would go and like look at something different and it's what they like. They don't want to manage people they want to just go and explore new things. And so it's important to know that and make sure that the company knows it before you join them. Okay. Okay. Hello. We have a question from one as well. It seems that most people strongly relate years of experience with level of experience. How can we break this relationship? What separates a junior to a senior on the roles in between? And most importantly, what can a junior focus on to grow as a professional faster faster being more efficiently? That's a really good question. I guess maybe we can touch on it after when we talk about interviews because this is also related to the way hiring work today. When you have hundreds of resume and you have to basically do some kind of sourcing and everything and basically understanding people's skills in one page, that's super hard. So I guess that's also where it's coming from because of the volume and everything. But I guess we can discuss that maybe in the second part of the talk. Yes, maybe, go ahead. Okay, Patrick. Again, I would like to have some kind of feedback from people that are with us about this different roles. So to remind of what we said, solution engineers, okay? We talked about education engineer, right? Documentation engineer. Documentation, yeah, we call it education. It has several facets to it and then there is the developer experience. We talked about this. Now we have three roles, three different roles, right? So I'd like to see if people, well, again, find themselves in one of these roles or if they've done it. I mean, maybe we have some people, certainly we have some people that did one of these roles and we can learn from them if they can write a comment on the chat and send it to us about like, okay, I did this job and this was my impression, maybe good impression, maybe bad impression, and we can talk about that. It will help us also talking about other topics. So yeah, go ahead. Oh, I was just reading a question from an anonymous attendee. Can someone from one country apply as a solution engineer in another country, how likely is this kind of get hired? I guess it totally makes sense. Once again, about the company, it depends on are they remote friendly? How do they handle the sales process? Because some company, like especially the enterprise tier, sometimes still doing a sales process in-person, but it's less and less the case today, especially now with the pandemic. So I guess there's a lot of opportunities today also for people who want to join a company from another country, especially if you have that kind of skills, that's something I'm sure of that companies are looking for social engineer, even if they're not in the same city or same country, because it's really rare on the market to find good social engineers. Yeah, I wanted to say this. It's a rare profile, everyone is looking for this. So if you think you can be a solution engineer, a DevEx, or, yeah, in documentation, all of these are rare profiles. There is a lot of demand on it, extremely a lot of demand on it. So this is a time, and if you go remote, so basically if you go for other countries, then there's even more importance, for a lot of reasons. One of them is like, a lot of companies are looking for that, so you will have more offer. The other thing is like, companies they look for, different to covering different time zones, for these roles. So, that's a great opportunity as well. So it's a very good question and I think that, yeah, you should consider all opportunities. Yeah, time zones, markets, a lot of opportunities, especially right now, with a lot of SASS companies going public, and the high growth we saw in the last year, it's a lot of opportunity in that field. You have a note from Lutmina. The social engineer role seems really nice, it requires different skill sets, which makes the job less boring. Didn't know so much developer roles existed. Awesome, well that's, that's the mission of this workshop. We have one last role that we thought might interest you, and some, a lot of you actually voted for this one. It's growth engineer. So same as going to be Francois, touching on this one. Yeah. You want to go ahead? Yeah, so growth engineer is maybe even newer than the social engineer one, and it's also super wide. I guess that the sense of it is that, it's an engineer that is going to work on growth projects. So any type of project that is going to have like a direct business impact, because you can say, yeah, so a big part of the team is working on business impact because at the end, we are selling the product, but here it's more like working directly on the customer acquisition, customer monetization or retention. So really, like big business KPIs and influence them in a direct way. So that's- Do you have an example of something like that, like in a company that- And maybe also Francois, if you go through the different KPIs, well, KPI, as in key- Performance. Performance, indicator. Indicators, yes.

So basically, if you going to go and explain them a little bit and why they are important and then how a growth engineer could have an impact on that. Yeah, basically, growth. What is growth? Growth is what is going to make the company grow, obviously. So these KPIs are going to influence the whole business because basically, if you have a better acquisition and that you still monetize your user, you're going to have more money in the bank. If you have more money in the bank, you can grow the business, hire new people, create new teams, have a better product, sell it better. So that's why they're so important to work on. And that's why, there is growth team creating today. And one part of the growth team is the engineering part. And there is two big type of growth engineer I would say. So the main thing about the role is it's a mix of technology, data and marketing in a way because you are going to work on these business KPIs. And there is basically two spots where you can be. There is a growth engineer as part of a product team, that's something we discussed yesterday with somebody from a Hodger. So there is growth engineer inside of the product team, so they're going to work on initiative inside of the product to work on growth. So it can be really wide, it can be for example, experimenting on the signup process to see if they can have a better conversion rate on the signup, because if you have a better conversion rate on the signup, you're going to have more users. If you have more users and the sales team is working well they're going to monetize and if you monetize, you have more money. So it's working on these really important projects that are really designed for growth to impact these KPIs. It could be also as simple as, I think we need to make this feature more popular and how can we make it more popular? At which moment we need to talk to people about it, suggest it, I don't know, all these kind of things. So it could be, it doesn't have to be about making people pay. Sometimes is about making people pay, maybe about making people advance, understand something. Maybe a feature that no one is understanding and then understand why people don't understand it whereas we feel that there is the need for this kind of feature. All of these things, is some kind of engineering to get some kind of statistics, some kind of numbers. Right? About the functionality, the product, the thing and then making decisions about it and experimentation, as you said. Exactly, it's a lot about experiment, about the hypothesis. Like, I think that is action is going to impact this thing. For example, having more users and from that I know that we are going to have more revenue. So I'm going to try to prove with my code that I can build this thing that is going to impact that. And so, one of the interesting thing about the role is that you're working on code that maybe will be thrown away in two weeks because it doesn't serve the purpose, the experiment doesn't work, but at least you tried it and you have the proof that it doesn't work. And if it works, it's great because that code is going to be in production and you're going to have it for years. And that's also really close from the production level because everything that you're going to create, you're going to experiment with real users, so it's not only about building a backend that maybe is going to be used by the product team in the future. It's really about like concrete stuff that is going to impact the business. So that's the first type of growth engineer working on the product team. This is something that we see more in a company like product-led growth, meaning that company that are growing from the product, GitHub is a really good example because the company is growing from people publishing stuff on GitHub, inviting their friend or other anonymous to basically work on open source project. So they're going to grow from the products. On the other side, you have some type of company, maybe more enterprisey, also more expensive targeting enterprise that are going to have a higher price range and that can have a growth team that is outside of the product. And these people, they are going to work on initiative that are outside of the product. So it can be like landing pages to bring more traffic to the website and convert this traffic, not just only having the landing page and seeing how it goes, but really having a clear goal with the landing page. It can be also like building tool internally for the team to, for example, for sales team or for customer success team to have a more efficient way of working. So it's a lot about code, script and business understanding also, because you are as a solution engineer trying to solve the business issue but the internal ones, so not the one from the clients. So it's a really, really interesting combination of skills such as solution engineer, maybe less communication, a lot of empathy as well, because that's the kind of role that is working with a lot of different teams, like can be product, sales, marketing. And so all these people have different point of view on things and you have to help them achieve what they want to achieve. So yeah. I would say I, I'm impressed. The passion that how much you're passionate about this role, this is Francoise's favorite. If you didn't decide it already, let me tell it to spell it out. It's Francoise's favorite role. But the thing is that if you find yourself talking about these kinds of things with the same enthusiasm, well maybe probably this is a role for you. Yeah, like I know some people they read about how companies like GitHub grew or like how Stripe, or I don't know, Airbnb. What's the story behind it and how it became a big thing. I think this kind of people who are interested in how to grow a company are very good fit for this kind of positions because you need to think about okay what is the technique, how would I make people use this feature more, how would I bring more people to know my company and all those kind of things. And I see Joana saying definitely growth engineer sounds even better than solution engineer. Ah you're changing opinions here huh? For me with a marketing experience yeah that really helped design SEO and conversion understanding these kind of notions as well. That is what I would really enjoy doing to try to create the product even more attractive. Yeah yeah, this is, if you like this. And it is even, you know I don't know if you're interested in marketing SEO on these kind of things and you also like automating things. There is another one. There is a marketing acquisition automation or life cycle but we didn't think of talking about this one but if you connect with marketing then there is a lot to do there as well right. Yeah that one is really marketing related even if there is some kind of engineering point of view on it because it's a lot about KPIs and everything. I guess this one is really about marketing. Life cycle marketing which is also even newer I'd say this one is too yeah. I want to answer, I don't know if it's Juan or Joanne I don't know how to pronounce, it depends where it comes from. But no it was more of a joke like Phil's answer was more of a joke so don't worry about it. It's just the social engineering. I love the idea like I love studying the idea. It's just like it doesn't fall under our scope but I mean social engineering, maybe it's not about trying to hack people but more understand the holes in the system to understand like how can we protect from them basically? But yeah this is not what a major focus for us but I like that you shared with us the definition of that hole. To go back to, I see Joana is hesitant maybe between solution engineer and growth engineer. Imagine if someone is hesitant between the two roles. How can you help them decide? Someone is saying I like business, so I like seeing customers and I like convert like helping closing the deal, I like helping with that. But that growth engineer thing is also interesting because it talks about KPI and growing the revenue I thought we just said your growth engineer is better because you help them. No, not true, not true. I guess the biggest question is like, do you value more talking with people and understanding their problem, or do you value more building stuff? Because I think the growth engineer is really about building.

And one of the big traits that we're looking for in this kind of role is people who want to build a company in the future, who wants to create their own thing, and who want to grow that thing. So I guess it's really the main difference because yeah, the Center of Social Engineering is about dealing with people, and on the other side is dealing with business problem and creating a solution internally for that. But yeah, both are a mix of that, sorry, of business and technology, and it really- And let me comment on the building part. Both will be building. I mean, the other, you will be building solutions for clients and helping them build their solution. But I guess it's more there's one that is kind of building some kind of engine, right? It's more engine. Whereas the other's more result-oriented. If you find yourself, you're satisfied, you find your satisfaction in building something and looking at the result and it looks beautiful and it serves the goal and that's where your focus is, then maybe it's more towards solution engineering. If you're more into I want to see an impact on numbers. Numbers are important for me. I want to see things growing and I want to see them growing quickly. Well, that's the other maybe or all. That's when also like solution engineering it's a lot also about processes, right? You want to, like let me give you maybe a picture of it. Solution engineer, you will get my understanding and you correct me Francois you know better. But you get into a client, they have a certain problem and they want to solve it with your product, right? Imagine I want to build a website that is sophisticated, has these things and these things, all right. Well, let's and then you will set milestones with the client. Okay, we tell them, okay great let's start first to make a test or a proof of concept. And the first thing we want to make sure that this product works for solving point A and then two weeks after we will talk about point B and C but seems the most important thing but it's like also a bit of project management, right? And their solution engineering. So that's very important to be able to interact with the client, put some kind of milestones to help them navigate through their problem. They will come with a complex thing and it's not exactly explored and you will say like, okay, let's take it step by step. What's most important? This, okay, let's solve this. Next priority is this. Okay, now we explore the thing, seems the solution is working for everything. Maybe next step is like you should start and build the stuff. So it's more about that, right? Yeah, definitely it's also a lot about structure and then there's also the satisfaction that you will get from your job. Like in social engineering it should be a lot about success of the client, maybe big deals as well because it's a sales function in the end. Where the growth engineering, it will be more about like business success internally and there is crazy stuff that happened. Like if you take the example of Facebook, the growth team, that's who created the success of Facebook. They found that metrics, that was the number of friend that you need to have to basically stick with Facebook. I think it was six or seven, yeah? Seven. And that's the growth team who realized by doing analytics like, okay, we see that people want to have seven friends to stay longer so we are going to create initiative around that to have people inviting their friends. And then you have a lot of feature that were developed for that, like sending an email to tell you like, you need to invite that and that coming from, I don't know, like your phone number or anything like that. And that's what created the high growth of Facebook in the end and that's growth and that's different type of satisfaction, I guess, really depends on the person. I'd like to jump back to, we have two very good questions that we have to answer, really good questions, and I would like to have even more questions. This is making the whole discussion more real. I think we're gonna have even more when we talk about the recruitment process. Ah, you think? Anyway, this is like, whatever you think, you know, maybe you know, you're thinking, and I like one of the questions that we just received, is like, and we're going to go through it, but just to give you an idea, it's like, okay, maybe if I like these roles, how can I go about starting to apply it to them? And this is the right question. This is what you need to learn, right? And maybe we can help you with that. So any question that happens to you, just, you know, throw it, send it through Q and A or the chat and we will... It will make this discussion more dynamic. But I wanted before that, before going to these two questions, because you know how, maybe Francois could help, if I'm hesitant between, I think it's... They're very relevant, related, sorry, related. DevExp and SolutionEngineer. How can I know which one is the best for me, right? There is DevExp and there is SolutionEngineer, and they're very close, you know? It's funny, because lots of people I'm interviewing, sometimes they're telling me, I'm having other interviews with this company and it's for SolutionEngineer. So I think it's kind of the same people, because both of them are like, developers who are interested in like, looking at the project as a whole, and then understanding all the different integrations and not being focused on one technology on one thing, but really thinking about the developer experience behind the project and what should they build and how should they build things. And not wanting to be in a product team, but want to be connected to people. So whether they are in the companies and building like one project or like just the community of people using your product. And, well, I have my preference. But I... No, but if I am a person, I'm ahead of you. Yeah, I think developer experience is more on like, you don't have this like, it's not the same reward, like I think in SolutionEngineer, you have the reward of like, yeah, we want this lead and you may be more like competitive in growth. In DevEx, but it's more like- I have a lot of friends. I have a lot of friends. I'm invited to conferences. I am featured in this newsletter. I... When I do my stream people come and they know me and they trust me. Like it's a different way of building relations. One is like you're gonna be trusted by like a dev team in one company and you're gonna have them with that project and maybe it will be a bit more complex or you're gonna have like more specifics about the project. The other is more about the mass and people, like a lot of people and lots of maybe many times junior developers. So helping people and teaching them and making your products easier to understand by them. I think there is also the technicality of the role where maybe developer experiences, people will maybe a bit more in-depth in the understanding of the frameworks, understanding of the different coding stuff where in social engineer, maybe tow more into the business side, even if you need to understand stuff, maybe not as much as you need in the developer experience role. And by the way, I know that Francois, you're recruiting for both roles, social engineer and gross engineer. So I thought of making a little site for people to be able to receive the job posts whenever they're ready. So I'm gonna post it here. Should we go through the two open questions maybe in Q&A? So yeah. So self taught devs looking to break in, how can they tailor their portfolio for these roles? Yeah. Okay, I want to start, I choose one of these. Okay, how can I make it...

Um, well, yeah. How can I change my CV, my portfolio, my everything when I want to apply for this? I think like, well, your portfolio is your portfolio or like your CV is your CV. So you will not make, invent experiences that you don't have. But I think what people interested in, like me, when I look at the CV, I look very quickly to be honest, and then I'm trying to look at like the owner, but it's for my kind of role. So more like developer experience and community. When I look at the social profiles of the person. So, for instance, we have someone in the team and she's pretty junior. Like she's still at school, but she makes a lot for the community, and you feel that she's interested in helping others, maybe more than people who have more years of experience. And so this counts a lot for me. So, you know, when you receive a lot of applications and you have lots of CVs to look at, sometimes you just look at the very first lines of the CV and you try to understand who's the person, and then you want to just dig deeper on like one specific thing. So, for instance, to me, I like when there is like a specific cover letter, but not like a cover letter, but just like a paragraph explaining why you want to do this exactly and what you think you can bring to the position. And this for me also makes a big difference between just like looking at the CV. So many times I don't really look that much on CVs, to be honest. I read, I just look at like it's okay. It's not like unrelated at all. And then I look at the profile of the person and if they wrote something custom, I read it for sure. Yeah, I guess for developers, it's a good sign to see self-taught developer because it's people who like to learn, it's people who are able to learn by themselves, which is a really important traits when you're joining especially a startup because you are going to learn a lot of stuff. Also by yourself, the company is going to bring you stuff, but you need to be able to learn. So I guess in our side, we mostly never check if somebody is coming from a specific school or anything. It's just about the skills. And I guess on the growth engineer role, it's important to have some kind of growth mindset and that you can only achieve it by doing stuff, by doing a project, a personal project, trying to make grow that personal project. And it can be from one user to 25, but just understanding how you go from one to 25 and then from 25 to 100, or maybe something like that. So it's really important to do some stuff, even if it's at a small scale, to really understand the thing because that's the best way to relate to it. And then when you have that, that's a super great thing to talk about in interview because you are talking about something that you understand and something that you did. So for that role, I guess it's a good way to do it. And that can be like growing an online community about something like kite surfing, or I don't know what. Weird example. I mean, maybe I... You're a lot of kite surfing nowadays. Did you plan it or did you? I'm not sure. I think there is, maybe the most important thing is like how can you talk about your experiences, the things that you did in the past, and show how relevant they are for the role. Imagine, okay, solution engineer, or like, okay, I did that, I did that, I did this, and they, I think they are relevant to this job that I'm applying for this and this reason. The solution engineer, I like it. And in the past I helped a lot of clients build solutions by helping them choose the best tools for building that solution in an agency, for instance. That's relevant. When I look at that profile, I said, okay, at least that person understands what the role is and what's necessary, what's required for this role. I don't know, for DevExp, like, okay, I did this video to explain this kind of concept and this way we can see, okay, are you good at explaining concepts and stuff like that? So, make any experience that you had in the past, try to look at it from that angle and see how did that teach you? How did that teach you? As Phil said, Phil, when we were talking, when we had the interview, if you remember, was like, I was in this mobile shop, right? And I would have all these kind of cases where you have to be patient with the client, right? Because they need something and now that's what they need and you need to listen to them, even if it sounds like unrelated or something like that. And you talked to us about several situations that happened in that shop where. That you're patient and you. And it was clear that you were a patient person. And that's what made me say like, oh, okay, Phil really fits in the goal because you talked about your teaching experience, it fits very well. You talked about your mobile shop experience. You wanted to listen to customers to solve their problems and all that. To help them with what they're doing. So you made every experience that you had in the past relevant to the role that you're looking for. So that's maybe for me the major thing. Like re-imagine all the experiences that you have and how did that contribute? Everything contributes to something. The fact that you today, you need, you want this role. Imagine if today I want to be a growth engineer. I have a preference, I like it. It's because I learned several things in my career about relevant to that job and I'm feeling that everything fits now. The picture is clear and everything is making sense now. The fact is everything is making sense. It means you have a lot of experiences that led you here. Well, talk about that story. Talk about how this and then that and then that and that got you closer. Now you see, okay, everything is making sense and that's why this role is the right role for you. I think this is a good way of talking about it. Yes. Yeah, and just so, since we were talking about applying, I feel like you shouldn't hesitate to apply to a role that you think you would like doing. Many times we write like a wish list of everything we would like for the role. But many times also, like it's not like we're checking the boxes. We're just like meeting the person and trying to see if this person can help or bring something to the team. So just knowing the person it actually helps and we just talk and we see if the person could fit in the team. And then if they can bring us the help that we need for that specific topic, when we're looking for someone. So, yeah, like don't like verify that you check all the boxes. Just apply and like nothing will happen if you don't get the job or if no one calls you but at least apply for everything that you think might interest you. Yeah and it's important if you get to that stage that you see if that company fits for you too. Yeah. So if you apply to a role you're excited about, you wanna jump in and you meet them and you think it's something you might want to do but then you kind of force a square peg into a round hole and it doesn't work out in the future and that's why you have to be honest with yourself and honest with the people that you're interviewing with because essentially just that goal is trying to see if you're gonna work together and if you are someone coming into grow into a role and you're not honest in that first place you might not be able to reach that point that you want to get to at that time.

Yes. Yeah, I agree. Yeah, it's important to ask yourself what you want to develop and also tell it to the company because people need to know so that they help you developing that. And so that's like, in general, when you're in a job it's important to share what you struggle with, I think, and let people help you instead of like proving, like trying to prove that you can do the thing and hiding what you don't know how to do.

I think that's a great point. It's not only about, I feel it's not only about hiding or not hiding. First, if you don't, if you don't make the whole checklist, not that important. What's really important is like the story. Why does it make sense? Because, you know, I would take someone that doesn't know everything, but I see clearly that they learned a lot in a few time. You say, there's no risk. They learned and they won. They have motivation and they can learn. Motivation plus they know how to learn, it means they will make it, but at least show the motivation and show that you're relevant, you're relevant, but you don't check all the boxes, but you can learn it. And that's good. That's good enough. As long as you got the basics.

And then about the company thing, it's not only about like cheating and not being honest or these kind of things. No, no, you will find, honestly, in these roles, you will find yourself with a lot of offers. There is a lot of offers out there and you need to choose to be comfortable to work with the people and people as well as a company. Like, okay, you might see a very good company and you like that company and you always liked this company because you work with their product and stuff like that. But look at the people that you going to work with. Do you like talking to them? I see it always when we talk to candidates, I always tell it. And maybe it sounds weird in an interview, but I like to say it each time. Like I said, like, look, it might seem like this is an interview where I'm the boss and you are someone that is coming here and you are here to prove me that you are strong enough so that I take you and pay you money. But it's not about that. It's about you choosing me, me choosing you. And it's important that it's, we are on the same level. No one is superior to the other, okay? You want to find something that checks the boxes for you. You have a career path, you have financial requirements, you have several things and they are as important as mine. So we're on the same level, that's important. And we are here to test our collaboration. We're not here to try to impress each other. That doesn't work. You can impress me in a 30-minute, I can impress you in a 30-minute interview. We can do that. We do nothing. But then what happens afterwards is a waste of time for everyone because you will spend months unhappy at the company because you try to impress. No, no, just say what you can, say what you can't, I will say as a company we can provide you what we can. And if it's a deal, it's a deal. If it's not a deal, it's better to be clear since the beginning that it's not a deal. You can like it that way. Maybe this is not the standard thing that happens but I love to do it that way. At least we're sure, we're clear, we're honest. We see things that way. Right? Yeah. I think this helps. And what I say also in interviews is that, I don't say it but I should maybe. But is that I want the person to succeed. You know like me when I'm interviewing someone, you need the person, like you need someone to join your team. Like you're not here to trick the person or to like to show them that you're smarter than them. The only thing that you want is that they succeed so that they join your company and then like your problem is solved and you have someone to help you. So. Moreover, you want them to be smarter than you. Yeah. No but honestly we are. We repeat everyday. We need to find people smarter than us. This is how we can build a better company by finding people smarter than us, right? So questions are not like tricky questions or like yeah, and if you don't know it's okay. We're just trying to test the collaboration and also we're hoping that you will succeed. So, and we have lots of things to do also and you have lots of things to do, so we're taking both of us time to talk to each other. And so this should be like useful time. So also trying to make it as a conversation as much as I can.

Yeah, definitely. And especially to follow up of what Noah said about the boxes of these roles. They're so new that most of the time, we're not looking for somebody who already did that. We're looking for somebody that has a relevant experience as Alex said, like the example of Phil. Because obviously this job, they are born like five years ago, 10 years ago. So there's not a lot of people with that experience. So we are really looking for people who can just show us that they have relevance and that they are relevant in that potential position. Yeah, you need to see what skills you're bringing to the table that can match the role.

And that's what helps you kind of, you know, it's like when you're applying for jobs, you skim through and you say, I do that, do that, I can do that and that. And then that's kind of where you have to match all of your experience to what they're looking for. And if it's something that's a role that you are going to grow into, then that's the important part where you need to ask those questions. You know, there's parts in the interview where people are like, oh, do you have any questions for us? And you can't think of anything. I think I asked about like, do you have subsidized meals or, you know, take a rest over there and I was just sweating, you know. But what you need to ask is there is some areas that I'm weak in. Is this somewhere that I'm gonna get the support to grow into that role? Am I going to get that help here? So, you know, that you can advance your career. Those are the types of things that you should be asking. It's more about how can you push yourself further? Yeah, I remember me, I maybe, it was weird when I interviewed for British Make, I wanted to meet people because, and it's weird because, you know, maybe some people in interviews, they want to go quickly, you know, they don't want to meet too many people. But yeah, for some people, it's like, I want to see people because I know I'm gonna be working here for years. And so I want to make sure that I like them. Some people is like, I want to get my meals and have yoga classes. It depends on you. But it's important that you ask the questions because it's a big investment for you too, you're gonna be in this company for like that company, this one for years, so you should be sure when you take the decision to join. And by the way, this is my way of doing it. When I am an interviewee and someone asked me a question, imagine I'm interviewing, that didn't happen a long time ago, I'm seeing, but anyway, maybe my knowledge is outdated in that. But it's, if for instance, you don't know the role exactly, as we said, right? So you should engineer, you're new to that, but everyone is new in the market. You don't have many people that know that role. So if I ask you like something, and then I start talking about like some acronyms or something like KPIs, do you know this and that? And then, no, I'm not talking about you Francois. And then you don't understand another problem. I think you can say like, can you explain it to me? We are testing the collaboration, right? We said that. We are testing here the collaboration. So we're testing. One of the things that you need to test in the collaboration is like, actually it's the most interesting thing. Like if someone doesn't know, if Phil doesn't know this, what will happen when he will join the company if he runs through something that he doesn't understand? Will he hide it? Will he just not talk about it? Will he ignore it? Will he say like, ah, okay, I understand. Or will he like go and... Ask questions about it because, okay, well, I understand. I don't know everything, you know, humble, no problem. But just, can you tell me what does that mean? First, good reaction. It means Phil can learn in that kind of case. Because if Phil doesn't even give me the opportunity to teach him the thing or to talk about it, then I will never know. And you know, you will not know about this topic for a long time. Whereas if you tell like, I don't understand this, I'm sorry, maybe I'm supposed to. But explain it to me. And when someone, I explain it to Phil, I get the opportunity to ask questions. Did you understand it? What did you understand about it? And then we'll see. Okay, how is the learning process going? And then, I would see like, oh, Phil really, I mean, this happened actually for you in your homework, right? Maybe you can talk about this? You remember it? I can remember it like it was today, you know. So the whole thing happened is that, Phil came in and like, oh, we so much wanted Phil. Everyone in the team wanted Phil. And we're like, ah, yeah, we really like him. This is our guy, you know. We need someone like him. And then we went into the homework, like, look, Phil, you need to build this and this and that. And then went through the thing, and Phil didn't build this. And we're like, so, everyone was disappointed. Everyone was sad. And I was like, in the middle of four people disappointed, and Phil doesn't know what to do. And I was like, oh, what, shit, what is the situation? I was like, how can you solve that? Like, look, Phil, okay, let's do this exercise. You have one hour, I guess, well, 30 minutes, I don't remember. And you have this one hour to build this, right? But you don't have to do it on your own. You can ask people around you, this is your team. Consider it your team. You can learn anything from anyone around you. You can use internet, do whatever you want. The only thing that I want is when we get back on the table, that you explain it to us in simple term, your education. You're not supposed to know everything, you can learn things, but once you learn them, I want to see clearly that you can express it simply, and you can teach it to other people. And that was the exercise, right? Education team and documentation. This is what's important. And actually it went really well, and this is the moment we saw, okay, that small failure that happened, actually it was an opportunity to understand Phil more, and understand, okay, how can we develop. So we tested the collaboration, right? That was an interesting thing. It must have been stressful for you, Phil. Oh, yeah. It definitely was. Because like Sudek said, I came in with work and homework. As soon as the questions came, I had nothing to give back. I just sweat, that's all I had to give. So yeah. And after Sudek gave me that opportunity, and I'm like, I took the hour. And like I said, people were going up and talking me on, how it's going, and they go, do you need help? And it was actually genuine questions, because some people didn't even realize I was on an interview. And so afterwards I explained it, and Sudek was like, yeah, yeah, cool.

I realized then also for me, like this is what I'm looking for, this is the opportunity for growth, personal growth. And I said that stuff and I was very clear about it. I might not have all the technical skills that are needed right now for this job, but I really want to advance, and I am willing to do my learning and the hard work, because that's what I wanna do, and it matches exactly what I've been looking for.

And like I said earlier with those questions, you should ask, is this the place that I can grow? I didn't have to ask the questions at that point, because Sudek, and everyone in the company, then made it very clear for me. And three or four years later, now, I don't know how many years you've been here, what do you think, like did it? Yeah, it worked out all right, you know? Did it look like the interview? A bit better, a bit worse? Yes.

Less sweat. Well done. So we have a question from Juan, and I don't know if it's Juan, I'm gonna keep saying Juan. And Milos also asked, because he said he's interested in this question. So it's the one about, people caring more about years of experience versus level of experience. And how can you balance that and like gain experience or level of experience quicker without having to wait all the years? I think something that we try to balance with that is that, we don't filter, I know for most companies, but we don't filter that much on years of experience. It's more about like what you've done and if you have like one experience that might be relevant to what we're trying to do. And then it's enough for like what I look at and then you have the homework. And so the homework is the moment where you're gonna be able to judge on the level of experience. And so I don't know, for instance, I know for the, we had, at some point we were like, and we're still not recruiting a lot of interns. But we had some people who were looking for an internship or like doing better than the people who, when we were looking for a full-time person. And so we took them as interns because they were doing better at the homework than the others. And so the homework is basically the moment where we try to test the collaboration and the level of the person. And so it helps a lot, and this is like the moments where your years of experience don't count. So, yeah, I think the homework is a big part of it to prove that you have maturity and you understand what the tools that you use. And one advice I would give for that, and I don't know, maybe it's related to feel sorry, is that many times when we share a homework, it's many times about building something. But the whole goal, it's not just that you come and you have built your thing, it's about explaining why you make some specific technical decisions. And so many times when I do a homework presentation, we start asking questions about, like, why did you use this technology, and do you know how this works? And we realized that the person didn't prepare for all of this, they just thought that they would come and they would present the project that works and it would be enough, or finished. So I think it's important whenever you prepare your homework to get the thing done, but also try to anticipate the questions you will get and prepare to answer them about your technical choices or specific technologies, like what they are and what do they mean and what do they bring, so that you can also prove that you understand what you use and that even if you don't have the years of experience, you have the level of understanding of things.

Yeah, definitely. And then there is, as you said at the beginning, there is the impact. Like, you can have 10 years of experience in a company where you just did the thing without having a big impact, or anything in your job, that is not the same as working two years in a start-up where you grew a team, or you grew processes, or you grew anything like that. So I guess start-up peers, they can't maybe double.

No, but this is the thing, I guess when we talk about experience, and we had this discussion, I don't know, who did I have this discussion with? But experience is not about number of years, because in a start-up, it's more about problem solving. So can you solve the problems we have, or not? If you can because you kind of read about them, but you didn't really do them in practice, okay, we'll consider that, but we'll do some exercises to see like, okay, but can you learn that? If you did solve these kind of problems in the past, well that's good news, then you can help us solving this problem. Every time we're doing an interview, I'm more interested in the problems that you can solve instead of like how many years you've been there. Maybe I ask the question after the fact, like, with some of the solution engineers, like, okay, how many years? But it's more like curious, how many years did it take you to learn all of these? It's more the question, like okay, how many years did it take you? More than, okay, I value the time. It's more about like, okay, the problems that you need to help solve, you need it to solve.

Yeah, especially in startup, in this kind of role where you focus on something really small. So it's like solving one really specific type of problem. I guess it's definitely what you said, Sadek. I see that there are other question.

Yes. Maybe I can take Ludmila's one.

Yeah. If you were to starting your own business, what roles would be in between these two points so as to be a good entrepreneur? For me, definitely the gross engineer because that's really about... Yeah, once again, I know, I know. No, but like, honestly, this is the closest to... I know you're honest, I know you're honest, this is not the problem. It's the closest about building a business because you are basically doing the growth of the business, working on that growth part. And that's the most important skill, especially if you're a developer. You know, develop one of the big skills that developer are lacking when they're starting out a business. There's two I would say. First one is the business sense, like understanding the business, understanding how bringing value to a market and all this stuff. And that you can partner with someone for that. And then there's the growth, like how to grow from, as I said, like one user to 10 and then to 100, and then creating virality, creating demand and stuff like that. And that's the kind of thing that you learn as doing growth, especially as a growth engineer, because you're going to see like the basics of doing that, the technical side of doing that. So I would say that that's a great thing. That's also something that we are looking for when we are interviewing for these profiles is people who want to start a business in the future and that they know that they are lacking this kind of skills that makes a difference between a product and a successful product, I'd say.

Absolutely, Chris. I don't disagree with you. I don't disagree. But I think there's, you know, basically, if you look at the solution engineer, it's important because you will understand different problems of the closing of a contract. It's a very important thing, you know. It depends what the product that you are, you know. But if you want to build a product or a company that will deal with bigger companies, it's very important. You will understand so many things about the different processes of, you know, qualifying and making proof of concept and addressing problems, and you will learn about a lot of things about how to make a product. So it's a very important thing to learn. If you're looking into DevEx, well, if you're building a developer product, a product that is done for developers, DevEx is certainly a good thing because you will learn what features matter and what features don't matter. Sometimes you really fancy something and you really love it. You love it because of the, maybe the problem solving that you have inside of it. Or maybe you love it because there is something interesting about the solution. Or maybe it's due to something that, a need that you have but no one else is having. Maybe people are not exactly similar to you. That with DevEx you learn to listen.

That's a very good thing as well. Growth engineer is a very important thing. You learn about the business and how you can make impact. Basically have, okay, there's something that is not going well, well, the universe will not give you any gifts anyway. If you're starting a company, things will not work well. The thing is, you have this engineering mindset, this kind of problem solving. Okay, I need more people to sign up. How can I get more people to sign up? And then there's a problem and you need to find an engineering solution for it. I need more people to go from signing up to building something real with a product. Okay, you need to have an impact. The impact could be through the product. You improve the product. But it could be through a growth engineering or it could be through listening to people. If it's a developer product like DevExp and I would like to learn, how can I impact that, right? So everyone, and documentation. I know the person that we founded, built actually the initial proof of concept of Prismic with, he is so good. He's a very good developer and also very good at documenting things, documentation. And also he did a lot of, he answers questions, Q&As and all of that. And that what made him very good for doing a startup because he has that kind of feedback and implementation mechanism that allowed him to be extremely important for a startup like ours. So I don't think that there is one particular. I know why Francois is talking about the growth engineer because it's our focus at the moment. Okay, we understood it. But also is that it's, it allows you to learn a lot about business. And I feel- And to bootstrap stuff. Yeah, to bootstrap. And solve problems. It's not, it's okay as far as you're thinking about solution. It's okay not to have enough signups in the beginning. It's okay not to have, I mean not great. But you can work on it. It's not the universe. It's not like, I love this, and I used to have it so much. I don't know, maybe we were diverging into another topic, but I used to think like, okay, this is the best idea. This best product idea in the world. And I'm going to develop this and the moment I'm going to release it people will throw themselves at it. Like there will be so much adoption because this is the best idea ever happened on earth. Even if you got the best idea. You need a way to distribute it. You need a way to distribute it. People to understand it, to understand why they should use it. How can people hear about it? How can they test it? How can they, do they pay for it? Will they pay for it? Will they pay for what? Which budget goes from here? There's so many questions about the business that you would learn better if you are into maybe growth engineer. Because it's like very, like it touches on everything. You can have topics that are related to acquisition to making the product more known but also to making people like make money from the products, make people recommend it. So yeah, it's true that it touches on lots of things.

Speaking of which you have you have a question for you. I don't know. You can answer it Francois. NFUA. Which skill are important for growth engineer, soft and technical? I guess main one is being able to code. So the best thing is the full stack experience because the essence of growth engineering is doing a lot of technical stuff. Can be scripting, can be like publishing a landing page, doing CSS, HTML, JS. Building a server real quick, a Lambda or anything. So it's really about having a way to understand some experience in building stuff. Doesn't have to be the best engineered kind of code, doesn't have to have a lot of design partner and everything to have the best optimization. So this is not a SADEQ obviously. But yeah, like quickly build up something so that you start experimenting because you care more about experiments. Because when you have something that works, you can spend the time of engineering it well and have a good code, have good performances and everything. But the most important thing here is like, building stuff that you can put on the market quickly to test and see the results. So, coding skills are important. And then I guess, one of the most important thing in my opinion is knowing when to buy versus when to build. And that's something that a lot of developer like to do building stuff. And sometimes just for the sake of it, like, yeah, I'm going to rebuild this thing, like I'm going to rebuild the Stripe because I can do it and that will be fun. But the idea is to be super efficient, super quick. So, being able to understand when you need to build a solution because what's on the market, it's maybe not just turn enough or you cannot achieve exactly what you want. And sometimes you just need to buy because you're going to win a lot of time and you're going to be able to go on the market quickly, quicker, and then test and learn. So, that's a really important one and that's, especially for developer, I have a developer background, so I know what it is and a lot of my friend, they like to build stuff because they like to build and they are not thinking about technology as a mean, but more as a goal. And it's really important to see it as, just as a mean to achieve goals and not the other way.

Cool. So, I see we have maybe like 15 minutes left. Let's talk about growth engineers. I had a few topics, but I feel like I've seen a lot of people talk about salary negotiation on the recruitment process and I thought maybe this can be relevant to some people. I don't know if that interests you. Tell us on the chat. Also, or I was also planned on maybe talking a bit more about how to prepare technical interviews. So yeah, let us know what is the most interesting for you. I mean, if you don't tell us that you're interested by for instance, the package and the salary and how did that work, we're not going to talk about it. It's an important aspect. I mean, it was a joke. Let's give people some time. Yeah, let's give you some time. Yeah, Let's give people some time. Or if you have other topics that you'd like to talk about, we can talk about these ones.

Okay. One says benefits and salary, sounds great. I can say how I do? Go ahead. Interviews? Me personally, when I have interviews with people, it's one of the first questions they ask. And it's because I want to make sure that whenever we interview someone, it's something that I know we will be able to work out from the beginning, so that we don't lose the person's time. And so also for them, I know it's like a stressful topic to talk about. So it's good, I feel that this is sorted out early on. So I generally ask people what they expect. And I know it's a stressful moment. So sometimes when I see them being stressed and not knowing what they will answer, so I just tell them, okay, take the time to always think about something minimal. But it's, yeah, it's really just to make sure it's not really, it's not for, it's not to make you answer before us, it's really to make sure that we can reach that. I read that for some companies like large companies, I don't know like Microsoft, for instance, they have salary tables or grids. So it's not really something that you can negotiate. So this will be like also something that I think you can ask from the beginning because then they can right away tell you how much that would be. In startups, I don't know, like it may depends. I know in some startups, it's always like some kind of balance between sometimes stock and salary, you have also other benefits that you can negotiate, I don't know, you wanna get a gym, a lunch vouchers, 401K, or like retirement plans that are paid for all of these kinds of things. Learnings also if you want the company to invest in your formation, if you want to still learn stuff, courses, conferences, that stuff that the company can also cover. Yeah, and being able to work remotely I guess, today it's like allowed for everyone, but I know for some companies, they don't allow it, which like for instance, if you wanna go to conferences, it can be blocking because you will need to take holidays each time. So it's important, I think to do the list before you start actually. No, Sadeq doesn't agree with me. No, no. But it's good what you want I think, in the beginning. But I would like to maybe provide some kind of concrete knowledge. Okay, here's a question. I don't know if someone can answer it in here, but, is any of these roles, does any of these roles pay more than the others? Yeah, I think so. I think so, yeah. Which ones? I would say, solution engineer. This is the top one? Solution engineer? Yeah, I guess so, yeah, because it's close from business, right? It's about closing deals, it's about money. Yeah, I guess the idea is that it's easy to measure the outcome. Like if the solution engineer is there, you can count how many contracts did they close, how much money, and that's why you could say like, yeah, I could pay this much for that person, because it's easy to count, whereas someone like much farther from the revenue, it's hard to estimate, and that's why maybe it goes up. However, there is also competition, like I know that, the market, right? So, but all of this, pay as much or more than, being a backend or a frontend developer. That's my experience.

Like, if you are going for a frontend or backend typical job, these jobs, the ones that we talked about, they pay as much, at least as much, some, often more, because of the, how rare the applications are. Yeah, and the skills, because it's a mix of different skills. The skillset that's just harder to find on the market. So yeah, that's one of the reasons.

There is a quick question from Juan. It's hard as an applicant to say a number since we don't want to lose the opportunity yet and we don't want to leave the money on the table. How should we handle this? Very good question. That's hard. I think that like people I talk to many times, they say something like- Wait, wait, wait, yeah. Like you're saying your strategy. Now when you were hiring, everyone would know what I would do. How would you do? But I'm not like- It's a joke. They tell you, like, okay, this is what I have and, or this is what I would like to get. Now I'm interested. It's important for me to know more about your company, but yeah, just, and it gives you like a wrench. You don't need to give a number. You can give like, even like a big wrench, but a wrench is always, it just allows to be sure that we can make it. And it's important because imagine if you go into the last step of the process and then you realize you just like lost your time. So yeah, maybe a wrench. And then again, like it's not closing the door. It's just like saying this information and then it's the role of the person to deal with it. It's no longer you who will need to, like at the end of the process, feel like you need to accept the, sorry I touched the mic. You need to accept the opportunity because you already made them spend a lot of time with you or you already spent a lot of time with them. And also if you want to talk about practical stuff, there's a lot of salaries information on the web. You have Glassdoor today where you can have exact, the exact number of people on the same role in same companies. So it's really important to do your research on the market, on the job. So you have a good number in mind because in the end companies are going to pay what the market is paying. So that a lot, it's really important to go prepared to know exactly what that role in that market in that type of company is paid. Where can I find this knowledge? Glassdoor, LinkedIn, also has that. And then there's a lot in developer communities. I know that a lot of developers share their salaries. Also even on Twitter like six months ago there was a trend, a hashtag- Yeah, no one was sharing their salary. All the developers sharing their salaries and you can see also all the difference that exists in the market because in the end there's also negotiation skills in the end that have an impact in the salary, obviously. And that's something I guess that they want to... Yeah, I mean I like, I mean I have my own, I always had my own strategy in doing this and I don't know, many people will not agree with this but it has been my way of doing something. My dad told me when I, so I entered France, okay, and I didn't even speak the language. It was like a big hassle, right, for me. And I was like, okay, I'm going to work. And he told me, look, just forget the salary for now, just get something that you can make a living with. All right? And then, when you have experience, okay, and you will have knowledge. Like one year after of being, I don't know, in education team, you will have the knowledge, you will be in the role, you will have the experience in that kind of role. So, in the market, you have a bigger value because you did the job. It's not that you're jumping into a new thing. You did the job one year after. And you know also better about how much people pay for this role because you're inside the community, inside the role. You know friends, maybe, you know people, colleagues. So, you'll have that idea. You will be in a much better place to kind of talk about the money and bring it back. You will look at your value and you say like, look, I have value here and I see that the market does that, okay? If the company doesn't value your value, doesn't see the same value as you, it's not a problem. It's not a conflict, it's more like, okay, I think I have more value than what you're seeing and I see that there are other companies that will value it more, okay? But I see it more of a balance. I see it a lot like a balance. Like you would go into a company. If the company is teaching you stuff, okay? I was always into like, okay, I want to learn. I want to spend, I was young and I wanted to spend time to learn, and that was my priority goal. And I was like, I don't care, I want to get to do the job. And once I had the experience, it was easy for me. It was very easy. I mean I could go to any company and tell them, look, I'm available and they will take me. And that's a much better position. So I was never into negotiation upfront when I started, like a new category of title let's say. But I was more like, okay, let's be patient, let's spend a year and then do that. A lot of people will disagree with me because often inside the company, you don't get huge upgrades. And it always annoys me, this kind of thing, because I learned a lot in the company and they always told me like, yeah, but we can do more than, I don't know, 10%, 20% off of upgrade to on the salary because you know others, I don't know, strategy, policy, whatever. Well, I didn't care about the story. I said like, okay, I have a value, you're not paying for the value. I learned a lot and I think I want to try other opportunities and that's normal. It's not a conflict. It's a normal discussion that you can have.

It's not a conflict. It's a normal discussion that you can have. So that's my strategy, maybe not your strategy, maybe not someone's strategy in here, but I think if you're jumping into the role, like a solution engineer and you want to try it out, get something that you're comfortable with, your life should be comfortable. Don't put pressure on yourself.

So basically, maybe the one thing not to do is to kind of trying to negotiate hard, sorry, it's like not negotiating at all or not saying anything or like get a salary that will make you uncomfortable. You're learning a new job. You're learning a new responsibility. You need to be comfortable, at least comfortable in your life. Like if you're single, maybe that's not a lot of requirement. Maybe you have a family. Maybe you have things that are important for you in your life. Maybe you do, I don't know, some sports, some yoga, something that will cost you a lot. Maybe your hobby is important to you. All of these things make yourself some, like say, okay, this is how it will cost me to be comfortable in my life. And that's the right limit. Under that, it will be hard for me. Okay, you should not put yourself in a bad position. And once you do that, you go, you learn the job, and one year after you'll be in a much better position to get a bigger, a better package, I guess, I think. This is how I do it myself, or I did it.

There's a question from James, asking, is it okay to ask what is the budgeted salary for the role during the interview? I think it's okay. For someone like me, I feel like some people, when they ask me, I feel like they value their time and they want to make sure that we can make it before we go too much into details. Of course, it's not the first question they ask, but at the end of the interview, we had a good time, we kind of both feel that it's going to be a good fit. Then it's the moment where we can, you can ask the question and you can say it's clearly, it's because I like this opportunity and I want to make sure that it's going to work for both of us. And so the person will just answer you. It can be taken the wrong way if people think that you're here only for the money, but if you state it's clear that it's because I want to make sure that this will work, I think it's okay. It's a good question. It shows me, for me, when I see someone that says that, I see that someone is concrete. They want to be concrete on things. And I like transparency. I like people, I think you see that someone determined and they have a question. If you give it too much importance then it's like, okay, why it's so important? But if you go about it, what's the range of the salary or maybe people will not share it. There are different companies do different things, right? Yeah. Yeah. There's one asking if the interviewers have projects-

First, there is a comment from one. Yes. I completely agree, it's a very transparent way to go. I feel the same. At the end of the day, it's an agreement. Yeah, it's an agreement from your side and the company. You should always see it like this. This is how we should look at it. It's an agreement, we're on the same level, and then, you know, okay, what's good for me? I'm learning a lot, okay, I'm willing to make an effort on this for a year or two or a year or whatever, but whatever is good for you, and you say it and then you get into agreement. That's how I guess I feel to do it. Yeah. Like feel for yourself in the beginning, so like, I'm okay, I'm going to learn, that's somebody who's like, look, my value increased, right? Exactly what I was going to say, that's exactly how it work for me because I knew I had so much to learn, but I came in and I didn't want to ask for obviously the top of the range because I knew then even personally, as much as it would be nice to have all the money, like I wouldn't feel as comfortable about then trying to do the job and learning within that time because I think I would have questioned myself. That's the reason, right? Yeah, exactly, because when you start any job, you always have that imposter feeling, you know? Why am I here? Did I trick myself into getting this job? Yeah. And then if you have more pressure added on top, you kind of ask yourself that question for longer and then once I just exactly as you described that I was bringing value and bringing more value than what I was getting and then that's when the conversation started again. Yeah, like you get the conversation and say like, look, I think I'm in a bit in a different position now and we need to talk about this, and this is good. So I think you brought my attention to the fact that comfortable is in both ways. Comfortable as getting enough money to have a comfortable life, but comfortable as not to put too much pressure on you by negotiating a higher salary and then expectations are so much higher that you need to live that kind of thing that will make you not in a good position to learn, right? Look, I know I will go into learn that's why, but maybe make it clear, right? Make it clear in the interview, look, I think I have a lot of things to learn. That's why I'm going to accept this. I think it's below the market or like in the average of the market. But I'm willing to do that because I guess I'm going to learn a lot. And then when you learn, you can go back to it. It's like, now I learn, I have value and let's put the discussion back. I guess it's a good way to say it. So go ahead, you wanted to go to that question. Yeah, I just want to say, we're already two minutes late, so we're gonna answer the last two questions. And like, if you have others, we will take time to answer them Yeah, sorry for being late. I just wanted to add again, the link to the newsletter I think we're gonna just post the job openings there. Phil told me that they're also recruiting for the documentation team. So we'll make sure to send you an email whenever the job post is is ready. So we have a question from Milla is asking how do you know the salary package for a job? I mean, how do you know how much you can ask for a particular job? This also varies depending on the country as well. So as Francois said, I think it's a good idea to look online like you have lots of different resources. And whenever I checked, they are pretty relevant. So to the range that we see, depending on the country it's yeah, for sure, like salaries are very, they're very different depending on the country. A lot like for us, we leave it a lot for France because like in France you have lots of taxes, but lots of things that are provided by the state, which is very different from the US. So whenever we recruit in the US, it's like completely different salary range. But in the end for the company, it's more or less cost the same because you don't pay as much as many taxes. So I think you can ask, and what I do in general is that I try to get...

So basically when you ask, ask for different countries. Yeah, ask for your country. And something to know if you're working for a startup is that many times they would need to hire you as like a contractor. And so they would just give you some kind of budgets as hiring you as a contractor. So what do they know, like a daily rate or something like that. But then you can transfer or transform into a monthly salary. For remotes, right? For remotes, yes. So this will depend, but what I do is for people in countries where we have an office, I can give a salary, like full time. And then for other countries, I just give a budget on a daily rate that I can offer. And then the person can see if that's something that they could make work with all their expenses.

And Juan was asking, do interviewers have budgets? Should we always counter offer? Do you as an interviewer counter offer if the applicants goes too high? Yeah. So yeah, we have budgets. So whenever we open a new job, we try to look at what is the budget for this kind of role so that we make sure that if we recruit someone, we have the budget for it. So we do kind of the same as you. We look at like how much these people are paid. We look online and we try to ask people who do that job, how much, what is their package that we understand if we can recruit someone with that budget and then yeah, whenever someone makes you an offer, of course you can counter offer if that doesn't work with your personal expenses. No, I think you can do that. For some people when they say, honestly look, I have an offer and I like what you're doing. As long as you're honest, it's not too much about like trying to negotiate and it goes into that kind of route. It's good and it's honest and you have a counter, you can tell and story is important. Look, I really like the job here. I have an offer, I really what I would like to do looks like what for instance, Prismic is offering here. I really like it, but you know, there's the salary part and I feel that their salary is better. The company can also tell you no, but you know, this is what we can offer for this and you have to choose and then you have to choose. But if it's more about like, okay, trying hard to negotiate and all of that, it will sound like too much interest into that, I guess, but anyway, I think, would I say like no to an applicant if they negotiate hard? No, I will try to see, okay, is there a budget for this? Is it, are we willing to pay for that? There's some profiles which I would appreciate if they tell me they have a counter offer because it will allow me to respond to that because I want them so much because I feel that they can add a lot of value. There are some profiles where no, I don't feel that and you know and that's fine, I guess. Yeah, I think transparency is the most important thing. Like me, I really like when, once it happened to me, like someone ask me, I asked the person how much they would like in terms of salary and then they gave me an amount and they came back to me and saying that they actually the amount was too low and they realized that they need a little bit more. And I understand like if you went and you did your calculation and then you realize it's more, it's okay, like you can just be very transparent and we're trying to make this work. It's not my money personally, that I'm giving you so I can understand that you want more and if I want to I will try to get you that but also like you need to understand sometimes companies have budgets and as much as we want to, we cannot make it and we're going to be as sad as you are. So it's good. Yeah, exactly, like as we might be as disappointed as you are about the fact that it's not working. It's not like oh, you were the judges and we judged that this person doesn't worth it. It's rather like okay, we can make it, we can make it, you know? And we're not be, we will not be so happy about it anyway. Yes. Okay, so we're a seven minutes over time but we hope this was useful to all of you. I think that's it, that's like the topic that we wanted to discuss with you. I don't know, yeah, maybe I'm gonna to share my email. So if you have questions you can always reach out to us and then if you have questions for Francois, for Phil or for Sadek I will just write the email to the right person. So don't hesitate if you have any questions and yeah, we hope this was helpful. And by the way we have a talk right? Yes, we're doing a lightning talk and a panel discussion on the first day of the conference. So it's on the 14th, so it's next Wednesday. So see you there maybe. Yeah, and you'll get to know a bit more about Prismic as a product. Now that you know the people behind it. Anyway thanks a lot everybody. Thank you. Have a nice day or evening depending on where you are. Yep.