I typically ask the question “what would you build if money wasn’t an issue?”. We covered this a lot in chapter 4.
Who would your dream company be? This will start your job hunt. From there, look for competitors, or companies who do the same sorts of things. Start to narrow down where these businesses are located, how big or small are they, what/who are their customers, what kinds of job postings do you see. As you network and get to know people from the company, you can begin to ask questions about salary ranges, job titles, mentorship – all things you can’t really ask about during the interview itself.
Once you build a matrix of these kinds of attributes, you’ll have a better idea of companies you do and do not want to pursue.
In my time in the industry, I’ve summarized two business models that need software developers: those started by business majors, and those started by other engineers.
Many institutions exist in this sector: they were started by business people, led by business people, and usually cater to business people. These are often finance or insurance companies, or other industries where software simply supports an idea. The leaders' language is that of sales and marketing, and engineers are hired to build support software (ie, billing systems) or marketing web sites, and other applications that support the business idea.
My experience in these kinds of businesses is that the sales and marketing teams may set deadlines without engineering input and present work as “we promised the customer they’d have this in 3 weeks” and then watch the engineering team scurry like ants to get everything done. Smaller business-led companies have been learning things like Agile methodologies and understand that engineers need to provide input on deadlines, and thus shift away from this norm, but almost all of the business-led companies I’ve worked at have operated in a “deadlines set by non-engineers” way.
These companies often have a main product to support, which is a great place for engineers to start their career: you join the team and usually have an established code base, established work patterns, and your work day can be mostly predictable. You can grow with the company, work on new features to a product, and learn a lot from the engineers here. Often, the engineering team will create its own subculture within the company, and it can be less likely that your interviews will require time with non-engineers.
Some larger corporate companies, especially those started a long time ago, may be less flexible when it comes to exploring alternate technologies.
On the other side of this coin are businesses started by and led by other engineers. At these companies, engineering output is usually the product sold, and you’ll often find SaaS/PaaS businesses in this area, as well as consulting firms. Having engineers as leaders or founders will change a lot about the culture of the company, and they’ll often work to ensure that non-engineers hired to the company get along well with engineering.
Working for engineering-led companies usually means working on very interesting and complex problems including things like security, scalability, high-availability and more. Deadlines are usually determined with input from the developers who will be working on the project. But when deadlines are not met, leadership is usually a lot more understanding about the technical nature of roadblocks and problems along the way.
New engineers to the industry can do well starting out at engineering-led companies but I believe you’re more likely to end up in a very focused area of technology, so you will need to decide carefully if a company’s tech stack and tools match your career path.
Companies vary a lot in size, and the things that matter to them can vary just as much. Some companies will care more about culture, some will care more about optimized code, some will care more about equality and diversity. Every company will be different, but here are some generalizations I’ve made about my time in the industry.
Small companies under 50 people are usually what we call “startups” in the tech community, though some say a company is only a startup if it’s younger than 4 or 5 years as a company.
Culture is extremely important at this size, because there are so few of you in the business that nobody wants to risk awkward confrontations within the office. It’s not like you can go work on another floor in the building, or another building, or across town on the other campus, or switch to a team in another state or country…
As a business, startups usually have a lot of pressure to get things done because “time to market” is critical for them to grow their customer base. Their primary concern for you as an interview candidate is that your code can be written quickly. Sometimes they’re more forgiving on introducing small bugs if it means getting a major feature released. Unless the company is engineering-led, it’s more likely that testing and documentation are not a strong priority yet.
Since the company is small, your point of contact in the company is more likely to be a technical manager, so expect that a phone screen will become technical right away. When it comes to on-site interviews, unless the startup is involved in heavy algorithms like machine learning, AI, or Big Data, they’re likely not as concerned about highly-optimized code from an entry-level web developer.
However, in their rush to find a good candidate quickly, decision making tends to fall to hard yes/no scoring on whether you answered questions correctly and whether they want to hire you.
Smaller startups are also less likely to consider entry-level developers partly because they need experienced developers to get features released quickly. Smaller companies are aware that deadlines also mean less time for mentoring and sharing of knowledge, which makes building up an entry-level developer much harder.
For on-site interviews, startups will be looking for people with more breadth of knowledge because you’ll be expected to work in many areas of the code.
Usually around this size, companies will begin to hire someone to manage Human Resources, and offload tasks like payroll, benefits and so on to a team who can specialize in taking care of the individuals in the company.
At this size, your first point of contact may well be someone in HR who is not technical, and the first phone screen may be comprised of more career path questions, and then hand you off to a technical manager to follow up with a second phone screen. However, this size of company is still quite busy and HR will try to offload as much of the screening process from the engineering team, so the technical manager may provide some basic technical questions to ask on the initial phone screen, so you should still be prepared to talk about your project work.
As the company grows, they realize that overall code quality is much more important, and methodologies like Agile and TDD are more likely to be practiced. It’s also likely that the engineering team consists of enough senior level team members who have the time to bring on entry-level developers and provide them with a good learning and mentorship system around them.
Because HR has been introduced to the company, sometimes grading candidates is a little more flexible, and I’ve found companies are more likely to fall on a 4-point grading system:
Note that there’s no middle ground here; no opportunity to be neutral.
At this size, the engineering team may begin to split into two or more smaller teams, and you’re likely to only interview with one of those teams, which will be more specialized in their workload. This means they’ll look for less breadth of knowledge and more depth of knowledge in the areas important to the team.
At this size, the company may start to invest in recruiters who come from a strong technical background, perhaps they were developers earlier in their career. In this case, expect that your initial phone screen will be very technical in nature. You may only have one phone screen at this size of company and move straight to a homework assignment or straight to on-site interviews.
As the HR team grows, they will put a lot more care into ensuring that candidates are fairly graded against one another, and will also be putting more thought into equality and diversity within the company as a whole.
On the engineering side, the engineering team may have dedicated DevOps people, dedicated QA people, and several small engineering groups working on different parts of the code. Depending on their structure, they may expect that an entry-level developer is either strongly focused on fewer areas (less breadth, more depth), or they may desire someone with a wider set of skills to fill in some gaps on the team (more breadth than depth). You can usually discern this from the job posting.
Engineering will also care a lot more about testing and overall quality of their code, so you might expect more questions around testing. At this size, some companies also experiment with pair programming and interviews could also incorporate some aspect of pair programming as well.
Beyond 250 people, the company is usually headed for full-on corporate enterprise. They’ll have a strong team of technical recruiters handling phone screens and perhaps some of the on-site interviews to offload on-site interviews from the engineering team. You’re more likely to be asked to sign a non-disclosure agreement (discussed later).
Companies at this size have a well-established brand and growing reputation to protect, so quality code is very important to them. At this stage, they’re also going to care a lot more about optimized code and may be moving away from scripted languages and getting into compiled languages such as Go, Java and C++ for performance reasons. Because of this, they’re also more likely to hire Computer Science majors depending on the kind of applications the teams are building.
Unlike startups, who care more that your code can be written quickly, companies of this size will care that your code operates quickly. You’ll need to study up on more complex data structures and algorithms and the problem solving may be a lot more difficult at this stage.