Today Adi, one of our hosts and the hiring manager at Elixir, talks about the intricacies of applying for a job, and what companies to search out.  We talk about the expectations for the applicant, and how to prepare.  We also talk about what you can look for the employer to provide before spending too much of your time in the interview process.  Walking through various interview processes, we learn what things can help you land the job you want.

Companies that are hiring Elixir positions (google or reach out to Adi):

If you need help looking for Elixir jobs, reach out to Adi for help: aditya7iyengar@gmail.com

Hello and welcome to another episode of Elixir Mix. I am hosting today with Adi Iyengar. Adi, welcome.

 

Hello, hello.

 

So Adi brought up a very interesting topic. He is basically the hiring guy on Elixir. So if you need a Java Elixir, go out and find Adi. He seems to know who's hiring all the time. Adi, you wanted to talk more about, yeah, about the hiring process, right?

 

Yeah, specifically like the interview preparation. Last few weeks I've been helping out quite a few people, some friends and some people who are destructing the podcast and other platforms. And it seems like a lot of things that might be obvious to Alan, you and me and some other sort of more experience with the job hunt wasn't as obvious to others. And also the job market has changed quite a bit and that's, you know. even last a year and a half, you know? So, yeah, I want to talk through the intricacies of applying, especially if you're looking at the LICSR area and what things to consider. If you're in a place where you have to be at a 16th and they're built, and you are looking to change jobs, what can you prepare before you start interviewing? Like, what to expect? And also, what kind of companies do I apply to, right? Yeah.

 

I think the expectations on applicants have also changed quite a bit too. I think before it's like, well, if you have interest in learning, we'll accept you. But I think now people are starting to change where it's like, well, interest, but also you need some, I think maybe the lowest level would be you need to at least crack open a book and have gone through the whole thing. Right? I don't know if they're actually looking for a production experience or not.

 

Yeah, I mean, yeah, yeah, you're right. You're right. My wife just transitioned to being a software engineer within a month. She was a dental hygienist, hadn't heard a lot of code before that. Did a quarter of a boot camp, and she got a pretty good job. And now she, it's been like a year now since she's been coding, and she makes more than what I made after four years of coding. So. Yeah, definitely it's more accessible and there's like more companies, especially like in the startup, you know, low, you know, less tech heavy startups, right. That choose like languages like Ruby on Rails and Elixir, you know, because they're more productive. Like those kind of companies tend to, you know, give people a chance, not even without Elixir experience, but without any coding experience period.

 

Yeah, I mean, I guess it depends on the company too, right? So like, I mean, the thing is, I found that some people have what, I just remember like Dilbert, remember the Dilbert cartoon a while back? No?

 

Nope.

 

Okay. So there was an episode called the Nack where it's like, um, you know, how the expression, like if you have a Nack for something. So it's like some people, they have like a natural ability to program, but I found that it's basically like STEM people, like people who are really into science, physics, math, they have the ability to reason. So high logic and like they can easily start coding. But yeah, there's very few people I think that can code like out of the box, or I'm gonna say out of the box, it sounds a little bit weird. Maybe out of the gate, I guess I can say the word.

 

Yeah, very few.

 

Yeah, but even if you learn, right, just depends on you. Some people have to struggle harder. But

 

Totally.

 

yeah, I was accepting people who have never coded before but have an interest. At the time, it was the right thing to do because it was hard to find decent people. Now I can be a little more selective because I've learned my lesson that sometimes some beginners are just too beginner, right? The other thing I found too is, and I... brought this up a couple times in previous episodes is that elixir is not easy. Like now I'm not talking about OTP, that's like forget about OTP, like immutable data, all of this kind of stuff. If you start off doing JavaScript or Java where you have like mutability as a huge part of it, it's so difficult to change somebody's mindset. And some people are so wrapped up in a specific language that they can never branch out.

 

Yeah, totally. Totally. I mean, Elixir. Yeah, I have subscribed to the notion that it's an easy language to kind of like, you know, start doing simple stuff in. But as you complicate things, like, yeah, functional programming can get really hard. Like, yeah, one day I was trying to do one of the binary tree algorithms in Elixir. I was in a hard time. I've been doing Elixir for like, seven years now, you know, almost. And I was having a hard time doing them in Luxr. I mean, it was a tough problem granted, but like doing something, you know, with a combination of reduce and maps, right, is a lot harder because yeah, the state, the scope as well. You're not able to access variables that's out of scope, edit variables within a scope, you know. Those things start getting really hard with a Luxr.

 

Also, like a lot of concepts don't really transfer over. So one of my employees is actually rewriting a Python functions over to Elixir. And one of the functions that we have is a while loop. And he's like, well, how do I transfer a while loop over? It's like, well, there's no kind of looping. And it's like a while true thing. So it's like basically you keep trying to hit this API and after five times, then it doesn't work.

 

Right.

 

So it's like, well, I also had to think for a moment, I'm like, how would I do that?

 

Recursion.

 

Yeah, recursion. Yeah. So, or I told him to try actually the first thing that came to my mind was like there's like an enum reduce while I think that one is

 

Yeah.

 

also could work because you can stop reducing.

 

Right.

 

So that's one way, or yeah, or recursion. But I think recursion is a little bit hard to explain to somebody who's not really used to it. Because he's got much more experience in Python. So it's like, well, you know, recursion in most other languages, they don't have the, what do you call that? The tail, no, I mean the tail recursion. The multifunc, yeah, is one thing. But I think the tail recursion, it's like, well, I don't

 

it's

 

wanna

 

called

 

do

 

my

 

recursion

 

vision

 

because I can, I can have a stack overflow, right?

 

right right right and you can have done with it right it's just like crash

 

Yeah, it's possible.

 

but but but yeah uh... it yeah i i i think the that's the need to go to the access to the political it's a multi-class function right that's like it all while true into a while through the couple of other one with through and one with

 

Yeah, that's the thing. But, um, sorry, I think we're getting sidetracked with stuff.

 

Ha

 

Um,

 

ha.

 

but, but yeah, yeah. So, so yeah, like, like we said, uh, my, again, also my interpretation is, I just want to kind of go back to the same thing before, right? It's no longer that you have an interest. Now it's like, what is the, the, the minimum that you would say right now? Like if you wanted to get a lecture job that you would say you need, like, is it that you just need to actually have gone through at least one book or like, how would you kind of measure that?

 

That's a great question. It really varies. There's, over the last few weeks, I've seen companies that are okay with zero elixir experience, but like a proven record of you having interest. Like I said, my wife got an elixir job a couple of weeks ago, and she had turned it down because her company really outmatched that. But... She basically just showed them an Elixir app she wrote. The interview had no coding. She just talked through it. It was a very simple site project. Live View was probably never be able to run in production, not optimized at all. But the fact that she has this mentorship group that she goes to every Thursday, that's for Elixir. And the fact that she's been, you know, she has a way to prove that she's interested in Elixir. And as a year of real experience, which is somewhat close, right? Was enough for her to get a, I think pretty good job. Like it was a pretty good salary, I think, more than most, what most engineers would make at this point. So yeah, but on the other side, I have the best engineer I know. I think he's literally the best engineer I know. His name is Eric Chilvan. He's been on the podcast once. He started his own company and came and talked about that. But he... I think he joined, ended up joining Pepsi finally, and I think he was asked some pretty hard questions in some of his interviews, like weird, or like types, which I don't know about either. You know, like how are certain types implemented in the underneath the surface and stuff like that. And I was very surprised, you know? And the difference in salaries weren't much. It wasn't like, you know, maybe like 30, 40% difference, you know? And that was, that's what was surprising to me, you know, like it really depends on the company. If a company is at a place where they're hiring very, very early season engineers, they'd probably go for senior engineers, right? Or more experienced. But if a company's at a place where engineering is relatively stable, they're still start upy, still okay to take a risk, you know, upon kind of junior engineer. Also want to diversify more senior engineers, you know, are craving mentorship opportunities. Those kinds of companies that might be okay bringing in someone with. a lot of interest and potential if they do want.

 

That's interesting about the people wanting to know the types and stuff. I guess it depends on what they're looking for. I've had just a generic interview, I think I've talked about in the past where like the guy wasn't academic and he's like, you don't know what is a, I don't remember like, because like, you know, you and I are used to, I think most people are always used to like arrays or lists, integers, floats, et cetera, like these kinds of types, but he was like, you don't know about, and then like, apparently there's like a whole nother set of types. that you would know if you're like a compiler creator or like something like that. It's like, you know, like, like map trees and, and, and like this stuff that actually runs a hash table or whatever, like he was like, you don't know these things. I'm like, this job is for writing like, like a, like a backend for APIs. Like is this is not academic stuff. So like

 

Great.

 

the only way I actually, the funny thing is I, I, the only way I made him like me is that when I went back to him and I was like, you don't know what a WebSocket is, do you? Oh, you don't? What are you an amateur? And then like, I started fighting with a guy and then like, I got respect. So like,

 

Wow.

 

maybe, yeah, it's kind of weird but I think that's actually how academic works is like, they need like this debate and depending upon that kind of person, sometimes the debate has to be heated. And then so like they need, you know, you just kind of stand your ground a little bit. So yeah, like I said, it depends on the company. That was the first time I've ever had a situation where they asked me stuff and I had no idea. Because, yeah, I'm just not exposed to it. And that, I think, interview is a good example of not a good interview from the interviewer's side because they had expectations that

 

Right.

 

were not realistic to the position that they were hiring for. Which I think is what you said your wife went through, right? It's like, whoa. I guess it depends on your interest, right? But do you really need to know that kind of detail? I don't know. It depends on, like you need to know a list is actually like a single link list because that's super important. But like how that thing is implemented, like down to like the C code I think is maybe too much unless you're doing some high performance stuff.

 

Yeah, I mean, I don't even know if most Alexa jobs you need to know it's a singly linked list either, you know. I think that's the world we live in right now. The software engineering, majority of software engineering interviews aren't really qualifying persons for the jobs that we're doing. It is just finding, it might seem arbitrary to us, but I think it's like basically gauging someone's problem solving ability as a side. as like an added bonus, but primarily it's like filter candidates, you know? Like give them something hard, let's find someone who is good at something, you know? It feels very, that part feels more arbitrary. Like I mean, you said that's one interview you had no clue. I have, when my first job I was looking for, I had a three hour long interview at Google, they asked me to implement basically what it was like a a traveling salesman algorithm modified for when the nodes are moving, certain set of nodes are moving. They asked me to implement that real time. I was obviously couldn't do it. And they actually said then they were expecting an answer. They don't expect just they were not just seeing that looking at my thought process, which is what I thought there would be. I thought it would be unreasonable for them to expect it. Like, no, we actually expected an answer. We've had a couple who gave us an answer. Like, I don't know who you're hiring, who you're looking for, but yeah. So I think that's the world we live in. A lot of these companies ask these kind of questions, which is. Yeah. It's, it's, it's sad.

 

Yeah, but again, it depends on the position you're hiring for, right? I mean, and also like what are you kind of like a good question is. Yeah, I guess what is the position you're hiring for and then what's realistic based on the market too, right? Because no matter what you have to train people up and every product is going to be different.

 

Right.

 

Everybody's got different coding styles and different preferences, et cetera. And also the other thing too, to think about also, it's like, well, how do you say this? Um... What you think is good for one project may not fit for another pending the domain and the people around you. I think we remember we had an episode in the past about like, hey, if your team is already proficient in tech or language X, choosing Elixir may not make sense because of that reason. So maybe it's kind of a similar thing.

 

Yeah, yeah, definitely. I think it's definitely perception, comfort, how things are already structured. Yeah, it has a huge, huge effect. I think one of the reasons why I've been, I'm seeing a lot of these interviews lately with my circle is that all these companies that they're interviewing at are bigger, more established companies, right? Whereas the same circle of people, most of them would apply to like more startups, right? And yeah, those kind of companies do have a set process, set expectations, and maybe they're also companies that need to focus more on data structure and algorithms, even though they are using Elixir or Ruby, where it really doesn't matter. You know? But yeah, maybe it's part of the culture there. Actually, that's a good segue to another point I really really bring, which is, again, it's obvious to me, but I think in this market, if... people listening, if you're looking for a job change, definitely prefer a non-startup, right? Offers are being rescinded. People are getting laid off a week, two weeks after they're joining. Yeah, I mean, even the best of the companies are laying, startups are laying people off. So if you are looking for changing a job, definitely go for a bigger company. There is absolutely no harm in... and applying to a startup and thinking of them as a backup. I have been hiring for five companies now, and every company without exception had backup candidates. Oh, let's keep this person. And I like this guy, we'll give him an offer after we interview this guy, right? Companies can have backups, you can have companies with backups too. Like there's no harm in applying to a company that you're like, ah, let's fall back. if I don't get a job at these companies, let me just have their offer and get a two week response time. And you can say, I have my family, I have stuff going on, give me two weeks. Two weeks is a reasonable thing to ask. Generally these startups, they're getting smart and they say, hey, respond within three or four days. They say three or four days too quick, can I get two weeks? Trust me, you can ask that. I haven't had it till now where a startup has come back and said that's too long. Two weeks is very reasonable. Ask for two weeks and try to get a job at a better company and have hierarchy, man. Have hierarchy. Every time I've been in the job process, I've had two or three backup offers. And it's good to have that. Not enough candidates are doing that. That's why it feels like a company to have a higher upper hand in this job hiring process.

 

Yeah, this is tricky. This is kind of a side question based on your understanding. Do you feel that it's a, I want to say buyer's market, but is it a candidate market or is it an employer market?

 

That's a tough one, right? If you are experienced, and kind of what you said earlier, Alan, like you kind of imply if you're experienced, it is a candidate market. If you are new, or like I would say if you have less than three, four years of experience, it is still the bias market, the company's market, right? So yeah, it's tricky. Good thing about Elixir is it's a good thing. If every recruiter I talk to, the supply is still a lot less in demand, right? So if you are doing elixir, if you have experience, knowledge, interest in elixir, keep building that, you will end up getting a job. I tell these two, some other mentees who are looking for jobs, you apply for 20 elixir positions. If you do things right, likely you'll get at least one, right? one job. Again, it might sound a lot, but job process is a lot more than your skills. It's about timing. It's about a company feeling, oh, we thought we could hire this person, but we can't. There's so many variables that go into it. That's why I said you apply 20 companies, even if you are a good engineer. But if you apply 20 Alexa jobs, you should get one. Yeah.

 

If the demand is really high and supply is low, it seems hard for me to understand why is it that you shouldn't

 

Right.

 

get say at least half, right? Are you saying that like, Alexa developers, how do you say that, their soft skills are not good enough? Because that's the thing, you and I have both met people where it's like, this guy is excellent technically, but he cannot socially fit in here.

 

or maybe imposter syndrome. They just can't sell themselves. People don't like talking about themselves.

 

Yeah.

 

I think that's, yeah, few of the best engineers I know have that and they have a hard time selling themselves because of that. But yeah, I think it's also, I think, be safe, it's so easy to apply to jobs. People who actually know how this works, they applied a lot of jobs, right? And that's why companies get a false sense, oh, we have 25 candidates, but they don't think that. 25 candidates who also applied to 25 jobs, right? So I think it's that cycle, you know, where smart candidates who apply to hundreds of jobs, they do take up, you know, that place in the queue of candidates that the companies have, which slows down the process. And, you know, if a month or two has passed and you're applying. things kind of like, you know, refresh, a lot of things change. So, but yeah, I think that's a big, big factor as well. The competition is there even though the demand is high in supply, but it still feels like you're competing with other people who might, might as well end up taking some of the jobs, you know.

 

Yeah, true. Okay, actually, kind of going back to my first question, did we actually, yeah, we didn't actually really address it about like, what do you think that, you know, like, if I want to get a job in an elixir, kind of like what kind of how much soft skill or not soft skill, how much hard skill should I know? Right.

 

It looks like coding skill. Oh, I think that one dropped out.

 

or continue on I don't know I must have tapped something

 

So yeah, hard skills of initial, let's say coding, right?

 

Yeah, I mean, I guess like, um, I don't even know what's a good way to measure it. Like maybe I want to leave that part open, but of course, one way for me to measure is like, do I need to know everything about OTP or, you know, I don't know how to even say it.

 

Yeah, I haven't had people ask a lot of OTP questions, unless they're applying to a company that heavily uses it, which is a good sign, right? Like, unless they're applying to, I don't know, a community that uses a lot of OTP, or what's the, I forget, where they're adopting, it looks like the guy's working, but, you know, unless they're using it very heavily, they don't ask that. It's generally, the extent of OTP people ask is like, Do you know how a gen server works? Like, can you like, you know, build a very small gen server, client server separation, and know how to test it, right? Pretty simple. The simplest one that was asked was, write a gen server that its job is to pull data from a weather API and store it somewhere. Yeah, I think they ended up storing it in a file. So. That's a pretty simple GEN server. Nothing crazy about OTP supervision trees. Yeah, nothing crazy. But yeah, I think one good thing about Elixir is that you won't have a lot of algorithmic questions. You're not gonna have a binary tree question for an Elixir job position. It's very, it just doesn't go, those two things don't go well, right? Like if you're in a place where complexity matters so much, you'll probably end up getting lost to something very low level. right, anyway, or C or something like that. So elixir positions, I don't think it's gonna matter much, the complexity and data structures. They generally will ask an API call question, right? Like you can mention the weather API. Maybe like string manipulation questions are pretty hard. Right? It's good string and integer manipulation. One that was asked was, given an integer, get the next palindrome. integer, next largest hand-run integer. Pretty simple, did it in Lixfer, so stuff like that.

 

I don't even know what that word even means, palindrome integer. I hate these kinds of questions.

 

So the palindrome again, if you reverse it, it's the same, right? So as in, so like if I give you 100, the answer should be 101. The next largest palindrome, if I give you 101, it'll be 111, right?

 

Okay, that's not too difficult, but... Okay, Palinjo, yeah, we flip it around. Okay.

 

Questions like that, like string manipulation, basic and visual manipulation, nothing like, you know, where complexity and analysis matters, space or time. So that's like one advantage you have with the LixR. Questions will be like more doable, at least, you know, with like a normal mind without having a computer science degree and like without having a lot of algorithmic background. Yeah, so as far as hard skills go, just do exorcisms, do your... Don't worry about those lead code problems for elixir jobs. Do exisms and code wars and basic elixir stuff. And just keep writing. Have a couple side projects to show that you're proud of. Add tests to that. Try to maintain that. Try to deploy them. Have a couple projects if you're always as handy that you can talk about. Have a story ready. Why you built that project. What two or three problems you ran into that project. How you solved those. What was the research process to solve those? all that, what was the thought process to solve this problem? Like have some monitoring, logging in your side projects. Just work on those side projects, keep the exorcism so you're ready for short questions. Take a different frame of mind to do interview questions than actually code. So just keep doing exorcism so you're in that frame of mind. But yeah, as long as you do these things, you should be good. And like I said, if you apply 20 jobs, you interview at five, you should be able to get one.

 

Um, actually here's a kind of a good question, right? So if you got these side projects, let's just say like, you're not doing freelancing, but you're just kind of just doing projects to kind of keep your skills up. How do we say this? Um, The tricky part is, what if you're doing those projects, but you're doing a bad job of them because you don't have the proper guidance, right? I don't know, do you have any kind of feedback on that? I mean, have you ever

 

that

 

gotten

 

one.

 

where it's like, yeah, somebody gave you the stuff and you're like, wow, this is just not idiomatic elixir.

 

It happened to me, but I think that's where I think having a mentor is important. Having someone to guide you is important. And there's not a lack of mentors in the Elixir community. Just reach out to people who do Elixir. Reach out to Alan. Reach out to me. People are very open to help. And like, you know, just, I love looking at code. So like, if you have any code you want to be validated, shoot that my way. And I can give you suggestions. But. It's important to look at open source projects when it comes to that, right? If you do work, if you want to evaluate what you're doing is good or not. Like look at awesome elixir as a repo on GitHub. They have a bunch of examples, packages, and even open source apps of how to do what, right? Uh, I have a lot of open source projects. I have like at least 25 elixir projects, like I try to write hundreds of tests for all my apps. So. I look through other people's open source code and compare it and learn from that, right? That's also a good place.

 

Let's not get into the whole test coverage situation again, right? That's a long discussion, but I also do try to strive for that 100% too, except for, you know, I have to ignore a lot of files because of like, you get all those extra files generated and some files you don't really need to test.

 

That's the way to go. That's the way to go.

 

Yeah. Yeah, I mean, I think, yeah, there's, there's, uh, it's interesting to hear about what's kind of changed, right? It's, it's good to hear that, like, now there's more expectations on the candidate side because it's, um, yeah, that's something that's there. And, um, but I think that if the candidate is applying for, for, for the position because they want to do elixir in my opinion, and I think, well, I haven't. had that situation here because the market in Hong Kong is so small. I would think that if they are interested to do Elixir, they're going to be a better candidate than somebody who's just interested to get a job. Well, that's obvious, but like, how do I say this? If they're applying to a company because of Elixir, they're going to be a better Elixir developer because they're just that much more interested.

 

Yeah, for sure. The person we hired as our second engineer in my company did not have an experience. I don't think he even particularly had elixir, as much elixir interest. I think he just had interest to work with me. And when I told him about elixir, that interest amplified. He's a brilliant engineer now. He only has a total of like a less than two years of experience and he's pretty good. Yeah, there's definitely truth to what you're saying But but it's there are there are lesser companies than if they were two years ago who are willing to hire people who are in that category But if you find one, I mean like it's a big factor. It's something good. I don't know Alan if you agree I think like it's the biggest factor in job search timing luck and Yeah It's pretty hilarious again. My wife. We were just talking about the fact that she has this She's barely coded in Elixir. She's coded like a total of 15 hours in Elixir all her life. And she got a pretty awesome Elixir job offer with 130 plus K a year, barely doing nothing. Her timing of applying was right. And her interviews kind of suited her. There's no behavioral explaining code. Life coding is where she gets flustered. So I think luck is the biggest factor in. job search. So yeah, the more opportunities you apply to, more opportunities you create for yourself, that's how you minimize the luck factor for you. Right. So that's the only thing you have in your hands. And prepare, like I said, with Elixir, it's pretty straightforward. No algorithms, no BS, do accessisms, and keep maintaining one of those high projects. Right. You should get a job in Elixir. Still, demand is pretty high, supply is really low. And there's so many companies hiring, you know. And then when we do takes, I'll list a few and hopefully they'll be in the show as well.

 

Well, I think another big thing too is like, to be honest, I think the most surprising part about any job is that they have to like you, right? And they have to be able to communicate with you.

 

Oh, that's all right.

 

Like I mentioned, what I mean like I mentioned before, like it doesn't matter how good that developer is technically, if you cannot communicate, if you cannot... If you come off as a weirdo, sorry to say it directly, but I was actually interviewing somebody recently, and like, First of all, the guy's name is LeBron James. He had a very thick accent. I think he's from Korea, but he says his real name is LeBron James, so I have a hard time to believe that. I just gave him the benefit of the idea. I was like, okay, this is weird, but maybe just, maybe he got his name legally changed. I don't know. I'm not going to worry too much about that. But I was just asking him simple questions, and then like he would just, he just like ended the call. And he was like, hey, the connection's not good. Just send me a test and I'll pass it and then we can get started. It's like, no.

 

What?

 

Like, you

 

Wow.

 

don't understand. Like this position is like, you need to work with the client and they're gonna be talking to you about what they need. So if we can't even like have a simple discussion, no matter how good you are technically, I cannot risk working with you. It's too high cost as an employer, right? Like you've been an employer, so it's like. It's a really high cost when you bring on the wrong person, right?

 

Oh yeah, yeah, it's crazy. Yeah, yeah, that is so right. Don't come across as weird. And I know I think a lot of times, you know, you might be introverted, you might not be used to talking to people. You might, you know, be the beginning of an interview stage. I told this to one of my friends actually, a couple months ago when he was looking for a job, practice in front of the mirror before the interview, practice your answers, right? Like... A lot of engineers are used to being socially more introverted, which kind of catalyzes us being more socially awkward a lot of times. So take the opportunity to practice speaking. That's so right. I'm glad you mentioned that. Yeah, just practice in front of the mirror. Hear yourself. Get your spouse or significant other and practice with them. It's, yeah. Yeah, I've had my share of awkward interviewees who had a lot of potential, unfortunately.

 

Actually, the other thing too, I think it's good that we kind of talk about stuff from the employer side because you need to also have that mindset. There is a lot of this kind of like, okay, here's what I'm looking for and then how much do you match? And then again, it's like you said, am I willing to accept this candidate? Because there's no such thing as a perfect candidate. It happens. As an employer side, I'm sure you've met people like that. And at the same time, it's like... But you know, you and I are both married, right? So when you're dating, right? And you find somebody that perfectly fits what you want and you're like, okay, holding the excitement, you know, just play it cool, you know? But sometimes you get those kinds of candidates, you know, like, okay, I gotta like, you know, be not creepy and not too excited to meet them, et cetera. But yeah, you have to kind of play this, okay, well, I can concede these things, but I can accept this one. So it's like, I think a lot of times it's like, well, I can, I can concede that they're not, they never worked with OTP before, but they have to be able to create a mixed project and, and, and write some tests or whatever. I don't know. It depends on what, like you said, what's your company culture and what do you accept? And also like for me, I w I want to find a candidate that can write on my test and has done on the testing, but to be honest, I've yet to meet one in Hong Kong. That's just. market is so few people are actually writing on Maytest. They just test everything manually and I think that's part of the the culture of their... so I have to lower that standard down. If I met somebody like that, automatically it's a big plus one and that will move them up the ladder.

 

That makes sense.

 

So I forget what topic, why were we going in this direction? But yeah, there's definitely this kind of, like I said, the employer said, yeah, you have to figure out, hey, what can I give up? What is my hard ground, right? Okay, this guy has to have been able to have made some kind of program at some point in his life, or else I can't take that risk because I need somebody who can get going as soon as possible,

 

Right,

 

right?

 

right. Yeah, totally. Oh, I think one other thing, since we brought up the employer side, it kind of reminded me. I think it's very important, if a job, if you're applying for a job, right, and talking to the employer or the hiring person, and they say that, here's a tech assessment before we talk, right? Make sure you ask them, hey, what's the salary before I do the tech assessment? Don't just like go in blind. If they can't give you a salary, ask them, hey, can you jump on a 10 minute call? Like, let me understand, give me a range. You don't have to like, they'll say evaluation, might determine your salary. They should be able to give you a range. Don't waste your time. Like if the employer has a way to invest time before you do an assessment for you, you should not invest your time either. It's... For a lot of people, it's not for me, but I learned it lately for a lot of people, job application is a very emotionally heavy process. When they spend an hour on a company, they start imagining themselves working there. Yeah, and you wanna make sure if you have spent time doing an assessment for a company, they're taking you seriously at the very least, right? So make sure you are at least able to get a range from them. Try to get something more from them, you know, to get a proof that they're invested. Try to get a 10 minute call, at least with them before the tech assessment. Very important.

 

Yeah, that's something that we figured out also is, is, uh, yeah, you need to, you can't just show somebody a test, right? Like automatically on the employer side, you do want to see kind of sky code, right? And then you want to talk to them. But to be honest, like you need to motivate them because every job has a coding assessment nearly. I actually, I don't really do coding assessments anymore. I just kind of take a look at the code.

 

We don't do either.

 

Yeah. I just say, just send me any code. Send me actually what I usually say is send me your most proud code. code that you're most proud of, any language, I don't care. And then I'll ask you questions about it because I've had people like, have you done Rails before? You probably have, right? Yeah, so like this guy, he applied, it was Rails. He opened up the project, he did APIs for a company. There was a skip before filter for the verify, you know there's a verify token thing?

 

Yep, yep, yep.

 

So you need to do skip before filter so that you can use it as an API. So I said, what does this line do? He's like, I don't know, why are you asking me so many questions about like. Because he's like, all I did was do APIs there, right? And I was like, okay, so what does this line do? And that one you need to do all the time and you should know what you're doing if you have to edit there. And he's like, oh, I didn't memorize the entire library of Rails, so why you ask me so in-depth question? I was like, it's not really an in-depth question. Like if you're doing APIs only and in Rails, you should know what

 

Yeah.

 

this line does, right?

 

I'm actually surprised you asked me a question like that. I mean, it's okay if you don't know. It's okay to say I actually don't know, but love to know what it does, right? That's how you deal with that in an interview instead of saying back, why are you asking me a question like that? That's also so weird that someone

 

I can't remember

 

comes up

 

if

 

and

 

he

 

says,

 

asked me... maybe I got the question one, but for sure he was... I know he was like... I know he did say, oh, I don't memorize the entire thing. It's like you don't have to memorize

 

You

 

it.

 

get

 

Like

 

the faster

 

to me...

 

aggression.

 

Yeah, maybe. I don't want to make him sound like he's a bad person, but like I think my point of this whole entire... of what I'm bringing this up about is

 

Mm-hmm.

 

like... To me, I'm asking questions that I think you should know and this is stuff that you wrote yourself and... If you did come back to me and say, you know what, I just copied and pasted it. This kind of person is not a good person to have, I think as a developer, because. Like, can you imagine, like, I always give this example to people. Okay. Say you have, you know, a kid, right. And you take your car to a mechanic and it's got some problem. They say they fixed it. They gave it back to you and you asked them, you know, what, what was the problem? And they're like, well, I don't know. I just kicked the engine and started running again. And like, would you feel safe to. put your kid in that car and drive? I mean, most likely not. And they would answer usually no. I never heard somebody say yes to that. And so I'd say, well, then how can you expect the client to have their business depend upon the software that you're making for them? But you don't know what that line does. Like you don't have to know, like you said, it happened with the compiler stuff, the deep. You don't need to know all that, right? But you need to at least know, okay, this line is gonna be skipping the validation tokens so that way you can. use it as an API. That's enough, I think, for that particular case. But if you're just copying and pasting, you don't know what's going on, man, how are you going to know when something breaks, how to fix it, if you have no idea what some of these lines are doing? It's crazy.

 

Yeah, I think there's a balance, right? Like where you need someone to know, obviously you need someone to know everything and you need someone to know something. I think that skip before action thing that they're saying, I might put it in a place where I might be okay hiring someone. If they admit that they've copied and pasted it, I just copied and pasted it. If they admit that, I might be like, you know what, fine. Most of the stuff, if you're a junior engineer or mid-level engineer, most of the stuff you're going to do, we're going to review anyway. I'm going to force you to add tests anyway. So, yeah, I might let this one go, but I see the point. There is a place, there are certain things like that for me too, which are a requirement. There needs to be a certain level of understanding of what you're writing.

 

I think another thing to point out too is I also did a recent interview a couple of months ago. So he's a self-proclaimed elixir, senior elixir developer, right? So what I do is I always, you give me a weird look and I'm not too sure why, but

 

self-proclaimed

 

I'll tell you more.

 

senior elixir developer, so he didn't have the title.

 

Well, I mean, I don't know if he had the title or not. I just remember that in the CV it was there. Um, well, the reason, okay. Now the reason I'm saying self-proclaim, maybe I'm just being a snooty asshole, but, uh, the reason I'm saying this is because like, I asked him just stuff simple, like what's a gen server? What's OTP? He was unable to answer that. And his reply was, Oh, I just learned enough Phoenix that I can get the work done. Well, then to me, you're not a senior Elixir developer. You're just.

 

Junior,

 

Senior developer,

 

very junior.

 

junior and elixir, but maybe not junior as a developer. And that's fine, like you said. But the problem is like, I remember going, I just want to kind of touch back on what you said about like, okay, are you telling people enough about yourself? Well, at the same time, you're, you know, what you tell is that you're also setting up expectations. So if you come to

 

Right.

 

an interview saying that you're a senior elixir developer and you're only doing simple crud apps with Phoenix, and that's all you know, and you're just getting along. you may want to adjust your, adjust their expectations and not say you're a senior elixir developer. You can just explain to them right away, hey, you know, but if you come to me saying you're a senior elixir developer and all you've done is Phoenix, because of the way Phoenix has done, like you don't need to know a lot about OTP. But again, I had to, I adjusted my questions because of what he presented himself before we even started the interview.

 

That make sense? Yeah. I mean, setting, yeah, over promising, under delivering, doing interviews, yeah, one of the worst feelings as an employer.

 

Yeah, but I think that's another thing too is like, I think most developers, they don't really wanna gloat about what they've done before. And also my hardest part is like, I call it like typical Tuesday, right? It's like, okay, well, I've done stuff. I think I brought up an example before, like this guy was promoting himself. He's very good at promoting himself about taking Google Translations from Google Doc and sticking them into an application. I did that like more than 10 years ago. And my client was like, hey, how come we should bring this guy on because he can do this. And I was like, listen, I did it like more than 10 years ago. Like if you wanted that, we can do that. Like, but, oh, how come you didn't tell me? Well, I didn't know you wanted to know about that. And to me, like I said, typical Tuesday, we do this kind of stuff normally. So it's not like we're not making anything crazy. It's just, but it's like, well, how do I know what I should tell you? What I shouldn't tell you? That's another, like on the, on the interviewee

 

Right.

 

side, it's like, well, what should I say? What should I not say? It's really difficult. Like both sides, you know, how do you, and also like how do you let people know like, you know, every, you're not gonna tell everybody everything that you're doing for your backend. So like, let's say you're integrating with Google Maps and this guy may be a Google Maps expert and that may be a core piece of your application or at least a good part of it. And you don't display to people and people won't know to talk about their experience with that, that's really tricky.

 

Right, right, right. Yeah, definitely. But I think that also brings up a good point about, what again might be obvious to both of us, is like, definitely ring to a job description right before the interview, and setting your introduction in a way that you're checking off requirements of the job description, right? That's also something I actually mentioned, but that's kind of aligned with what you're saying. As an interviewee, I should make sure I sell myself best for this job, at least the description. paper. And if the descriptions are accurate, that's on the template, right? But if the description is accurate, and here are the 10 requirement bullet points, let me come with like a script for my introduction that checks all if not most of those bullet points.

 

Okay. Yeah, I mean, it's tricky. Like, there's all kind of questions like how much of my card should I show to you?

 

Right, right, right. It's always tricky, yeah.

 

Yeah, I mean, do you have any more to say about this topic?

 

I don't know. I mean, we didn't really talk much about architecture, system design like question, but that will probably be in more senior category. Yeah, I think, yeah, I mean, if you have worked with projects you've deployed and like worked with Microsoft or any kind of distributed systems, only then you would have those questions. And that's probably like our small proportion of our audience. So maybe we can cover that some of the time.

 

Okay, then I think if you don't have any kind of closing topics or closing, let's say arguments, it sounds like we're debating. Any more closing ideas? Maybe we can transition over to PIX.

 

I'm not, I think I'm a fud.

 

Cool, actually yeah, I quite like this topic maybe because I talk a lot. That's why I like it so much. So that's another tip for you guys. So whichever side, say you know, not only for the interviewee to want the employer to want you, but also if you want, if you find the perfect candidate and you want them to want you back, the best thing to do is let them talk as much as possible. Just a simple, like maybe it's a little bit of a kind of a trick, but at the same time You know, it's people who need to like each other. And the more you talk, the more likely that you like that person who you're talking to. Yep, see, Adi's doing a good job letting me keep talking and he's just shaking his head. So he's a professional at this. If you need help on how to do that, Adi's the guy. Not going over to pics. So I can go with my pic first. I did have a specific thing, but now I don't. What was the thing? But in any case, so I'm actually traveling at the moment. And I've been taking lots of pictures and stuff. Highly recommend if you guys are a traveler, pick up a GoPro. It's been extremely fun to work with. Very small, waterproof. I love it. So GoPro Hero 10 Black I've been using. It's a lot of fun. Mostly because it's waterproof you can take it basically anywhere and it's very compact and small. So that's kind of like my pick. Adi, how about you?

 

Yeah, I'll have a job fit after this, but I'll share a recent one with the quiz. I guess I'm gonna do a job. That's what I would like to do with the quiz. Uh, shoot. No, yes. Yeah, I've been playing with darts a lot lately. And it's a great way to do something while thinking about a problem. It's been really helping me. I think I... Recommended punching bag one of the previous pics that's also a good one, but you get tied very quickly But if you want to make a less tiring Activity that you can do while thinking which while also getting good at something that's a really good That that's that's my One of the non-tech pics. Oh another one is a video game straight just came out for PS5 I have a couple of days off tomorrow and the day after, and I'm gonna play a trade. You're a cat in a post-apocalyptic world, and it looks like it's an open world RPG, but you just play as a cat. So it's a very, very cool game, so you better try it. And jobs. Whew. I have at least six companies that are hiring. The prominent ones are Pepsi. And you know what, the details will be in the show notes. Yeah, I think mentioning them here will take you too long. But there will be like six companies and seven companies in the show notes. So yeah, please apply there. But if you have any questions about hiring, finding an electric job, need help with anything, don't hesitate to reach out to me. Don't hesitate to email me. Some of you have already done that, but I'm willing to help more folks. Sam, please feel free to reach out to me.

 

Okay, and with that, see you guys next time. Bye. 1