The basics that IT Recruiters & Salespeople need to know about software

I remember when I first got started in this business how frustrating it was because I didn't really understand what software engineers actually did. I would Google things to bone up and try to get my learn on, but the subject material was quickly over my head and spoke more to actual developers than people like myself trying to get developers jobs. My solution ended up not being better reference material, but simply asking my candidates how I can better serve them.

"All my clients are asking for "X", and you have a lot of it. Why is "X" so important from a business perspective, can you break this down in a functional way my recruiter brain can handle?"

That led to the most important thing I've learned so far in my career. Being "technical" is quite different than understanding technology, and a lot of the info I felt I needed to do my job better wasn't even applicable to the business of placing software engineers. Nobody is going to ever ask you to do a code audit, but a high level understanding of some software basics will empower you to build better teams for your clients, and find better homes for your devs.

Whether you work at SpringbokIT, Modis, Randstad, Robert Half, we all have a responsibility as an industry to give our candidates who code and clients who rely on them a better experience.

What do people do with software? As complex and amazing as software is there are only a few ways people actually use it.

Design it: Architects build the blueprint,some are involved with both the technical and business functional aspects of design. There are people that just do architecture, and lots that do both architecture and coding.

Build it: Now that you have a plan, you can start coding. You may be building something brand new, or building a new feature for software that already exists. This is the part where the developer goes clickity, clackity all over the keyboard and their screen look like gibberish from the Matrix.

Support & Maintain it: It's alive!!! No really, just because you put some bug free code out in the world does not mean it stays that way. Software is exposed to lots of stuff, just like humans, it gets sick too. Keeping existing applications healthy and performing well is a giant part of the world we live in.

What kind of software? It used to be back in the day that computers were giant boxes beeping and booping, they were the huge machines that James Bond ran by when he got to the villains volcano headquarters. Now we have those things in our pockets. So what kinds of software do we deal with in 2018? There's a bunch, but for our purposes this is what we deal with mostly.

Desktop, client/server: See that thing on your desk? Cool, we're done here. Desktop applications are the classic apps that run on our PCs and lappys. They are powerful because they take advantage of harnessing the mighty processing muscle of your machine. This was pretty much the only way to use big apps like CRMs & ERPs because web browsers weren't robust enough yet, you can't drive a truck through a keyhole.

Web, browser based: It's time to make some bad ass dragon scale armor out of all those CD-ROMs, because we don't need them anymore. Now that browsers have evolved to be absolute beasts they can handle much larger applications at performance levels similar to desktop apps. Open a web browser of your choice (I'm a Chrome, Mozilla and Opera man myself) and get to work.

Mobile: Our phones are little supercomputers now and the mobile platform has gone from a "nice to have" to a "must have" for companies looking to serve their users. Nowadays we mostly have either iOS or Android devices in our pockets, if you're developing apps specifically for those Operating Systems you're doing native development. You can also use web languages and standards like HTML5 & CSS3 to write mobile apps that will look nice on both desktop and mobile screens, lots of companies do that. There is also amazing software out there like Xamarin and Ionic that let you build mobile apps at the same time you're building web apps, they're kind of like code translators that transform the code you're comfortable writing into code that plays nice on mobile too. Just ask your developer candidates or clients what route they take to build there mobile apps.

Cloud: The "Cloud" is a data center or bunch of data centers chock full of servers specially made to house and deploy software over the internet. We're experiencing a magical time as humans using software because with cloud based applications you can churn and sift through mountains of information and build really powerful stuff. Map out cancer genomes, predict the path of a hurricane, crawl all the social networks in the world to figure out that a bad person is about to do something bad. You can build your own cloud, or use a commercial service like Amazon's AWS, Microsoft's Azure or Google's cloud offerings.

Where do you put your code? Doesn't matter anymore because everyone is full stack! Actually that is far from the truth, take the time to figure out where your candidates write the most code, and salespeople need to pose the same questions to your clients.

User Interface, front-end: In my humble opinion this is the funnest layer, but then again I have the STEMS skills of a brussel sprout. The UI layer is where the user interfaces with the application, it's a combination of art, science and human psychology. The application space is wicked competitive, you can have an awesome piece of software but if people find it hard to use or it's not engaging they'll just move on to something else. Is Kylie using Snapchat again? OMG I'm losing sleep over this.

Business Logic layer, middle layer: Every company has a set of "business rules" they use to run their operations and almost every industry has their own ball of wax that's important. Healthcare, financial, industrial, retail, all have different ways they actually do business. Remember Algebra? Think back, you probably failed it and that's why you're now in IT staffing :) The biz layer is kind of like algebra, it breaks down pieces and components of the business into Objects and Classes that helps make sense of things. When you hear Object Oriented languages, these are the languages that live in the middle tier that help parse the chaos. Example: You're on a beach in Peru, buying insurance for your vacation house in Madrid Spain, and you're a resident of Dallas TX. When you "click" on that product you set the wheels in motion for a lot of "can we do that" kind of stuff. Dude is in Peru, can we originate loans there? For a house in Spain? For a citizen of Dallas? All of these things are checked out, and it happens in the fraction of a second. Some common languages you'll see in this layer are C#, Java and PHP after version 4.

Data layer, back-end: Most of the applications we're dealing with have some sort of a back-end or data base they're pulling data from. Nowadays we have the relational databases we all know well like SQL in all it's various forms, and Oracle. We also have the NoSQL back-ends that work out of the cloud dealing with mountains of data, they are set up differently than relational data bases so they can churn through tons of info. Instead of searching for the needle they can just look at the whole haystack and find it right away. It's amazing stuff, and coupled with the cloud it's where we get Machine Learning and Artificial Intelligence. Back-end engineers are special people, they make sure the application is being served data in a way that ensures top performance and stability.

Full-stack: Be careful with this one. I can tell you with a ton of confidence that all the above layers are different and they require different expertise with different technologies. I am skeptical of any developer who tells me they are equally adept at building a compelling UI as they are optimizing a back-end. The truth is developers have a deep dive into one of two of these layers, with the ability to build on the others. When I talk to full-stack devs I always want to know where there heart and expertise originated, regardless of being able to contribute production worthy code on every layer.

That's the basics...

You may notice that besides a few examples, I didn't really dig into "Are you a .NET Developer?" or anything that platform specific. That stuff is important too, but we're moving into a time where developers aren't silo'ed by particular platforms anymore. With the explosion of Open Source software and API's (Application Programming Interface), the name of the game is integration and sharing, which does make things more muddy for us recruiting people. People absolutely still identify as Java, .NET. or PHP developers, but it's better to dig into those specifics once you've laid a foundation with the above questions.

Happy hunting everybody! Hopefully this helps y'all do a better job repping your developers and building teams for your clients. It takes a village to make sure we're not just using buzz words and bullet points, nobody wins there.

*And checkout our new site!!! (I'm also looking for an Account Executive to come sell for us, ping me if you'd like to chat)