So, you want to work in tech?

, 6,427 words

So, you want to work in tech?

I recently collated and published a set of pieces — including this one — in a short book:

So, you want to work in tech? book cover

“So, you want to work in tech?” is a guide for aspiring tech and product people, written from the best part of two decades working in tech. It covers topics including finding and winning the right role, finding a mentor, and becoming an excellent engineer. The second half of the book includes a number of helpful how-to articles, including how to get a raise and how and whether to move on.

The book is available through Amazon and iTunes.

A guide for aspiring tech & startup people

Introduction

This article is a collection of things I learned over the best part of two decades working in tech. The aim isn't to provide hard advice but rather to share experience and offer ideas for consideration. I hope it's useful in your journey.

I’ve tried to include as many insights as I could from my time as an engineer, a CTO, a tech investor, and an entrepreneur. Whist several sections are specific to would-be engineers, the piece may be useful for people going into a variety of roles.

If I had to make one recommendation to a tech person at the start of their career, it would be this:

Get a mentor. Someone who isn't at your company, but who has followed the path you seek to tread. Ask if you can buy them a coffee once a quarter for their insights. Use these meetings to hold yourself to account on your personal development.

If I was cheekily able to offer a second piece of advice, it would be this:

Don't take advice. Everyone wants to give it, but not everyone is qualified with relevant experience. Perhaps I'm not. If you do seek guidance, try to learn about people's experiences and mistakes rather than letting them tell you what to do. Read up on their backgrounds.

This guide is in the following sections:

What makes an excellent engineer?

Excellent engineers typically share three attributes: intelligence, passion, and curiosity. Just about anyone can write code, but it takes a lot of practise and thought to understand how to design and implement systems.

I particularly like curiosity as an attribute in engineers, which in part is why I tend to hire Physics or Maths graduates over Computer Science.

When an engineer's passion outweighs their curiosity, they can become more concerned about the art of writing code than about delivering value through their work.

Ability to learn quickly can decrease markedly over the age of 25, and engineers who start young tend to have an advantage over older starters. It is rare to find engineers who started coding in their early teens who aren't very capable.

Post-graduates should not be deterred. Many early starters are quite unconventional characters, and they lack soft skills or judgement required to complete the picture. Latecomers to tech may have to work harder, but the results can be as good or better.

There are few standardised systems to assessing a developer’s capabilities, and SWEBOK -- perhaps the most widely accepted -- is onerous and still all but unknown in industry. A number of companies and bloggers have built their own assessment frameworks, and of these I think the Programmer Competency Matrix is by far the best tool for the journeyman engineer.

Excellent engineers demonstrate the following:

  • A passion to always be coding.

  • Expertise across a range of languages (Paul Graham wrote about mastering Lisp) and very different systems.

  • Initiative. Learning ability on its own is not enough! Not knowing something shouldn't stop you from giving it a go with Google and StackOverflow's help.

  • A predisposition for taking things apart and putting them back together.

  • Strong communication and facilitation skills, both to explain in lay terms but also to understand what customers want.

"A very simple but particularly effective technique for finding the cause of a problem is simply to explain it to someone else."

- Andy Hunt & Dave Thomas in The Pragmatic Programmer

  • Delivery. Being able to get things done and deliver value at the end of the day. Done is better than perfect, and you should develop intuition as to which tech needs to be perfect and which doesn't.

  • The ability to learn and synthesize rapidly: novice engineers build frameworks, whereas experienced engineers find the framework they need has already been built.

  • Commitment to learning and readiness to benchmark oneself. How good are you, objectively, compared to your peers? Building a developer library is a good idea.

  • Empathy with what the business is trying to achieve. It's no good being technically brilliant if you don't understand your project's rationale. Passion for the company's vision makes it a lot easier to become a domain expert.

Readers may question the importance of being an excellent engineer rather than merely a good or average one. As Ward Cunningham's wiki rightly points out with Grand Master Programmer theory, productivity of software engineers is non-linear, and an excellent engineer is many times more productive than the median average.

"Startups are an Olympic sport and every slot on your team is critical. You wouldn’t put a "good" swimmer in a relay, would you? Don’t have one in your startup. [...] Replace them with the great."

- Jason Calacanis in The Startup Depression

Does a degree matter?

Many universities offer Computer Science courses, but it's the better and more scientific ones that offer Software Engineering. This is geared towards would-be engineers. Whilst a degree course can give candidates discipline to help them structure their thinking, it’s rare that they alone will produce expert programmers. Expert programmers are made by doing programming, and lots of it.

"Computer Science education cannot make anybody an expert programmer any more than studying brushes and pigment can make somebody an expert painter"

- Eric Raymond in The New Hacker's Dictionary

Formal education isn’t of critical importance. Engineers have never had it better, with employers worldwide wanting them. After all, software is eating the world. Even Google aren't as insistent on degrees as they were a decade ago. Courses can lag years behind industry, and getting a CS degree from a second-rate university may not be as valuable as a harder science or maths degree.

A growing number of entrepreneurs -- including me -- would like to see more diversity in tech, and this has led to the emergence of new development programmes. Makers' Academy, General Assembly, Girls Who Code, She++ and she.codes all seek to offer new routes into the skills and connections required.

Having a trade, and what employers expect

Unlike being a doctor, an airline pilot, or a civil engineer, there are no decent software industry accreditations, ongoing retesting or progression through a structure. As such, some engineers arrive in the field without understanding what it means to truly have a profession.

Continuing to learn is key. Capable, driven engineers are committed to studying and building their capabilities. This approach to continuous learning can be taken to extremes, and it can make diversity harder as it discourages other commitments. Not every employer expects this level of commitment, but it is a good way to get rewarded, and it is the norm at hard-charging companies like Apple and Amazon.

As a limited set of things to consider at the start of your career, try the following:

  • What will you be doing in five years? Ambition isn’t necessarily about wanting to be the boss or making a huge amount of money; it may be about personal development. So long as it’s measurable you can weigh up the steps to get there.

  • Code at home, on your own or on open source projects. Develop your communication, writing skills, and network in the industry by blogging about it. Otherwise in five years you'll have only picked up what you've been exposed to at work, and more passionate coders will run rings around you. Keep sharpening up.

Opinions are split on the value of code katas. One former engineer-turned-CTO shared this with me:

"A lot of people do short coding exercises, but they don't help you learn how to solve real world problems. I find it best to see out a project with goal. I built an app that monitored Amazon DVDs and tweeted if the price dropped >25%. Amazon banned me when it started making money, but that's another story! It taught me a lot about the language I used."

For my own part, I learnt by doing, making mistakes, and then getting better. Writing, hacking, building.

  • Be prepared to put the hours in. Sometimes it takes a lot longer than 9 - 5. Hopefully not routinely, but if you're watching the clock you might be missing the point.

  • There are many ways to immerse yourself in a discipline. Debating and presenting on tech is a good way to ensure you understand it well. If you can explain complex topics to others, you probably understand them. Speaking at events, engineering groups, and book clubs won't hurt.

  • Learn how the fundamentals work. Have you mastered Windows, OS X and Linux? Can you compile a kernel? Do you know how the Internet works? If you're going to be asked to write software for a platform, you better know how the platform works.

  • Being introverted and intensely technical is great, but the office is often a mixed environment. Spending time with people who are dissimilar to you, and getting practise in social situations can you help you get on. Don't be one of those creepy engineers.

Milton speaks

  • Have a look at MBTI. Even if you discard it, it might have you thinking about which interactions give and detract from your energy, and with whom and how you might work best in a team.

  • Doctors get taught how to maintain a professional appearance in their training, whereas software engineers don't. Bright blue hair isn't a problem, but not being clean and properly clothed is.

How much money should I look to earn?

Recruiters might talk about industry norms -- and it is true that there are some bands -- but engineers can earn just about anything in their first role. I've seen engineers get £18k, £30k, or even £65k, right out of school.

There are a few things to think about when considering or seeking an offer:

  • There will always be someone who will pay you more. Generally, the worse the technical environment, the more an employer will need to pay to attract and retain staff. Financial institutions, big corporations, and -- god forbid -- development agencies tend to pay a lot more than start-ups because they have to.

Beware employers who make up for lack of leadership with cash.

  • At the start of your career -- irrespective of what you're paid -- the experience you get from an excellent environment and stimulating employer will far exceed whatever they pay you. Thus, the right amount in the context of negotiation may start at whatever amount will take any immediate concerns about money off the table. A job that helps prepare and stretch you for your longer-term goals is very valuable.

  • As an engineer your value will increase so sharply in the right environment, so it is worth thinking about whether the employer has the mind-set and capability to be handing out 10 - 50% raises year on year. An employer that will track and reward your growing value year on year is a better bet than one that gives a high starting salary and measly 3% raises.

  • There's no harm in negotiation but it should always be done with grace. If a hiring manager won't play ball, it isn't necessarily an unprincipled matter: perhaps they consider it fairest to pay in parity according to experience bands.

  • Some employers may offer bonuses. These are usually discretionary and underpinned by company performance. It is important to understand whether a bonus is set with the expectation of being achieved or whether it is tied to "stretch" goals for the individual and the company.

  • Some employers may offer stock, and this usually requires more data than is available to even mid-level employees to assess the value of. Most start-up companies fail, and a sensible assumption is that the value of the stock is zero, or possibly slightly negative if it has the wrong tax structure. However, the rationale for giving stock to employees is usually around creating a shared sense of ownership, which can be a very valuable thing. There are some great resources on Mark Suster's blog and Quora.

As a hiring manager, the most attractive hiring narrative is often around unproven candidates at the start of their career -- they could become rockstars -- or around rockstars themselves, who will be extremely hard to prise away from whatever business they're in. (Rockstars are hard to hire because they're deep in the zone, and because their incumbent employers will go to great lengths to keep them.)

Watch out for getting stuck in the middle. Most commonly, engineers on the market are those with 3 - 5 years' experience. By virtue of being on the market at that stage, they show to a potential employer that they've not been able to make themselves invaluable to whichever companies got them their first years of experience.

Thus, it pays to find a company that will take you from junior to senior. If you fall out of the rocketship mid-journey, people may wonder why.

On handling recruiters

Recruiters are a mixed bunch. There are some excellent, highly professional, experienced and skilled recruiters out there. But there are also plenty of shocking ones, too, every bit as devilish as estate agents, and you need to figure out which is which. There is a very low barrier to entry to becoming a recruiter, and it may well be that some teenager is doing you a massive disservice, both in the way they’re hawking your resume around and in the way they’re negotiating on your behalf.

So long as the recruiter still gets their commission -- and the employer doesn’t mind -- you might be better off cutting them out and negotiating directly. As an employer I've been on both sides of this divide: wanting great, trusted recruiters to handle candidate negotiation for me, or using a recruiter simply because they source well, and wanting them not to get involved with the negotiation.

If a recruiter knows a candidate is job-hunting only through them, they might push them to the highest paying role, irrespective of fit. If a recruiter is competing against another to place the same candidate, they may be more likely to try and place you for best fit as early as possible.

A word of caution: recruiters usually get paid on a commission basis. They stand to gain personally from your decision, and they will earn more if you take the awful agency job rather than the start-up one. Some companies may also pay recruiters a greater percentage than others. Reflect on this when they offer their counsel!

About those TPS reports...

Your resume (or curriculum vitae)

There are many guides out there on how to write a good resume, so I'll only stress a few things from my experience.

  • Brevity counts. 2 pages at most; resumes with 4 pages tend to get rejected immediately. The last thing we want is people who can’t focus or communicate succinctly. Your summer job from 2007 is not relevant.

  • Don't mislead the reader. I've seen resumes where a candidate claims to have led a team end-to-end, but when asked how they line managed the team or what their budget was they couldn't answer.

    More than once I've interviewed someone who mentioned Java in their headline summary, but when quizzed on it they told me they'd not used it in years. Dishonest or incompetent?

  • What you did is important, but so is autonomy and business value. Pasting your former job description into a CV is a nonsense. If you have prior experience, describing the business impact of your work shows a level of awareness. Hiring managers like it when candidates can quantify their achievements: did you double traffic, or grow sign-ups 20%?

  • Depending on the role you're after, the copy on your resume and your LinkedIn profile can be identical. It's nice to prepare a distinct CV, though, rather than just exporting your profile to a PDF. If you're looking at a set of roles with quite different responsibilities, it can pay to prepare a different resume for each.

  • Include links to your GitHub account and blog. If your GitHub is empty -- or only has forks -- you might not be ready.

  • Universities rarely fail idle candidates but instead award them a 2:2. Those with such a score might be well advised not draw attention to it.

Where to look for a job?

Despite my caveats on recruiters, a good agency is hard to beat.

LinkedIn works well to find and research hiring companies, and there are some online communities for recruitment, most notably Facebook's London Tech Startup Jobs group.

Beware of investing too much time into new recruitment tools; they're two-a-penny, have a very fragmented user-base, and rarely have traction. As a case in point, LinkedIn has 414m users and works fairly well, at least in terms of getting enough applicants. StackOverflow looks great but rarely gets more than a handful. StackOverflow's 4m users isn't enough by an order of magnitude -- and they're considered successful!

Taking a more direct approach can pay off, too. Does the company have any open source projects that you could make good contributions to, or build functionality around? That is a great way to get noticed.

Interview preparation

Sometimes we'll be asked by a candidate if there's anything special they should prepare for an interview; we always respond to come expecting a typical interview. That's not to say no preparation is required.

Ensuring an interview is successful is not hard, and preparation lies at the heart of it. Most candidates seem to get this simple bit badly wrong. If you're only interviewing for a few roles -- the ones you want most -- then putting in some hours' preparation should be both a good investment and a bit of fun. Going to an interview that you have not prepared for is a waste of time.

An employer may give some leeway for "nerves" if you perform poorly during an interview, but generally one assumes that a candidate will be at their best and will put in the most effort during an interview. If a candidate doesn't bother to prepare for an interview they're unlikely to act with much diligence in the role.

If you're worried about the amount of time it takes to prepare or complete tests for interviews, you might not be focussed enough. Don't waste time on interview for jobs that you wouldn't love. The right role will change your life: looking at roles which are merely OK is a waste of time.

Different companies do interviews in different ways, but in my experience they tend not to need much technical preparation. Where we set a practical, technical test, we may try and do it in a language that you've not used before. The point is to test your smarts and ability to grasp the concepts of a new language. Perhaps we'll get you to explain a few concepts on a whiteboard.

The preparation that does count is on the company and their product. As a candidate, I never went to an interview where I hadn't prepared a report or understood the company's background and mission. The reports comprised what I thought of the product, how I could improve it, what I found trying to take it apart, and where the bugs or likely security flaws are. Even as a CTO, when I would meet CEOs for coffee to talk roles, I still took a report along with me on what I'd found on their product from the outside.

You likely had to do homework for at least 15 years of your education, and in hindsight it probably didn't matter too much. This time it does.

Do your homework before the interview, it is too late afterwards.

The interview

The pre-screening or tests probably show the employer you’re smart. So if you fail a face-to-face interview it is probably because there's a values or attitude mismatch.

Your manners in the interview reflect on your attitude:

  • Don't be late, but don't be the nuisance who is twenty minutes early.

  • Dress appropriately. That probably means not wearing a tie if you're seeing a startup.

  • Let your behaviour show that you're organised: don't sling your bag on the table and drag out a sheaf of dog-eared papers. Bring a notepad and a pen, ideally with a pre-prepared list of questions.

  • Try not to offer a sticky handshake. Read up on how to do it.

Interviewing with the Bobs

At Reincubate we have an internal recruitment guide which lists red flags and positive indicators for a candidate. In particular, candidates asking sensible questions is a great indicator of the right sort of person.

  • "What does success in this role look like? What would I need to do to exceed your expectations?". Write down the answer to this one, so that you can check up at quarterly intervals and see if you're doing it.

  • Tell the interviewer if you have a plan for your career. They want to know what you want. If you're ambitious, don't be scared to show it. It’s fine to be focused: if you want to stay acutely technical and not manage people or projects, that’s fine, too.

I love it when gradate engineers tell me they want my job in a few years. Great, I'm on a journey, too. You excel to the point where you can do my job better than I can, and that'll free me to step up and on. Let's go!

  • Asking about a typical day, and what the projects would be like is a good sign of curiosity. An interest in the working environment suggests the candidate has put thought into working at the company.

Boldness is good, but naivety isn’t. For instance, jumping on a plane to interview isn’t a bad thing. But showing that you might be willing to take a job without digging into what you'd be doing tomorrow suggests poor judgement.

  • Asking for feedback at the end of the interview is a sign of clear-thinking initiative: “How did I get on? Do you have any concerns about my fit?”, although it may open up the candidate to frank feedback. This is much better than the platitudinous question of "what is the next stage in this process", which usually belies the fact that the interviewers have already made a decision.

  • Show a sense of awareness and be respectful to any reception or door staff on the way. True story: don't refer to the warehouse team as "builders" or "manufacturing people"!

Samir and Michael from Office Space

Getting people and culture right is a very important part of a CEO's role, and up to the first 50 people or so many CEOs stay involved. If you're interviewing at a smallish startup and the CEO isn't there, you might reasonably wonder why.

If you can't answer a question at an interview, don't try and bluff it. Either you understand the concept or you don’t. Not knowing something is probably not the end of the world, and the hiring manager may be trying to find the edges of your knowledge. One of our core values at Reincubate is "no bullshit", but it doesn't have to be a company value for it to piss off interviewers.

The interview bullshit translator

In the course of interviewing hundreds of engineers at the companies I've run or worked at, I've heard all sorts of daft comments from candidates. Here are some things I've heard which candidates probably didn't think were so bad.

What you say | What we hear -------------|--------------- I’ve started a really cool app, but it’s not finished so I don't have a portfolio. | I am a fiddler, not a finisher: a 9-to-5 technology tourist who wants you to pay me to ride on your tour. I could easily have built stuff, blogged, or spoken at an event, as none of these things take a genius, but I’m just not driven. I've not used design patterns as my current company doesn't or it wasn't on my course. | I’m too feckless to learn at home and I use lazy excuses. I tried to get my current employer to use design patterns but the senior engineers refuse. | I'm not structured, persistent or driven enough to present and convincingly argue for change. Hire me and I'll never evolve your stack. I want to use the latest technologies all the time. | I am swayed by what's cool over what works, and I am not disciplined. I never saw that MongoDB video. I'd rate myself at 9/10; I'll have to move to management in a few years. | I've not taken the time to study and reflect on what it means to be an excellent engineer. Hello, Dunning-Kruger! My last boss / company wasn’t very good / was a thief / fell out with me. | My last employer or I have issues. They could be mine, and I might be badmouthing you in six months. I had more than a year’s service and was made redundant, although there are others in the same role who weren't. | Perhaps I was genuinely unlucky, but either I was last in or it was perceived I contributed less value than my peers. My career path could be anything: development manager, architect, tech lead, project manager, BA. | I'm not into my work enough to commit to any particular part of it. I’ll cruise along and will probably do whatever has the best pay/work ratio.

Don’t accept any job

Engineers are highly sought after, and with even a modicum of talent, employers will fight over you. Of course, excellent employers are relatively few and far between.

The trick isn't to get hired. It is to get hired by the right people. How to find them?

Milton and his cake

There are all sorts of environmental benefits one might want from an employer. I'd suggest there are a few extra things to consider.

  • It is a company that is enabled by tech, or is it a tech company? In other words, do the executives recognise whether or not technology should be a core competency in the business? If they feel it is not a tech company, are you happy with what that entails: tech being a second class citizen in the business. That isn't necessarily a bad thing, but companies like this feel and act distinctly to non-tech companies.

  • If the company is a tech company, do they have the core competencies that they need to have? This probably means an experienced technical co-founder. Startup tech companies that do not have technical expertise at a senior level do not succeed.

  • Your boss is very important. Will they get you to the next level of your personal development? Have they done something you'd like to do, are they heading in your direction? Are they passionate and committed, and do they inspire you? What is their background, and do they have experience managing people? Could they act as a mentor, and can you learn a lot from them? Could you imagine your boss being threatened by your performance? Might they be a useful contact or friend in a decade? A good or bad boss will make or break your career; they say people work for bosses, not companies.

  • If you're being hired as the best engineer at a company, think carefully about what that means. There’s a good chance you’ll become most senior in the tech structure, which could mean you’re managing, recruiting and mentoring, not being technical. And you might not be very good at that. Who will mentor you to develop your technical skills -- will the company support you in finding an external mentor? If they're hiring in someone above you, are you confident in their ability to find and attract the right person -- and why don't they have them already?

Progressing up the tech hierarchy through a vacuum in tech skills at a company is easy but not fulfilling, and will not translate to success at other companies.

At the interview, the the Bobs
  • Does the company have a clear vision and a set of values? Are these the right values for you, and do the hiring manager and team appear to embody these values? A good interviewee question to ask during an interview is "What are the characteristics of people who have succeeded at yourco?". It helps identify how deeply the company have thought through their values, what makes their culture and team work, and what they're really looking for.

Assessing a company's financial performance isn't too hard, with tools like Mattermark, Crunchbase or DueDil. However, these tools can be meaningless for small companies, and the financial data can be hard to interpret.

At Reincubate we document our recruitment process and record a set of metrics around candidate performance, such that we can readily score new candidates as we see them. This means that where we have a lot of benchmark data on a role, we can hire good candidates on the spot in the interview. Many well structured or fast growth business do this, but if it's a new type of role or an unusual one, the process might move more slowly without benchmarking data.

Finding the right environment

Beyond the considerations in the prior section on potential bosses and companies, it is worth reflecting on the environment that the engineers have in a company that you might work for. Not everyone feels the same way about what it is important, but there are some generalities. When I made the transition to being a CTO and then CEO, I spent a lot of time thinking about the sort of environment I wanted to create for my teams.

Here's what I particularly care about at Reincubate, and perhaps you might, too:

  • Flexible hours. In most teams I've been in, the engineers at earlier stages of their careers like to get in as late as possible. When they come to have families, flexible hours and often earlier starts work better. This led to our 10am - 4pm core hours policy.

  • Regular, structured, value-based, bidirectional feedback. I remember during one of my first annual appraisals as an engineer, I was upset that my boss didn't score me for "exceptional" performance. I asked him why, and his nonsense response was he would have done, but that I didn't ask him to. This is why we run quarterly appraisals, where everyone is assessed against the company values -- including our "no bullshit" value. It's also why, in 1:1s, our managers ask how we can create a better environment.

  • Management with technical or product experience. I never got on with bosses who didn't understand tech or who didn't build things. Managers who were just in it for the money turned me off. Our board and management team have all worked as development or product managers, and have all built tech products in one way or another.

  • Good chairs, many big monitors, and whiteboards to scribble on. I spent almost all of my time as an engineer sitting, peering at screens. Making the sitting easier or the screens better pays off, and having to argue with facilities to get a decent chair is demotivating. Don't constrain yourself with two poky screens. This is why we let the team choose whatever kit they want. Aeron chairs and three screens to a computer is commonplace.

  • Opportunity for downtime. It's a tough one to balance, but after being in the zone for hours, it's good to have some sort of break. That's why we issue new starters with nerf guns, and the office is full of toys. We had a company holiday together in 2013, and since then we've run quarterly celebrations when we hit targets. Our teams get over the average number of paid holidays. It's also why we encourage the team to pick a different challenge to work on over Friday afternoons.

Time for printer payback

  • Easy commute. It doesn't work for everyone, but I've already done my time with long commutes. We've chosen offices that are central and well-connected by underground, bus, and cycle path, so that it's as easy as possible to get in without needing to relocate.

  • Natural light and a healthy environment. Having spent time working in basements, old houses, and converted warehouses, I came to see how important natural light is for one's mental health and productivity. Our London office is in a sub-penthouse with big windows on 3 sides.

  • Free food in the office. Having put enough money into other peoples' vending machines, I wanted an office that has free food and drink. This is why the offices are filled with fruit, snacks, soft drink, beer and wine. We take the whole team out for lunch every Friday (they vote for where) and the company buys dinner if people work late.

  • Private medical insurance. Early in my career I became seriously ill and was hospitalised for a fortnight. The NHS is great, but I spent two weeks stuck in a grim Victorian respiratory ward. Private healthcare can make a big difference, and we offer it freely to all.

  • Colleagues who are like-minded about learning. Some companies might hire acutely technical assholes, but we won't. We support this in our team with time off for events, building a shared learning library, arranging training, brown-bag sessions, inbound and outbound mentoring, and hosting speakers in our boardroom.

  • Colleagues with diverse backgrounds. We have quite a diverse team, and we're working to make it more so as we develop the company's culture and our recruitment processes.

Which other things matter? Let me know.

After the interview / how to start

If you don't get the role, ask for feedback. If you do get the role, and you can get time, reach out before you're due to start to ask whether there's any preparatory work you can be doing. Give yourself an advantage.

Finally, the most important bit, and the reason they hired you:

It's not about what code you can write, or how well you write it: it is about how you can add value. If you're lazy or inexperienced you won't know what to do other than code, but that's not the point.

Do you know how to tie your work to the company's success, such that you can do the former and have it lead to more of the latter?

That's all any employer wants of you. Create success, then go home.

The two Bobs

Don't forget to bring your notepad for day 1!

Bonus "how to" guides

I've written a number of additional guides for new starters:

Afterword

Tips from Bill Lumbergh

I loved my time as an engineer, and whilst I don't get to write a lot of code these days, I still get to immerse myself in the broader entrepreneurial challenge of creating tech products.

At my company, Reincubate, three of the company's five core values pertain to what makes engineers great: no bullshit, a commitment to personal and team growth, and a passion for well-designed tech products.

I enjoy meeting and hearing from people who get excited about building things. If you have an opinion to share or are looking to get into the industry, drop me a tweet for an invitation to one of our Friday London team lunches.

If you can help me improve this guide with a correction or a suggestion, please reach out.

In preparing this article I shared it with a number of CTOs and entrepreneurs who were kind enough to send feedback. Thanks Andy Coles, Matt Collins, James Crowley, Matthew Dalton, Andrew Dancy, Jason Duffett, Dan Glyde, Sandi MacPherson, Scott Millett, David Santoro and Dan Quine. Images in the article are from Office Space.

April 2016 update: This article and some others I've written appear in a short book, "So, you want to work in tech?". The book is available on iTunes (free) and Amazon (paid).

So you want to work in tech? the book