Finding the courage to stumble - El Medhi Rhindi

I guess, just as an intro, I'd love to know just more about you and what you're doing.

If we're talking about my job, I do front-end development for sure. So I've started actually as a C++ dev, doing Computer Vision. That was my first project, but it didn't click. It's not that I didn't like C++, but it was so difficult as a junior developer, and I was a solo developer on the projects. I had to do everything by myself. I didn't even knew what a compiler was.

But after two years of developer this, I was pretty much successful into delivering the project to the client, but at the same time, I started writing applications using JavaScript. So I used Electron actually to do some desktop apps and Ionic to do some mobile apps. And I just like the ecosystem, even though JavaScript is not the best language really. But I just like the ecosystem and how accessible it was. Contrary to C++, the community's there, but it was very difficult to get into it. And the language wasn't simple to understand, but JavaScript's community is very welcoming and whatever you want to do, you can find it. Either on a stock overflow or somewhere else. So that's what I liked about the JavaScript ecosystem. So I decided to go into front-end full time.

So I found a job on Angular. I didn't know Angular at the time. So I just tried to learn it. Learned it in pretty much a month, which was difficult. Yeah, it's a big framework. Even now after three years of doing Angulars, there are some more things to it. And lately I switched to React. I just found that there are more jobs and more paid if you do React than Angular. So I Just switched to it and as a matter of fact, it's a lighter framework. And I think I like it more than Angular. Anything like it.

What made the front end community more accessible to you?

Actually just the difference between looking for something when doing C++ and looking for something, when doing JavaScript, you can just find the answer pretty quickly. And if there is no answer, if you ask someone on forums, there is a lot of people willing to help. I wouldn't say that the C++ community is bad or anything like that.

Just not yeah,

Yeah, I think there're just fewer of them. That's why. They're much people willing to help because maybe they don't have time. They don't have as much time as that, because I think for them, it was a hard to learn it. So for now, as there aren't much C++ developers, you should do it by yourself to. Just go through documentation. And at the time I didn't even know what documentation was. I would totally be lost if I go into something as technical as that. So, yeah.

How did you find your first front end job?

So I did my, my final year as, like my internship in this company. And it's the company when I started doing C++. So I did some C++, I did some JavaScript and then after two years working with them, I was trying to find something else. So just received an offer. Actually, I didn't apply, just received an offer, which was about Angular. So I said, yes. I did the interview, and to my surprise, they just accepted me.

Oh, wow.

I got to position. I was surprised really.

A stroke of luck, yeah.

Yeah. I would say it's luck for sure. And yeah, something maybe I should tell you is I've been drawing for a long time, so I'm a big fan of drawing. So I draw a lot. I like art and I like design too. For example, in front end dev, I do like design. I do try to do my design by myself if I get the chance to do that. So, yeah. That's why I'm sticking to front end dev like UIs and user experience.

What's happened since you first took that first front end job? How have things developed since?

So been working with that company for almost a year. Learned lots of stuff. Was pretty much the first time I used Git, I didn't use Git before somehow, but it was a team. So from a solo developer, doing everything by myself, I went into a team and learned a lot of stuff with them actually. It was a pretty good environment too. So the company is called Amadeus. So they were developing this library with Angular and just liked it. After that I had to leave them actually, because of COVID. The position had to close. And from there, I started doing some freelance with React. And after that, it's [inaudible 000555] It went in discussion with a company called Enian and am now working with them for a trial period at first. And then if everything goes well, I'll stick with them for a couple of years, at least.

How did, when you were making that call to work at Enian. What were the first phases that you went through in your decision making? Were you talking to any other companies? Was it just Enian?

I was talking to some other companies. The first thing I would want to do is find a remote job. I've been trying to find a remote job for a long time and somehow it wasn't possible, but now there are more remote jobs to seek. So first thing I asked is this position remote? And it was, yes. So I was pretty excited about that. And really with the same fashion I did the first contact with the CEO, went well, we talked about energy and,

You first contact was with the CEO?

Yes.

Okay. So small company.

It's a small company. Yes. The product is there. It is a small company though. I think they have more people working on the research parts of the product. But the team working on the product itself, like the front end is pretty small for now. I think we're five developers in total. Projected to grow a lot in 2022. But yeah, first contact was with the CEO.

What type of things were you looking out for during that interview? And how were you figuring out those things?

I mainly go to trying to find out if the team is a good team. And by that, I mean, that most important thing for me is if they are helpful. Like if I have a question, I should be able to ask the question and have a quick answer, like quickly. And that will enable me to go through my work and not get blocked for a long time. And that is pretty much the most important thing I look for when looking for someone to work with.

What things do you look out for to avoid?

Bad pays, for sure. I've had some bad offers like way below market. This is to avoid. And recruiters who try to recruit for clients. And they have no idea what they're talking about. For example, I went through some recruiters and one of them told me that they're trying to find a next JS developer. So I said, yes, I do React so yeah, we can talk. And it was like, no, I need next JS, exactly. And I tell him that, I mean, it's the React framework. If you know React, it's pretty much the same as next JS or Gatsby, for example. And they were like, no, we need a React developer... We need a next JS developer and it should be a five years experience. Knowing that next JS is five years old. I think it's pretty hard to find someone with a five years experience in next JS.

Yeah.

And paying below market, again. Mainly those I try to avoid. But most of my experience went well so far. Even if I didn't get the job at the end, it was a good experience overall.

How did you weigh up your decision to join Enian?

So, first of all, they had a good solution for a good problem, actually. So product is a project management software, but especially made for energy. The CEO actually has so much experience in the domain of energy, so actually knows that it takes so much time because it's not organized. And if you try to make softwares organized the way it should be now it's going to be taking way less time to do it. So, yeah, that's the vision for me.

It made sense because I know that I've done some studies actually on energy and renewables. And I know that this tends to take so, so much time because it's, first of all, it's new. No one has that much experience on the subject. And if you have software that gives you all the tools to do so, you're going to go much faster than usual through this project. And second of it was because it's remote. And actually one of the developers, or not the developer, the VP for engineers, actually, was a level three Amazon developer before. So I think working with him will give me much needed knowledge about the job.

Been through the problem, been through the remotes. I've been through the money. I'm interested to know how you made a decision about who you wanted to work with. Sounds like he is someone who you instantly respected during the interview process. But I wonder how, how you built that relationship before you made that decision.

How we built relationship. That's that's a hard question actually. Because you don't have much time to [crosstalk 001214] You don't have much time. I just met with him like maybe two times, one in, yeah. I say one during the interview. We didn't have just the technical interview, just chit chatted a lot about different subjects and what I did before and what I tried to do, what I want to learn and stuff like that. And one afterward when he made the offer and he said like, we want to work with you. And seriously, I wouldn't have a systematic way of going through this. For sure, I liked the guy. He was very reassuring. And when he gave me the offer, it was like, I took maybe a week to think to it. And I said, yes, afterward. Basically it's by feeling. There's no systematic way of going through something like this. As I said, you don't have much time to know the people themselves, but at the same time, if you work with them and it's not a good environment. You can always walk.

Sounds like you needed access to certain bits of data. Like the salary, like whether it was a remote working. But at the point at which it became a relationship or a mission, the things that are untangible in some way, it was hard to make that decision with data. And you were only able to make that decision with your gut somehow.

I mean, for sure. Just like you said, if it comes to knowing the person before making the decision, you don't have much data about that. And yeah. Salary and condition of work is pretty easy to base your decision upon those. At least you have a baseline for these. And I think if you have an opportunity, maybe you should always, at least say yes, go through it, work with them, see how it really is, and then decide afterward. That's what I would pretty much do all the time if there are no red flags, for sure. But yeah, you need time to work with the people and then you can decide what to do.

How do you do that during an interview process? So tricky. So I guess a lot of the time you don't get the opportunity to work with someone before you end up saying, yeah, okay, we'll work together for years.

I mean, I don't know. I mean, during interviews, doesn't people talk during interviews. I mean, we talk, I talked about my origin, for example, I am from Morocco. I do live in France. I like to... I do some 3D model. I like to draw like artistic stuff and things like that. And I even told him that I don't like to go through work and crunch. Like he should know that for sure. I don't like crunching at all. I don't like having lots of... Not because I can't handle stress. I can handle stress. I just don't want to be stressed. That's something everybody should know if I'm working with them. Like if you have some urgent stuff, I'm totally up for it, but I'll for example, do it and take the day.

So we talked about that. We talked about, about him, what he did before, what he does now, why he quit his job for Enian, for example, in our case. And maybe even what he thinks about the product. Is it good, like the stack, the technical stack is it a good stack to work with? How about the developer experience?It's even both of us interviewing both of us, actually, not just him interviewing me or just me interviewing him for sure. So I think we talked for some time before even starting the technical questions. So after that interview, I was pretty much sure to have much of the information needed for me to take a decision. But I don't know. Does everybody do this or is it just me or?

I think perhaps if you have a shorter period of time to build that relationship, it relies on the quality of your questions and how fast you can break into the truth. And it sounds like you are able to get to the heart of what that working relationship might look like. Because the quality of some of those questions is so deep. And I wonder how you figure out what questions to ask in that scenario.

Like for sure, I've seen lots of videos on YouTube about bad interviews and red flags about interviews and how you should always ask questions and clarify what you want to do as an employee. If you're getting the job. And most of them are about, if you want to have a good relationship with your employer, you should always start with telling them what you actually like to do. And if it doesn't click it, doesn't. It's better to be honest and not miserable. Cause if you start working with them and it's not what you want. Like for sure you're going to quit and it's not worth it to go through maybe a month of stressful work and then you just quit afterward and it's not worth it. So yeah, that's what I try to do at first. Just try to be as honest as possible. What I like to do and what I don't like to do, go through some questions. Some of them are a bit tricky to get to, but you have to, but you have to ask them for sure.

There's a barrier to that, which is knowing what you want to do and what type of work is right for you in the first place. And it sounds like you figured that out.

You would say, yes. It's just lately that I figured this out. It's after actually my job as freelancer was working with React and I discovered all the ecosystem about React, and how you can go from design to final product with some specific tools. And I just liked working with them. So there is the stack or the technology I like to work with, and there is the specific parts of the job I like to do.

That's interesting. From the start of the conversation to now, it makes so much sense that you've gone from being a C++ developer to a front end developer.

Okay.

It's such a transition because it makes, as you explain it, so much sense because it sounds like it's a meeting of your interests.

Yes, exactly.

And your work.

So yeah, at first, you don't know what you want to do, but then you start to discover it. You stumble through tools, you stumble through technologies and then you choose the one you like and the one you don't like. You still need some bit of courage actually to make the switch. Like for example, maybe you've been doing embedded system development for five years, and then you figured out you like something else. So you still need some bit of courage to switch. And even though you're going to meet like recruiters that are going to try to recruit you in your old job or your old technology. So you need to be resilient too and tell them, no, I don't want to do this anymore. I want to switch.

Because even for me, I've received lots of offers on C++, and for example, Qt. And I just tell them yes. Even at the start, actually my background is a network engineer. I'm not a front end developer. I'm not a developer... I don't have a degree in programming or computer science. I have a degree in engineering and networking and telecommunications, and I've received offers in this domain. And I just say, yes, I don't, no, I don't want to do this. I want to do dev development. I want to code and little by little, you find what you actually like. And just lately, now I'm trying to make it design and front end dev. So user interface or user experience too, maybe, not for now, but maybe afterward and front end developer too.

Where do you find the courage to keep stumbling? As on that journey?

I don't know. Really. I don't have an answer for this. Maybe it's because I just like learning new things, for sure. If there is a new code technology, I want to know all about it. And then I decide if I keep it or not. That is a thing that I always done, actually. It's not just now, but maybe it's a good thing to have. And not to be afraid of learning new things.

Curiosity, not courage.