Hi everyone.
I’m Johno the Coder. This is big tech on point #btop. And today we are talking about “it’s all foreign to me, your non-tech tech hirers cheat sheet.
Now, if you are listening to this episode or , or this episode is particularly relevant to you, that’s probably because you are hiring your first tech person, or perhaps you are in a position where you are hiring a tech person and you haven’t got another tech person to use. Usually if you have a developer, you’ll bring them into the interview so that they can understand the tech jargon bit. This assumes you don’t have access to that resource for whatever reason. So this is how we’re gonna try to untangle some of the and figure out whether this person is actually good at what they do without you being there. This is based on me not being able to sit in every technical interview or every interview, but trying to gauge from first interviews, whether this person’s likely to be a good fit. And this is just a bit of a cheat sheet to help you figure out if this person is actually good at tech, or if they’ve managed to kind of bluff and their way around. And you’ll find that some tech peoples you try and hire can promise everything and deliver nothing. Hopefully this episode will help you avoid that situation because believe me, it is painful.
So the first thing I want you to do when you’re in that interview is I want you to admit that you’re not a technical person. There’s two reasons to do this. And the first one is you don’t want them to just start throwing tech terms at you, because the way that they talk to you as a non-tech person should be different. The second thing is this will give them the opportunity to start trying to black you, because you probably can’t understand what they’re saying. I know it’s awful. It’s a bit of a black, but we’ve all heard the phrase, baffles brains. Some tech people do like to do it. They like to throw loads of jargon out there either to get themselves out of a tight corner. They’ve accidentally knitted themselves into, through incompetence, laziness, wherever you want them to know that you’re not a tech person, because they’ll catch you out. If you, if you don’t tell them that, they’ll figure it out anyway. So you’d rather be upfront about it. So what you also need to know before any of the hiring process starts is what’s this person gonna do? What is their core skill? Are they picking up just a bit of it support and some website maintenance are they expected to look after a database? Are they expected to look after technical support for the website? What does this person need to do? Cuz the skills that they need are gonna be different for that other information that’s useful to know. And really you do need to know is what technology do you need them to use? Because there is no point in hiring a JavaScript developer to look after your WordPress eCommerce site that is business critical. You need , you need to the stand at a very base level, what you need this person to be able to do. So when they come in, you’re gonna have the usual chain , the usual team fit stuff , or the normal interview stuff.
If you are the sort of person that likes to ask what their strengths or weaknesses are, do that I suppose. I mean, it’s probably not something I would do, but I’m not HR expert. So I want you to talk tech a little bit with them and really what I want you to talk to them about are industry standards. If they can tell you about some industry standards or lack thereof , cause some languages don’t have them for specific reason, like PHP has the PSR , uh , the sorry, the PHP fig the framework interoperability group. And they set out a bunch of PSR standards. And these are international standards that across the industry, we all kind of go, yeah, that’s a good idea. We’ll follow that. So that all of our code looks the same because when you have thousands upon thousands, upon thousands of lines of code, it’s handy to know things are written in a very similar way. And there will also be other kind of patterns you might hear solid talked about. I’m not gonna cover that. That is a heavily technical term, but what you’re looking for are how would someone else, that’s not, you be able to understand your code and what assurances do we have of that. And that should come with some peer review process.
So they might talk about code reviews or merge pool requests, merge and pool requests , uh , like an interchangeable term. But it’s about putting your code into the teams code. And how does that work? And have they had their code reviewed before? Talk about collaboration and integration. How have they worked in other teams of other developers? What issues did they find up it ? The usual team fit questions you’d ask , but with this kind of tech spinoff talk about source control management. Now that’s usually gonna be in GI , but it might also be in SVN. Uh , there’s any number of ways that could have happened, but make sure they’ve got that ability to collaborate with other developers, talk to them about scope and specification scope creep. And how do they manage that? If the project changes halfway through, how do they manage that process? And you are looking for answers. There’s not a definitive to this cuz it’s gonna depend on how your business works, but really what you are looking for are answers that suggest they’re compatible with what the business is gonna ask and how they’re going to consequence produce something technical to hit that requirement. Also ask them about testing their testing processes. There’s 101 different ways to test stuff. And I have got another episode that talks about testing in some detail so that when you are talking to your developers about testing stuff, why wasn’t this tested the different kinds of tests we have, how things can get me missed from tests, what kind of things should have been covered by tests and what the limitations of different ways of testing are. But talk to ’em about testing, find out about their processes.
You also wanna talk about deadlines and management because in theory, in this scenario, you haven’t got another technical person. So they’re gonna have to manage that themselves, but really talk them about that in terms of , uh , there’s a little cheat sheet kind of moment here, the S DLC , the Sierra Delta Lima , <laugh> the Sierra Delta Lima, Charlie, okay. The software development life cycle . Uh , you can Google that . I’m not gonna go into it, but talk to them about the SDLC, how does what they do fit in with it. And all these things are gonna kind of really give you a clue as to whether they’ve really worked in the industry before some CVS can look really, really good. And the problem with those CVS is when you actually dig into it, it turns out that yes, they have built a bunch of high profile websites, but they were exactly that they were just websites and they’re coming into a software role or perhaps they’ve gone and done some stuff. You know, they’re quite new in their role, but they’ve done some stuff. And it all sounds quite impressive really, but it turns out they were all businesses of friends. They were side hustles. They weren’t, it wasn’t the same. It was working in a commercial environment and that’s something else you’re gonna look for this per person. Can’t because they’re gonna be your only tech person. You really need them to have experience working with. And ideally being mentored by other more experienced tech people and having worked around, obviously if they’ve managed tech people great, but managing tech people and working around tech people is going to be like a really good measure for you to understand whether or not this person was, has the experience that it looks like they have, cuz you’re not gonna be able to technically quantify that experience in the same way that a developer or a technical hire would be able to , uh , talk about agile.
Most developers with any sort of commercial experience now should have at least some exposure to agile and agile. Doesn’t just mean changing what you do. Agile again, there’s another episode about this, but agile is a methodology in the way that we develop software in the very simplest of terms, it means we deliver working software frequently rather than doing a long build cycle and figure out how they manage that. And they should, the cheap for you here is they should mention things like sprints, burn down velocity. There’s a bunch of tech terms they should mention with that. That will give you a clue. They have worked with other project managers and they’ve worked with other technical teams before. So what you are then looking at. So the other thing you want to figure out is how is this person actually gonna deal with a scenario, but we’re not gonna do scenario based questions cuz that’s kind of crazy and you won’t be able to emulate a real scenario. So a question to think about would ask them about a really difficult bug to find why it was difficult to find what information they had to go on. What made it so difficult to find and how did they fix it? And you’re looking for the depth of their answer, the kind of sincerity there should be like a genuine head scratch as to why this bug was hard to find and bugs are notoriously more difficult than features, which is probably something else I will cover later on. They should be able to explain to you what the technical problem was without baffling you, because they are only tech person. So if they’re just gonna baffle you all the time, this is isn’t gonna be the , that’s not conducive to you having a good working relationship with this person. And if they can’t explain what they did or why they did it, what they don’t know how it got fixed or anything like that, then they didn’t really understand what they were doing, not being able to fix or not being able to explain how they fix something means they don’t know. And that means it could break again. So there’s just a little cheap question. The other thing that I would ask personally is what a good developer looks like. And it should give you some insight into how they think and what kind of developer they are. And obviously, hopefully they’ve described the, so that’s just another one that I would kind of, you know, if you hire another one , this is maybe your first tech person potentially this person’s gonna be groomed into the role of being your sort of tech manager.
So understanding what they think the skills of a good technical person are, is probably gonna be quite helpful and then ask them about good and bad projects. Now from the good project you want to ask them about the impact it had on the business and why it was a good project. Maybe it was on time. Maybe the functionality was flawless. Maybe it was scalable far beyond what was actually required. They needed it to be able to handle $5,000 a day. And it was capable of doing 50,000, whatever it is, but they should be able to understand that and then ask them about a bad project. Maybe it ran over deadline. Maybe it was full of bugs. Maybe there was issues. What made it a bad project, but also what impact did that have on the business? Cause if they can’t understand and explain that to you, that’s probably not a good sign of your relationship to come and the projects they’re gonna do for you, they need to be able to understand as your sole tech pass , what these impacts look like, what does it delay? The two week delay in project going in most places is a thorn in your side. It’s an annoyance, but it’s not the end of the world. But if you are saying an agency that might mean that you have to cut 25% off the cost of your project, if you are in house , that might mean that other projects got delayed, that really needed doing, then there’s the cost of the developer and there’s all this other kind of stuff. So they should hopefully understand the impact of when it goes on and be able to mitigate that. How would they mitigate that ? How would they improve it next time? And there should always be something they could have done and we all get better if they can’t talk about why something went badly, they’ve not learned from it. So they’ve not, they’re not able to then improve. Most of the improvement process is this iterative evolutionary thing. It happens over time. That’s the friends in experience. So hopefully that has given you a bit of a cheat sheet into how to make your first tech higher and how to try to understand whether or not they’re just trying to you or they’re actually good at what they do. Obviously there’s other factors that are gonna come into it. The pedigree of previous hires, their salary, all this kind of stuff. But hopefully that gives you a little bit of insight and will help you make that first higher and avoid some pain . I’m Johno the Coder. You can follow me on Twitter and everywhere else at @ johnothecoder. This is big tech on point # btop and I will see you next time .