Alright, so the last post generated some good conversations about the things Millenials are facing that we crusty old Gen-Xers couldn't possibly understand. It turns out, life is hard. And you don't get to do what you want.
It's ... It's just so hard, you know?
And also, there are like 10 times as many people competing for the shitty entry-level jobs than I had to deal with, and it's a different world. So I'll put away my snark and talk turkey and maybe help some people instead of making fun of them.
Nota Bene: The following tips are entirely about finding work in the technical industry of the United States. It should be noted this is a US-centric post. I live here, I work here, I've worked here all my life. These tips might be able to be adapted to other cultures, but they might not work that way at all in the many, many places I've never been.
I should probably also mention I'm a good-looking able-bodied white male in my 40s overflowing with self-confidence and charisma. I have a midwestern accent that makes people trust me subconsciously, and I've played this game for years. I know the keywords to say in the interview to look like I'm what they need for the job, and I play on that without remorse.
In other words, I have some native characteristics that, frankly, make the things I'm going to talk about a lot easier for me than if I were a woman, or if I had an appreciable amount of melanin in my system. This shit I'm about to lay on you will not work for everyone, and it's not fair, and I get that. I'm not saying you have to be a white American man to get a benefit from these tips, but you should totally take that into account when looking for ways to apply this stuff to your situation.
On with the tippage!
First things first: Know What the Tech Industry Does
The technical industry in the United States is based on hardware and software solution development. The key word is "solution." Solutions are not necessary when things are cool and working well. Solutions are about solving problems.
All projects that pay techies money are designed to solve a problem. You must understand this fundamentally before you even consider applying for a tech job. There will be problems, and you will be working with a team to come up with a solution. If you don't want a job with problems, the tech industry is not for you. Some might say "jobs" are also not for you, but not someone who has put their snark away, that's for sure.
All solutions, whether hardware or software based, have two basic phases. In the first phase, the solution is developed. In the second phase, the developed solution is released to the people whose problems are being solved. Solutions are the "products" created by techies.
When the solution is being developed, it is generally referred to as being "in development." When it is released to the users, it is generally referred to as being "in production." This is because the second word in Technical Industry is still Industry, and the industrial revolution has shaped how we think about what work is all about. Most of the shit we do is shaped by 19th century thinking. Never forget that, because otherwise you'll never understand why you have to go to a building to do a job you literally use laptops for that you can do from home over the internet in the 21st century.
The Development Lifecycle
The development of a successful solution follows a process. This process is called the "development lifecycle." All development lifecycles will consist of gathering requirements, developing a product that meets those requirements, testing the product, deploying the product, and training the users.
People have been documenting different ways to approach the development lifecycle for years and years. Wikipedia is an excellent resource to learn the differences between approaches. You want to look up things like RUP, Waterfall, and Agile. Agile development is really popular right now, because it sounds like it's flexible and efficient and it promises to pump out solutions quickly, without spending a lot of time on things like ... documentation.
If you know anything about Total Quality Management from the 1980s, try really hard not to mention to anyone telling you about the latest form of development being implemented at your company, "Oh, it's TQM in different words! Why not just call it TQM?" They will give you the hairy eyeball, and pass you over for promotions.
Keeping silent is a big part of being a Techie.
Besides, it doesn't matter what form of development your company is using. No one follows the prescribed processes literally anyway. It's really more of a set of guiding principles. The only time you'll need to know anything about these phases is when you're being interviewed, because HR and Management tend to think everyone is actually using the techniques they spent so much money implementing to improve the design process.
Wikipedia will tell you all the right buzzwords, but remember, it's just gathering requirements, developing the product that meets the requirements, testing it to prove it works, deployment, and training users. Common sense, when you think about it.
Requirements
Identifying the requirements is the most important part of the process. Requirements give you a list of things the product has to be able to do. They tell the developers what to develop. They give you a list of things to test when you're done developing. They give you a list of things to document, and an outline for your training presentation. They guide the entire development process, and ensure the users end up with what they actually need to solve their problems, instead of yet another thing that doesn't work.
Requirements development also takes place in phases. You may begin to see a trend here. Pay no attention to the phase trend, the trend seeing phase is just a phase. You'll soon get tired of seeing trends, and move on to the next phase, apathy. But let's get back to the first phase of requirements generation.
The first set of requirements is created by the Project Manager and the Business Lead. The Business Lead is a middle-level manager ("Vice President") who is either directly or indirectly faced with the business problem that requires the technical solution. The Project Manager is in charge of interviewing the Business Lead, identifying the things that the product should do, and creating a list of these requirements. This list is called the "Business Requirements," and it is reviewed and approved by the Business Lead. In well-run organizations, the Business Requirements are numbered to enable you to track each aspect of development, testing, and deployment to one of the Business Requirements.
The Project Manager then takes the list of Business Requirements to the Technical Lead. Together they take the input from the Business Lead and identify ways a technical solution can meet the business requirements. They translate the stupid vaporous general requests from the Business Lead into technical language that a developer can understand. This becomes the "Detailed Requirements" or "Technical Specifications." Any similarities between the Business Requirements and the Technical Requirements beyond the numbers is purely coincidental, and probably indicates the ink on the Project Manager's PMI Certification is still warm from the laser printer.
The Technical Lead then takes this list to the Developers, and may send a copy to the Quality Assurance (QA) team that will be responsible for testing the product before deploying the product.
Project Managers usually spend a great deal of time developing Change Control Procedures to ensure that any changes to the requirements are documented, discussed, and distributed to all team members regularly. Meetings are held weekly for approximately one week, at which point all changes to requirements are documented in emails between the Business Lead and Project Managers. Sometimes they let the developers and testers know about these changes, but usually not until after the previous version of requirements has been met.
Product Development
Developing the product or code that meets the requirements is the next step. Products are considered "in development" when the requirements have been turned over to the developers, and they begin to create the product that meets the Technical requirements in an attempt to solve the problem the Project Managers understood the Business Leads to have, which may or may not be related to the actual end-users' experience, interest, or job description.
IT Products are developed in a "Development Environment." This refers to a simulated mockery of the systems, resources, data, and equipment that the end user will be expected to have at their fingertips while using the product. Note: The end user will access the product in a "Production Environment." The Development Environment will resemble the Production Environment in exactly the same way as the Technical Requirements resemble the Business Requirements. Any similarities are highly discouraged and will be noted as a waste of resources during the Budget Planning phase in the third quarter of the fiscal year.
The bulk of "development" is usually done the morning of the release, to the angst and chagrin of the testers, trainers, and ultimately the end users, though they usually don't know why the products aren't doing what they are supposed to do. This is known as a "production issue."
Developers: Some Notes
To understand the development process, some attention should be paid to the actual developers. They are a rare breed. They are highly trained in using Google to look up code snippets that sort of do what they think the Technical Requirements are talking about, and are therefore very expensive. Due to their high price tag, no project actually hires enough developers to code their project, which tends to put them under a great deal of pressure to develop working code in impossible time frames, leaving them cranky and bitter.
Because they are often under a lot of pressure and time constraints, Developers can't be bothered to use whole words, unless it confuses their audience. For example, they will refer to the Development and Production environments as "Dev" and "Prod." They will use inappropriate acronyms to refer to every part of their project, often in ways that make obscure references to science fiction plots written by Joss Whedon and Stephen Moffet that no one gets but themselves.
The stereotype of the code monkey who runs on various forms of caffienated products and Cheetos is demeaning and rude. Do not bring them Mountain Dew and Cheetos and expect them to be pleased, or to get your project bumped up in priority. They are bitter, angry and far too strung out on caffeine and undernourished as a result of their Cheeto, Ramen, and Pocky based diet to even think it's funny. But leave the Mountain Dew and Cheetos anyway.
Testing
While the Dev team is working on the code, the Quality Assurance (QA) team is putting together the Testing materials. These consist of a Test Plan, Test Cases, and Use Cases. The Test Plan discusses how testing will be done, and identifies the process of pointing out the Developers have totally missed the point of the Requirements. This document is then sent to all members of the Project. Next they develop Test Cases, Use Cases, and occasionally the Test Scripts. These artifacts are designed to list all the steps that are necessary to see if the Requirements are being met.
When the Developers are finished creating the code to (ha ha) spec, they load it into a Test Environment that is somewhere between the Dev and Prod Environments. Theoretically, the Test Environment is an exact duplicate of the Prod environment, but that costs a lot of money and, in Health Care and Banking industries, breaks several laws and exposes the corporate executives to "Risk."
Risk is bad, and several organizations have "Risk Managers" who create mitigation controls and policies that usually turn into mandatory training videos that have to be taken on a quarterly basis. To all tech workers lower than middle management, these are known collectively as "A Huge Fucking Waste of Time."
When the code is loaded to the Test Environment, the QA department pretends they are the Users, and checks to see if the product does what they think the product is supposed to do based on the conflicting documentation they received from the Technical Lead and the Business Lead. When it doesn't work, they write up "Bug" descriptions and submit them to the Dev team. If the Dev team is not ingenuous enough to find a way to blame the QA team for testing the product wrong, they are forced to "fix" the code and redeploy it to the Test environment.
This process repeats until the code does what the QA test says it's supposed to do, or until the Technical Lead changes the Requirements to match the code.
QA teams are notorious for complaining about how the Business Requirements don't match the Technical Requirements, and that the Dev and Test environments don't match Production, and that deploying the code will probably break all the dependent processes on the network.
Nobody likes the QA department.
Training
When QA has determined the product has passed all the requirements, or have quit in disgust and gone on to other companies that promise this time it will be different, it's time to unveil the finished product to the Users, and teach them how the product will solve their business problem. This is usually done at a "Brown Bag Session," at which you are expected to bring your lunch to the conference room and eat quietly while you're being trained so you don't lose production time.
Training is based on the requirements documentation, and includes step-by-step instructions in how to use the product to perform each task represented by each requirement. Screenshots of the software are often included, but are usually based on early Dev works in process, and bear more resemblance to PowerPoint mockups than anything the user will ultimately see.
By the time the product has made it through development and testing, it seldom resembles anything even remotely related to anything the target audience actually does on a daily basis. Users are surprisingly not interested in learning new ways to do things that do not actually solve any problems, and so have few questions when the last slide is presented.
That is ok, as you will see when we get to the Production Phase.
Deployment
After the product has been developed and tested, and the users have been trained, the product itself is released into Production. This process is a cleverly orchestrated routine led by the few technical people in the organization that understand how computers really work.
This is the only process that regularly goes well, and chances are it's because the system administrators (don't worry, if you're not one it doesn't matter if you know what they do; think of them as wizards who make everything better because they can tell management "no, computers don't do that" and are not fired) have set up a sequestered part of the network where the stitched-together shambling corpse of a product can be dumped without it infecting anything else.
The Production Phase
After products have been deployed, they are considered to be "in production." This does not mean they are being used, it simply means they are not being developed or tested at the moment.
The first few weeks after deployment are exciting times. The Project Manager, Business, and Technical Leads have all been assigned new projects, and the product maintenance has been dumped on someone's lap while they were on vacation. As a result, no one really knows who to contact if something goes wrong.
The Development team can't wait to hear how great their product is at solving the business problem. The remnants of the QA team can't wait to see the product fail miserably. The Users are all hoping no one really expected them to be paying attention at training.
Eventually, however, someone tries to use the product. This begins the Product Maintenance cycle. Typically, a User tries to Use the Product, and it Doesn't Work. They then contact the Help Desk, who have never even heard of that Product before. They begin the task of tracking down the Product, its developers, and the primary support contact, who has since gotten back from vacation.
The Support Contact is usually not in a very good mood. They have usually spent less time familiarizing themselves with the new product than they have spent trying to get the product to be someone else's responsibility, but everyone else has hidden their vacation schedules from the shared calendar. As a result, when a User finally gets through to them, they are surly, confused, and not very happy. The User attempts to explain what the product is, what it's supposed to do, and what aspect of that is not working.
The Support Contact then tracks down the Business and Technical Leads, who direct him hastily to the development team member who worked on the project before getting back to their current priority project. Eventually the User gets to speak with the Developer, who finally gets to see what the problem really is, and how to fix it. They then contact one of their friends in QA, explain what it's supposed to actually do, and let them know they need it tested. The QA person contacts the User and asks them to make sure the product does what it's supposed to. Everyone signs off on it, and the updated version is released to production.
This may repeat as additional features are accessed by the User.
Ok, so ... you said Tips and ... something something Tech Jobs?
Well noted, awesome reader, you remembered! Also, well done reading this much in one sitting. Please comment "gloat" on FaceBook's comments to claim your gloat prize, which is the warm feeling you get from being in on the joke.
Vocabulary Matters
I didn't think the overview of the Tech Industry in America would take so damned long, but really understanding this thing is key to getting these jobs. You need to get the vocabulary that will get you hired, and to get the vocab, you need to understand the process of tech projects. Google software development lifecycle (SDLC) and read all the Wikipedia results you find, click links to specific types. Study Agile, RUP, Waterfall. Know them well, and learn the keywords.
Pepper your resume with keywords from each phase of development. Design, architect, develop, requirements, testing, QA/QC, monitoring and control, etc. Sound like you know what you're talking about, tell the story in your resume about how you know this shit like the back of your hand. This is going to get you into the interview.
Show at least two years of relevant experience in each phase of development on your resume. If you can't make your actual experience sound like SDLC phases, study SDLC more and get creative interpreting your old jobs or college projects. You've done all that shit at some point, you just didn't realize you were doing it. Just make sure your references will back you up on anything you claim you did.
As you can see, the Tech Industry is a mess. As a result, there is a high turnover rate. This results in a lot of pretty good-paying jobs almost always being open somewhere, often somewhere nearby. Most companies go through temp staffing agencies. Most tech temp staffing agencies use Dice.com to find potential matches. Most jobs are not posted to Dice. Don't bother applying to posted jobs, spend your time reviewing job requirements for common keywords, and making sure those are in your resume. Update your resume and your profile on Dice, and let the recruiters contact you. Update your resume on Dice daily, so it always shows up in the "just updated" list. All you have to do is make one change to the resume and save it an upload it to get to the top of the line.
Don't work with any contracting company whose representative's accent is so bad you can't understand it. Only go with contracting companies who represent direct clients. The fewer parasites between you and the people you're working with, the more money you get to keep.
Always ask for $100 an hour when they ask what you're looking to make. They'll laugh. Don't laugh with them. Wait a sec, then ask what they were looking to pay. They get serious then. Whatever they say, you say you were looking to make $10 more an hour. They'll come back with something more serious, and you can take that, as long as they pay overtime. If they don't pay overtime, get no less than $5 more an hour than what they offered, and say the magic word "firm." They'll say, "I'll submit you at that, but it's a little high, will you be open to negotiating if they come back with something lower?" You'll say, no, that's my rate, and they'll come back with something less anyway. They always do. At that point, tell them you'll interview and discuss rates after if you like the job.
Study the job req, and grill the representative. Ask what they know about the job, get as many details as you can so you can build your story for the interview. If your resume doesn't have the keywords of the job description, add them, and then update your resume online and with the recruiter.
Interviewing
Go in a suit. Look better than they do. If they say something implying you're overdressed, smile big and say, "of course I overdressed, I want to get an offer here!" No commitment, and they'll laugh, and see you're ambitious.
Look at them. Keep a blank expression when they are speaking, but make eye contact, or watch their lips while they speak. Show attentiveness, but let them project their desires onto you. Reflect their desires. Don't laugh unless they do first.
Let them ask a couple questions, nod a bit, answer them using the keywords from your research and their job requirements at a really high level, then say something like, "But what is it you're looking for now? What's the project?" Then let them tell you everything they want to hear.
Smile when they say something you recognize, wrinkle your forehead when they say something is stressful, or if they aren't being clear in their description of the project.
Interview them. You need to know what SDLC they use, where they're at in the project lifecycle, how many resources are assigned, and what they expect you to do. You need to know who the users or audience are going to be. You need to know deadlines, constraints, and if there are any potential roadblocks.
Nod and go, "mhmm" when they answer.
If you really understand what I wrote about above, you'll be able to turn the interview around. If they are concerned about your experience, tell them what you haven't done you'll Google. Tech jobs almost always consist of being really good at using Google to find other people who solved similar solutions and posted it publicly so everyone can see how cool they are. Your interviewers are doing this too, they'll want to know you know how to do that.
If they ask about a certification, tell them you're thinking about getting one. Know which MSDN certification applies to your job before you go, and be ready to say you were looking at it, but aren't sure the value of the cert is worth the money it costs when you've been doing this for so long anyway.
Specialize Generally
Be really good at a lot of things. Know the whole cycle, intimately. Every time someone at your new job asks you to do something new, smile and say yes early in your career. Do the shit work cheerfully. Learn something about process flows, spreadsheets, word documents, database management, and SQL queries. Learn how to code a web site in HTML, be able to put text and graphics together in meaningful ways as soon as possible.
Experiment with every program you're given to use. Explore tool bars and hidden menus. Lookup keyboard shortcuts. You never know when being able to right-click will make you look awesome.
Being familiar with everything is great, but eventually you'll want to start to specialize. Pick a niche and go with it. Microsoft products are used everywhere, and if you know how to code in VBA, you can do amazing things with it, for example. Get certified when you can afford it.
Aim Realistically
Starting from scratch, you won't make 6 figures. Figure you'll make $35-50k a year your first three years, tops. After 5, you should be making 50-65k regularly. After 10, over 6 figures. If you're not, you didn't specialize enough. Data architecture is easy, and ubiquitous, and it pays well. Specialize in that if you haven't picked something by now.
Be Positive for Positive Results
Smile a lot. Don't complain or engage in the snark I did above, except at lunch when no one can hear you. Don't bitch, don't backstab, don't complain. Show up on time to work, leave your personal problems at the door, and don't be dramatic. Be agreeable. Do your best. Be calm under pressure.
