Season 05 Episode 10
– May 17, 2022
Show Notes
Hiring Junior Devs and How to Stand Out from the Crowd
Learn about the process for hiring junior developers and get insight into common mistakes made as well as how to stand out from the crowd.
Show Notes
- Terence has 12 years of experience with hiring.
- Number of applicants and number of interviews
- What's important in filtering candidates to interview
- Soft skills
- Advice for developers on portfolio sharing
- Contracts
- Job ad requirements
- Code test
- Attention to detail
- Common applicant mistakes
- Bootcamps
- Tips to stand out during the application process
Show Links
Accuracy of transcript is dependant on AI technology.
Hey, this is Mike, just letting you know that halfway through this episode, Amanda's microphone cuts out So you won't hear her for the second half, but it's a great episode anyway tune in and she'll of course be back on future shows
enjoy Hello and welcome to their website one-on-one podcast the podcast for novice web developers and small business owners Who want to learn more about running and optimizing their websites? This is season 5 episode 10. I'm here with Mike and Amanda as usual
And today we have a guest, Terence Sawtell, the founder and strategy director at Goat, an agency based in Vancouver. And he's going to talk to us about hiring developers. Terence, welcome to the show.
Thank you for having me. Yeah, thanks. Thanks for being here. This is going to be really cool. We have a lot of listeners who are, you know, junior developers kind of thing and maybe some of them are interested in getting into the professional field and hopefully they
can learn a bit about it from you today. I hope they can too. I mean, we need more of them. So hopefully we can encourage them and not scare them. We probably also be a good refresher for more seasoned developers.
who've maybe been in a job for a really long time, or working from home once they switch it up. Yeah, exactly. I mean, I don't know anything about applying for a job. It's gonna be interesting to find out
what the differences are since when we were doing it. I fell into the one agency job I had. I just got lucky. I didn't even apply for it. It just was handed to me. So I've never actually applied for a web developer job.
It's interesting, our senior devs, most of them have come from that kind of that. It's like they just, you know, conversations happen and referrals. I meet them through something and it's like, hey, do you want a cool job?
Yeah, sure. Okay. That's pretty much what I have to get up checks out. Like, yeah. All right. So you want to just start off by telling us a little bit about your company, where you work, what you do, that kind of thing.
Yeah. We're a small UX UI dev agency based in Vancouver with nine full-time staff, a few contractors to help support, you know, different resourcing when we need it. And we build lots of like content.
like, like universities, government. And then we've also do a lot of kind of work on stuff that's already been half built. And we're trying to audit and go through and fix someone else's work. So there's a lot of, you know, very technical work that has to happen.
We were Canada's first craft CMS partner. That's how Sean and I connected. So, so we, you know, we definitely were a WordPress focus for many, many years and still have a lot of WordPress work, but
I'm a big believer in. and lean and light products and I am a massive fan of PHP. So I'm trying to keep the dead dream alive. Another PHP fan, last episode we recorded earlier this week, we had a huge PHP fan and Amanda is big into PHP.
She's a resident PHP expert here on the show. Awesome, yeah. So yeah, we're just, we're small, light, but we do, we try to do 12 big projects a year is kind of our thing. So we don't wanna, you know,
the projects are very in depth and have a lot of strategy work that goes with them. Nice. So, a big 12 big projects a year that would be one a month or you just, it's 12 over the year and the length of time depends on each project.
It depends on the client and how well they're behaving, right? So, if they're fast and there's feedback cycles are quick, yeah, we can, we can, we can, we do some pretty crazy amount of work in a short amount of time, but no, it's generally
speaking, you know, there's, there's, there's over, you know, design overlap with dev and, you know, but it's 12 years kind of the goal is the goal for us. So, from an end new perspective anyways. So, Terrence, how, how long have you been formerly hiring people?
to work for your agency. Did you do this before you were self-employed or running your own company? Yeah, I've been hiring people for about 12 years total. I worked for Tell Us before this. So you're all Canadian, so you're very familiar with Tell Us. Tell us is a phone company?
Talk on company. I guess talk on company. We'll call it, but they've got so much now. Before that, so I did hire there. And then when I left, I was able to do it on my own with my own rules. and practices, which was nice.
But it was definitely valuable learning how to hire in a corporate world. So I guess collectively 12 years, I'd say, let's say three at Talis, and let's just say nine, doing it on my own. But obviously many different types of positions,
but for the most part, it's been related to some type of technical position at both Talis and this. Wow, so you definitely have a deep experience with looking at resumes, portfolios, and conducting interviews and things like that.
How many interviews do you feel that you've conducted over that time? I don't even want to know. 12 years, that would be a lot. It's a lot. You know, actually, at Talis, it was a lot because you're kind of, you know, a product
of the process of HR and whatnot. So they have very specific amounts of things you have to do to hire someone, whether it's interviews or, you know, reference checks and stuff, you know, with my own company, you
know, we're fairly small. So it's actually not as many as I'm probably exaggerating a bit just, you know, by just my reaction. But, you know, there's all, especially juniors and new developers, you know, we will cycle
through quite a few. Peripheral those resumes before we'll make the decision to interview and and and at this point I actually am not the first interviewer our director of operations is and he's more technical than me
So it's it's nice to get those things out of the way first But I've had a few and I've also gone through like the process With a big corporation like tell us and then and then been able to take what I've learned there
What I like and didn't like an apply to my own business. So Right, yeah You mentioned there a second ago that you you go through a lot of them before you actually do interviews or whatever I was gonna ask because I remember when I was applying for jobs
I would always wonder how many applicants, are these people looking at? I'm applying for an RFP right now for a project, and the thing has been online for a month. It's been promoted everywhere, and they must be just beginning flooded with proposals.
And so when you hire for a position, how many applicants tend to respond, and then how many do you generally try to interview? How's that go? Yeah, it's a good question. I'm also in the RFP space as well.
I've been on a lot of stuff, so I feel for you, and I'm sorry for you, and we can go talk about that for a hour. Terrible students. You know, it's hard to say. I think, like, developers specifically, we try to keep
things pretty. We don't want to go through a ton. There's so much work in trying to evaluate it, and you actually end up, it's almost a waste of time. When you're trying to dig through 100 applications,
you're just basically pulling it straws. It's like a lot of diminishing returns that's a lot of returns. Yes, huge amount of diminishing returns, and it's not fair to the candidates to be on. It's like you're really just setting them up for failure.
And it's almost like an old saying, like you go to a car, you look by a car and so you end up buying the car at the 50th of the ship because you're just sick and tired of doing the process, right?
So you end up, cause there's scummy car dealerships. So, you know, I think that's what happens when you're hiring. So we've tried to filter quite a bit through just our careers page and making sure that they're qualified candidate before.
And the reality is, there's just not very many of them available. So, you know, your product of our current job market is not great for it. agencies, which is good for perspective employees. But yeah, so I would say, if you try to keep it limited,
I'd say on a single junior dev posting, we will try to get it down to eight or 10 applications. And then from there, we'll interview, probably the first interview for three to four. And if you think about it, that's 25 hours of work for me.
So we keep it. Wow. Hiring is an expensive time, intensive process. It's awful. That's awful. I quite enjoy it because I love the evaluating of personality and people. It's probably, frankly. blackout.
one of my favorite parts of being a business owner is the people part of it and evaluating and learning and growing up and helping people grow. But I mean, just the time sink in itself of the interviewing processes is insane.
If you're getting all of these hundreds of applications, which doesn't surprise me at all, like how do you have like some specific things that you look for to narrow down to potential applicants to hire?
Like are you more interested in working at portfolio work or like maybe even just student projects or do you really just stick more to like the stuff on the resume? I don't care about your- resume. I want to see your work. I think with developers, and like, I didn't learn
traditionally, and you know, if you asked me to build a website today, I'd probably fond her. So for me, it's all about, are you playing? Like, are you having, are you trying things? And I don't think, I've always looked at developers, it's a trade.
It's a modern day trade. It's like being a tile center, or a carpenter. You need to practice. You need to run. And for or if you're in death laddox I played hockey growing up So it's all about practice like you shoot a hundred pucks a day Bob like and if I see a developer that it
Spents more time on the resume and selling themselves without actually just getting in and doing it It's a flag. Yeah go play like like when you were a kid you had a pile I go play Build shop even if it's pointless, you know the best example look at wordle like that's my favorite thing
I'm like man if someone just came to me that that I should made out like a frickin by the way that helper Ben. You know he was just playing. He just built something. I heard he made it for his girlfriend.
Yeah, he was just like, oh that's what he said on the syntax FM. Right, West Boss interviewed. We had West Boss on our show just recently and. Oh, nice. He interviewed that, I forget that Mr. Wardle,
I guess his name is Wardle, right? Mr. Wardle, yeah his name is our W.A.R.D.L.E. Crazy cool, sorry. It was really cool. And yeah, so yeah, short answer is, it's just what are you doing to play and learn?
And I think for me, that is key. You know, you need to have the core fundamentals in your resume, but like I personally am skipping right through that. Like I just wanna see what you're making. And it does need to be perfect.
So then are you actually like going in and looking at their code? Or are you more interested in like almost like a description? You know, oh, this is what the assignment in college wanted. And this is how I went about doing it
and sort of showing more of their like creative thought process and also writing the code. Early on, me personally, I'm looking at the description like what's the problem with how you solve. like what kind of things did you run into, you know?
That to me is the, from myself personally, if we feel like they are able to articulate that and get through that process, then we'll move on to looking at their code and digging in. You know, I think when I was exposed to this,
you know, even as a teenager and PHP and development, no one wanted to talk to us, we were losers. Like, we didn't, we had nothing, and we had no involvement in the customer experience when it came to delivering this service.
We were just the mushroom dwellers in our business. But now you're expected to be in front of the client. You are an integral part of the strategy. So there's more to it than just being able to code something.
So I'm trying to evaluate that upfront because if you can't figure that out, I can't teach you that. You need to practice that. So to evaluate a developer's ability to communicate with your client or be in a client meeting,
what kind of soft skills are you focusing on or most interested in? Good social intelligence ability to listen. writing notes, right? I mean, there's a classic one that I personally am so horrible at and I stress and stress.
Like take notes, don't make mistakes on things that clients have said and you forgot. That's the kind of credibility stuff you need to work on. And these are all things I personally have had to work on
more than I'd like to admit. So I think you're just good social intelligence ability to carry a conversation and be able to articulate and explain why and what you're doing. I think those are really key.
And the reality is you can't expect a junior dev to come at you with all those. skills. You know, as employers, we need to be open and ready to teach and learn and teach sorry and help develop because if we just, there's nothing worse than like getting a
job, they all right, like here's this massive project, like have fun. You're like, the reality is you can't expect that from a developer right away. So there's a little bit of push and pull there. But yeah, those are the soft skills. Just really, you
know, we have a junior dev right now and he came from a customer service role, you know, from a software, they're like a legal software company. and he went and did a boot camp and his soft skills are incredible
because he literally spent the last two years like being on phone calls, helping people learn how to use their software. So it's reps, right? Yeah. It's back to reps. And there's a certain amount of nurturing
that your agency will have to take account for when you bring someone in, right? Yeah. Because I would feel like NuGrat, like not only is joining a new job at a new company and meeting new people, that's intimidating,
but then you've also got these new graduates who are, you know, they've got imposter syndrome and there's a lot of times are just intimidated to be talking in front of anybody that they consider an adult
because they don't think they are yet. Right. Yeah. That's true. Oh yeah, I didn't even consider that. On top of like, I'm new to the job and like, I don't know what standards this company is looking for.
or conventions that they use, there's just so much to think about it, it'd be overwhelming. What I think's really unique about our industry is, we are, a, we're brand new, right? We're, our industry is max 25 years old.
Yeah. We don't know what we're doing. Like we have no, really no clue. We have no generational experience. If you look at McDonald's, you look at being a contractor, like there's a hundred plus years of time
in developing process. We have no standards. We don't know what we're doing. We're all seasoned, this is the sad part, we're the seasoned people. We're the best of them. This group here is a seasoned group of people
that have been in our industry, so that's scary. We created the industry standards as our generation. And you can see this in some of the controversy around things like tailwind, where you're putting lots of classes
inside and it's like, you're not sitting. you're converting your concerns, but we're still figuring out what the actual standards should be. And a lot of junior developers and what I love right now is there's a lot of career
switchers, right? Like this is what we need. You got people working on gas, potentially going into debt because that's the transition moving to a digital world. And they're used to the 100 plus years and multi-generational industries that have got
experience. It's just no brainer stuff and they're coming to a company like me and I'm like, yeah, here's our talk, documentation. I'll say our doc. is really, really good for a company of our size,
but it's still nothing in comparison to the onboarding documentation for a company. So, you know, it's a long version of that question. I think it's, you gotta be, you gotta nurture. And you need to really understand
that we are children in the grand scheme of industry. And that people need, people don't know that when they come into this business, in this profession. Hi, Sean here. Hope you're enjoying this episode.
of the website one-on-one podcast. We'd love it if you'd give us a review on Apple Podcasts or wherever you get your podcasts. These kind of reviews help new listeners find out about us and allow us to keep doing the show. Thanks.
I want to take a step back here briefly. We talked earlier about, you know, you'd like to see the work they've done and see them play that they've played around in that. What kind of advice do you have for a developer who's looking for a position, but the work
they've done has been off. either behind some kind of a login or it's like proprietary, they're not allowed to show it. And again, speaking for myself, this project that I'm about to submit a proposal for, the thing they're looking for, I've done very similar work for
another client, but you can see maybe 10% of the actual work without logging in and no one will have a login. So what's your advice for someone who has that kind of work? How do they show that? What should they do instead?
Well, always look at the contracts and talk to a lawyer if you're really concerned about... prior to our information being shared. I'm always, I'm all about having a good lawyer. But on the flip side of that, I think a good,
just having password protected and write a case study with as many screenshots and as much code so that you can possibly share. I think you just need to be really careful. I actually have had, I'm trying to think of someone
who interviewed or hired, they had a really good password protected portfolio, but it was a designer, sorry, it wasn't a developer, they had a really good password protected portfolio that actually had
a lot of that stuff in there. It was like, hey, I'm gonna show you this. Don't tell anybody. Yeah. But it's screenshots and stuff like that. On the flip side, I feel like, especially if you've got all this experience
and you have a good support of leader and you say to them, hey, I'm moving on, we know that. Is there any way we can work together so I can share some of this so I can help me get my next role? I personally would be all for that.
I'd be like, yeah, absolutely. Just show me what you're gonna show first so I can just make sure there's nothing impacting from our legal perspective. PEACE you put the company at risk or you make a company
and put a company in a bad spot, that's a world of hurt. And I would be not very impressed or happy. And I would do all the things I could legally to make sure you pay for that. So just talk to your manager.
I think that, and you can get a lot. So yeah, good bachelor protection portfolio and just talk to your manager. Like again, brand new industry, we all have a responsibility to foster and build up our people.
I would also say that for freelancers who are eliciting, you may. not be permitted to publicly share work for whatever reasons. But that's publicly like I have exactly relationships with a couple of agencies and they don't want their
clients to know that they're contracting me for whatever reason. So I my work is all white labeled. But when I put a proposal together, I can include screenshots and say, Hey, I built this and it was managed by agency ABC.
Boom. So, you know what? it's getting that permission. And I've explicitly gotten that permission. I don't do it without permission. Yeah. I'm happy to share a clause we have in all of our SOWs and our MSA at Master Service agreements.
And it's basically saying like, I have full right to share with my work privately. Okay, cool. And if you don't have a contract, you are, do not lift your finger until you have a signed contract ever.
I know it's unrelated to this, but it needs that. It's just. It's a non-starter. So there's a clause I have if you want to, if you're a freelancer, I'd love to share it. I'm happy to put it up there.
Please do, please do show that. Contracts is our most often requested topic and we have yet to cover it because we want to make sure we cover it properly because it's about law and whatever. So we will definitely be following up with that in a later episode and we may hit you
up for some advice if you have a lot of experience on that. I am not a lawyer, but I've been lawyer. So I'm happy to help. Got it. So we've all seen the job ads for developers where the list of skills or requirements is
so long. It's unrealistic to find anyone who meets those requirements. It's just, you know, like language soup. Just so much in there. Do you employ this kind of job ad? Why or why not? No, fun story about this.
We bid on an RP, hopefully we win it. And in one of the proponents calls, it said it was using, we want CSS cards. And I didn't say anything in the early, the questions right. and it's a great example of why there's a lot of words to because they just put lingo
in there to make themselves feel like they know what they're talking about. And that's a lot of the times the case on a job ad, especially with big companies. And the proponents call I said, well, what do you mean by that?
Because those two things don't go to get there. So yes, that's a programming language. And a card is what I don't know what you mean by that. So they're like, oh, it's just a terminology issue. We probably use their own term.
So a lot of times the word soup you see is written by. by someone who pulled that from a database of something or copy base of from somewhere, and they really don't have any ideas. So we don't. I would be, now that I'm thinking,
I'm like, oh, Dewey or not. There's definitely a lot of skills I'm looking for, but when it's a junior developer, which is what this is for, we're pretty light. We just say, you have the basic knowledge
and experience to understand syntax. And you get that, you understand problem solving and there's a there's. You know, you understand what GitHub does, right? Like, you don't expect you to be able to be an expert
in deployment and version control. But no, I try not to get too much in the weeds on the details on skill set. We have a senior dev position we're hiring for right now, and yeah, that one's got some specifics.
Like, you know, there's a very, you know, being compensated very, very, very warmly for that. So, but in the junior stuff, we try not to overwhelm. And even, and what I would say to that is, don't be discouraged if you do see that
because I would just apply. Anyway, like at the end of the day, if you're technically technically proficient, they'll hire you. And if you're not technically proficient, they won't hire you. So what do you have to leave?
That was my follow-up question. What did you say to somebody who wants to apply, but is intimidated by that? Don't even look at that stuff. Like go for it. Like who cares? What do you have to lose?
You're not going to make anybody upset. I can tell you right now, there's no one on the other side and that's going to go, oh, they didn't look at that last. They don't care. In fact, they probably don't even know the list exists.
And really, depending on the process and internal processes, if it's a small company and you know that, you know you're going to be talking to someone. on the ground. But if it's, you know, 100 plus person company, they've got an HR person dedicated
for that role. And they probably wrote that thing. So just don't worry about it. Yeah, it's probably often written by someone who's not even one of the developers or whatever doesn't know. Yeah. Yeah. They're gonna they're gonna say no to you if you can't get through their technical testing
anyways. And I know that's something we're gonna talk about. So who cares? Yeah, a few years ago, I saw some something on the internet. So it's got to be true. And the source of all truth about the creator of a
The specific language was unqualified for a job because the job required more years of experience in that language than the language had been around for. I saw that. I know it's what you're talking about.
That was funny. I can't remember what language it was. It was like no, and I think no words, press or something. Yeah. Oh my goodness. That's so good. Like years of experience, like that's a really good thing.
I actually, we actually purposely put zero years of experience on some of our ads because we don't want you to have experience. We don't expect you to have experience. I do. You can't have experience.
You're brand new. Even our senior dev, I think we're only asking for three to five years. Like, and even that, it's a loose term. In fact, I almost want to take it out. That's good that you don't require experience from, because that's one of the big catch-22
stuff. You're trying to get experience, but you need experience in order to get the role. That's good that you don't do that. Just don't worry about that stuff. Just focus on being yourself and don't worry about those details.
I want to step back just a bit. You mentioned coding tests. I was... wondering, do you use a coding test when you're hiring? And have you ever applied for a job in the past before you ran your own
company where you had one of those? I've never done it. I've just heard lots of bad stories about it. So I'm curious. I've never done a code test. I've never actually had to do development work for other business or other companies at
all, so I didn't have to. So we do do them. Okay, it's a necessary evil. We make them very fair, though, especially because we're pea. HP Focus Agency and no one wants to teach PHP, which is another topic for another day,
that I can talk for many, many moons about. There's my input here. Go learn PHP. If you learned all this stuff with fancy React stuff and boot camp, great, but go learn PHP. You'll get a job tomorrow.
But yeah, the tests are really important because it helps us understand your level of programming savviness. I don't want to say expertise. But one of the big challenges we run into now is you get these
Full-stack developers coming out of boot camps all over the country for the record Terrence was doing air quotes when he said full stack. Yeah. I don't know this is a podcast. What am I doing? Yeah?
quote-unquote full-stack developers coming out of boot camps and The thing that we run into is you're not a full-stack developer So don't put that in your resume You are a junior developer and you're you need mentorship and you need to learn and you need reps so
The traditional route of programming was go to CompSci and learn it at university. And whilst I absolutely despise most CompSci programs, I think they're a joke, one thing they do teach you about is the fundamentals of programming and the scientific part of
programming. And the technical tests are important because it helps us understand where your level of programming knowledge is not necessarily your level of React knowledge. And if you can figure out the PHP test that we do...
you probably have a good programmer head. You might not be experts, because we're not asking you to do complicated stuff. It's all stuff that you could figure out. But it tests two things. Yeah, your ability to kind of,
you know, as a programmer and as your understanding of computer science at very minimum, like very basic levels. And also your ability to problem solve and figure things out because reality is, most developers are Googling everything
a hundred times a day. They're on stack overflow all the time, whether you're the most seasoned developer in the world or your junior. So they're necessary evil. And we make them very, very accessible.
It's a long fun. Sounds good to me. Yeah, our test, the one that we do the most with juniors is we basically just show them free Figment mockups and we ask them to replicate this in HTML CSS using either SAS or how you
compiled it and we get them to explain their work. Okay, so what is the weirdest thing that you've seen someone include on a resume or send you when they applied that just made you say, why would they do that?
Do you have any examples of anything like that? Not to put you on the spot. So the designer side, definitely more. I would say the. I think this is really common practice. Just don't have spelling mistakes
Like please don't have spelling mistakes don't have silly grammatical errors. I'm not expecting to be an English major, but like just Review your work before you submit it. It's like it's the big thing. It's just exact. It's like
If you try to deploy something Without checking your work like and you like that's just a red flag right up like straight up But you can't review don't take the time to review like spelling on your resume before you send it to us
Mm-hmm What are you going to do when we have a deploy on a Thursday at 3 p.m. And it's going to site with 2 million visits a month. Yeah. There's like no attention to detail and... Yeah. Actually, you know what?
I'm glad you bring that up. That's something I didn't forget to talk about and normally look for in that early phase. Like, what is your attention to detail? We have a way of evaluating that in our kind of like scoring system that we have.
It's not a question. it's a combination of many things. What is their commenting look like in their code? When they do that test, how did they do the interaction? There's a specific interaction we have in there.
It's a little bit difficult to make, but how they did. So the attention to detail is everything. In fact, I would say that's the number one thing I'm looking for now that I look back at it. I could care less how good a coding you are
at this point, you're brand new. But what's your attention to detail? What are you noticing you can't figure out? Yeah, no, that's a good one. So we only have one or two questions left turns. One of those would be what common mistakes
do you see kind of. make in and and that's this could be in their portfolio resume like you mentioned type of typos or it could be in the actual interview itself. I would say the most common one is just
this idea that you need to learn a bunch of little things about everything. I mean much rather you focus whether it's the thing we need or not. I'd rather focus and get good at a certain hate likes focusing on languages but like focusing on a certain area of like if you're going to do
PHP and CMSs like we've really gone into that. Or if you really wanted to do react and understand how to work with APIs and create headless products like you really went into that I have a you know
a junior developer He's just always like playing with all these like random things. He's never actually finishes something through and I've always told him like It's great. You're gonna learn a lot about nothing or a lot of I'm sorry learn a lot about everything
But you don't know anything and that's a problem. So Jack of all trades master of none master of none And you know, he's he's he's never gonna be a master of anything if he can't just focus on getting, like pick something and go for it and learn and that's why you play
because you figure out what you're good at, what you're not, what you're comfortable with. So I think that's the most common mistake I see is just, and that could be a product of just the way that boot camps are all structured now is like, yeah, do two weeks of it and
like of react, two weeks of node, you know, two weeks of express, two weeks of SQL, like it's like this like massive crash course. And I think boot camps are just trying to prepare their students for any kind of job.
And that's how that gets through my experience here in a state of history. It's not like when we started 20 years ago where all you needed was HTML, CSS and jQuery. Now that there's just so much more that's needed to get in the door.
Bootcamps have been the savior of our industry. Um, I will always go to bat for them. They have literally made our jobs cool. And we have to thank them for that because for many, many moons, our jobs were not cool.
And they weren't marketed well. So I think you're just being... present in those interviews and listening and answering questions with confidence. I every most candid, I deal with imposter syndrome, horrifically, personally.
It's a huge issue for myself. And I talk about it a lot with my team. Please don't be afraid to pump me up. Because I have days where I'm like, I can't believe I'm doing this. Oh my God. But so you got to go into those things with a little bit of confidence.
Bounce, you know, get yourself ready to go. and try to formulate your thoughts and articulate them in a way that makes sense for a non-developer. So that's another mistake going really technical and trying to like, I'm like, you're lost me.
Like just explain this in a way that I could potentially show to a client. Yeah. All right, so conversely, and maybe you covered a lot of this when you said, you know, what, don't do this, instead do that kind of thing,
but are there any kind of tips you have for a candidate that would, if they did these things, you would kind of go, oh, that's interesting. And they would stand out from everybody else. Yeah, and the application process,
how much playing have you done? We talked a little bit about that. Like, what have you built? Well, you're right. you played with, like if you got a hobby that you tried to digitize, like for the
good one was I've restored cars for hobby. So, and someone that applied for job also was into cars. Okay. And they built like an auto part tracking app when you're building your project useless product absolutely useless.
You never use it and they even knew that, but they've played, right? They, they, it allowed them to have a way to build an API because they needed to connect with rock auto, for example, which is a website.
And then they also like they just, they just had a lot of things they could play with and it was. product that was useless but... But it resonated with you. It resonated with me. That was like cool.
And they admittedly were like, this isn't useful but it gave me something, a problem to solve that was big enough that I could do a bunch of different things. So that's a big one. And I think another one is don't be afraid to, you know, people that aren't afraid to,
you know, share their work and show me what's up and be excited about it. It's this like weird thing that you have to... like put this professional like cold face on all the time. And just like that our industry's not, we're not that.
Like we're, we're not an accounting firm. And I think, I think other industries are actually looking at our industry as like the golden standard of like, just be yourself. Yeah. I'm not hiring, we're not hiring you to, to be this like,
this fit in a box kind of person. Like we are hiring personalities. We are hiring people that we can put in front of clients that can be themselves. So I think just to stand out, don't be afraid to be.
yourself and if they hire you for that great and if they don't hire you because of that, well screw them. They weren't for you just like any relationship. So I'd say those are one to three things. Makes sense. Excellent. Excellent. Well, Terrence, this has been a really great
conversation. We're so glad that we could have you on. Where can people find you online if they want to learn more about you? Yeah, meet goat.com. So M E T M E T G O A T dot com for myself personally.
Just like Ben. I'm happy to answer any questions. We do have two postings out right now for we have one for junior dad one for senior dad. So if you look. for a new gig and also too if you know any companies that want to do the type of work we do we are
awesome hire and we love good challenges so happy to have a conversation whether you're looking for a job or you want to hire a wicked cool company to do your work. Sounds like a great place to work
too. We try our best. It's important that we are remote so we're fully distributed across Canada. Oh yeah that's a good point. We never really covered that in the age of the pandemic. But yeah, that's good to know. That's really cool. Awesome.
Okay, Terrence, thank you so much for being on our show. This is really informative. Really appreciate it. You're very welcome. Thanks for having me. Recording from a secret lair while plotting world domination. I'm Sean Smith, your co-host.
The website 101 podcast is partly hosted by me, Mike Mela. Find me online at belikewater.ca or on socials at Mike Mela. One third of the website 101 podcast talent.
Have a question for Sean, Mike, and Amanda? Send us an email.
Season 05
- 1 Meet your Host - Sean
- 2 Meet Your Host - Mike Mella
- 3 Wes Bos - Your Web Boss
- 4 Tailwind CSS with Adam Wathan
- 5 Starting my own Website with Bill Campbell
- 6 CSS is Awesome with Kevin Powell
- 7 Meet Your Host - Amanda
- 8 11 Things to avoid doing on your website
- 9 Vanilla Javascript - Fundamentals before Frameworks
- 10 Hiring Junior Devs and How to Stand Out from the Crowd
- 11 AlpineJS with Caleb Porzio: Lightweight javascript in your markup.
- 12 Contract Opinions From Not a Lawyer
- 13 Talking to a New Dev