There you are, in front of a powerful CTO heading one of the best 'we-will-disturb-the-market' startups in town. You answered a job offer which promised money and glory - and soon it'll all be yours.
To warm you up, the mighty CTO asks you to draw a B-Tree on the shiny whiteboard. Easy peasy! So you draw the tree you saw in the garden today. Then he gives you a sheet of paper, another test of your "skills". You've got to write the code for a complete chess application on this piece of paper (AI included), and you only have five hours.
After you complete the task, he asks you some questions relative to the business. This is about as useful as explaining how to compute the Fibonacci number in Lisp with recursive procedures and an iterative process.
Finally, he asks if you have any questions for him.
You look at him like a cow looks at a train. Your brain is damaged, the meeting room feels like a dungeon where the worst tortures are given. You're empty and soulless. So you leave the meeting as fast as you can, secretly wishing for your favourite teddy bear, and feeling like a fraud.
Does this sound like something you've been through? Some companies have illogical hiring policies. Personally, I've worked for six different companies over the last eight years and been through a lot of interviews.
Instead of writing another blog post about nailing all the random tests to ensure a job at X company, I'll instead show you how to judge if a company is a good fit for you. Here's a hint: the one which asks you to solve tricky tests from MIT is not necessarily the best.
1. Gather as much information as you can
What is this company is about? Is it worth applying for the job ? These are the first questions you need to ask yourself.
For a long time I felt so inexperienced that I was applying to everything and anything. 90% of the time the result was disappointment.
The Software Developer job offer
What's written on the offer will tell you a lot about the company behind it.
Is it promising glory, money and fame at the best workplace ever? Does their honesty strike you, not trying to hide the problems they face?
A lot of offers look too good to be true. If you have any doubts, write them an email and try to learn more about these "incredible opportunities" and "otherworldly advantages".
Do they require the candidate to be proficient in multiple fields (backend, frontend, devops, making coffee)? I would avoid these types unless you're well aware of the burnout risks associated with taking care of everything.
See if the offer stays consistent with the business model of the company.
And be careful of unrealistic offers which try to sell you unicorns and rainbows.
The company's image and business model
If the job offer looks attractive enough, the next step would be to check the company's website. Ask yourself these questions:
Do you like the way they present themselves?
Do you understand their business model?
Do you understand who their users are? Who their target market is?
Example: you see a job advertisement on the Internet and you go to the company's website. If you don't understand who they are trying to target or even what they are doing, chances are their customers don't either.
It depends on their business model as well. If they are in a very specific market niche, you might not have the domain knowledge to understand what they're up to.
Besides that, if it looks confusing, take it as a sign:
They don't know how to market themselves. A small company might not survive very long with bad marketing, and an out-of-shape startup is going to be stressful, there will be a lot of extra pressure to perform and get results.
If the company's way of marketing the product seems irrational, it's going to be the same for internal management decisions.
Preparing for the interview
If the company still looks interesting for you, you can send your CV and your Github / Gitlab / Bitbucket account to show concretely that yes, you know how to code.
If they answer positively, you'll need to:
1. Get even more information about the company so you understand clearly what you're stepping into. 2. Have questions. No need to memorise them, write them on a sheet of paper and bring them to the interview. 3. Write down your expectations for the job and company:
How much do you want to earn? Don't hesitate to ask for more. Nobody will stop the interview because you ask for too much. Worst case, they'll negotiate with you.
What position you would like to have?
What do you want to learn?
4. If they don't tell you in the screening call, it's best to ask them what the coding test will be and how long it will take before you can sit an interview.
2. Software job interview: A constructive exchange
The company accepted to meet you in their super cool startup office with, of course, a fridge full of energy drinks. Your dream come true!
Evaluating the company you're applying to
The interview is a really important step for you and your potential future employer. Don’t see the process as a powerful and attractive company judging a poor and weak developer (you). The interview should be first and foremost an equal exchange.
The crude reality is: You searched for a company to expand your skills and to reach your middle and long term goals with a decent salary. While the company searches for a developer who can bring knowledge, ideas and skills to add business value.
If you give them something (time, knowledge, skill), they need to give you what you want in return. Evaluate them as much as they try to evaluate you.
So if they don't provide satisfying answers and only try to test your skill and knowledge, I would advise walking away. Here's why:
You probably won't be happy working for a company who can't answer your initial questions.
If they don’t want to listen to you during an interview, they won’t do it when you're an employee. Trust me, you don’t want to be a brainless code monkey for 8 hours a day.
How is the company managed?
The interview will give you some clues about the CTO / COO / CEO of the company:
Do they look friendly to you? Consistent in their ideas?
Do they ask you to respect the deadlines whatever the cost?
Do they ask if you are ready to work on weekends?
The two last indications are obviously pretty bad: even though I worked way more than 10 hours a day in the beginning of my career, it’s not the path to follow. You'll do more harm than good in your codebase and you'll risk burning out.
If they don't bring it up, take a moment to tell them that weekends are off-limits. Explain gently that you need to have a life outside of work to be efficient in your role.
Working more doesn’t mean producing more. Not at all. A fresh mind can solve problems more easily than a tired one. And a tired mind can hallucinate specifications and find solutions to problems which don’t even exist. A nice way to create technical debt.
How have the developers been hired?
Do you have the impression that the people interviewing you know how to evaluate a developer’s skills? Are they trying to understand if you'd be a cultural fit?
If they sound like amateurs - speaking about the weather and avoiding technical questions, you can probably be sure that other developers went through the same interview process. Which means your future colleagues could be totally incompetent or even worse; not interested in the job at all! If you or they don’t fit the company’s culture, there will be a lot to complain about, and you motivation to work will quickly disappear.
Obviously if you can meet your colleagues you'll know what to expect, but we will get back to that.
Do they try to evaluate your soft skills?
Soft skills are as important as programming knowledge. My experience tells me that bad communication always drives bad implementation:
Bad communication between developers will lead to inconsistencies, misunderstanding and aberrations in the code. Ultimately you will have bugs and bad orchestration between applications / services.
Bad communication between developers and the business (product managers / product owners / mighty CTO) will create software which doesn’t do what it's supposed to do.
Remember: the goal of a good developer is not coding per se ; it’s to bring value to their company. Soft skills is an important part of that skillset.
In short do they:
Judge your communication skills?
Judge your capacity to solve problems?
Judge your adaptability?
I can't stress enough the importance of soft skills - especially communication. You’re not (and shouldn't be!) coding alone.
3. Software Developer Job Tests and Trial Days
The (In)Famous Coding Tests
I will be honest: I think tests are useless. If an employer wants to judge your skills they can:
Look at your Github profile.
Ask your former employers if they were happy with you.
Look at the consistency of your CV / portfolio.
Look at your experiences.
Ask you technical questions related to the company. Even simple ones can separate interested people from the rest.
There is an important keyword here: consistency. If the skills you claim to have on your CV is consistent with your portfolio, your github, your recommendation letters and your experiences, it means that:
You're not lying.
and you indeed have the skills and experience.
If you're claiming to be able to code in 5 different languages after two months as a developer, we've got a problem!
In short: there are other ways which are simpler and less time-consuming than setting up tests.
Moreover, tests need to be very well crafted to be effective. Which is rarely the case (big surprise). Most of the time, they are random questions which are not linked at all to the real tasks the developers nail in the company.
But let's focus on the result: these tests will push away developers who are potentially good and who can add value to the company while rewarding academics without any professionalism (those addicted to Kata).
There are places you can train for these tests (some websites like hackerrank are specialised in that) - but not worth spending a lot of time on. Why?
First, the tests are random. You never know what it will be. Second, I believe the best companies know how to recruit good employees for their specific needs without the need to setup tests.
Next time you fail some test, you should ask yourself if the company was really worth the effort.
Coding Should be Done… On a Computer
This is something I saw too often: coding tests on a piece of paper.
This might surprise you but nobody should code on paper. For obvious reasons:
You don’t have anything which a modern IDE / editor can provide you.
A software developer spends a lot of time Googling stuff. You can't Google on a sheet of paper.
Asking someone to code on a Windows 98’s would make more sense. At least there's a keyboard and a way to execute your code!
Another trend I've seen: the whiteboard interview. The mighty CTO (or tech lead) will ask you to write a bunch of code on a shiny whiteboard.
And here's what happens:
Your curly braces look terrible.
You can't write straight.
You will do some stupid syntax mistake ; replace your screen and keyboard with a whiteboard and pen and feel the confusion.
You'll also put a lot of ink on your new geeky t-shirt trying to erase your syntax error.
Your font size will be all over the place.
Who likes to have people staring at them judging their code? No one. Who likes it on a whiteboard? Even less.
How a Company Should Evaluate Their Candidates?
Two words: trial day.
As a candidate you will:
Meet the company’s IT team and see if you get along with them.
See briefly the company culture, how people work together and the general atmosphere.
You will see closely the company’s domain and technologies.
For this trial day you should ask to use your own computer, since you know it already and can even set it up in advance. If they work with a docker. No worries - install it before coming into the office.
I work on a Linux and have done countless tests on a Mac. Add the editors and tools I'd never used before and it's a perfect combination to screw everything up, stupidly.
My Software Developer Job Anti-test Policy
If the test is more than one hour, I walk away.
If the test is not on a computer, I try to explain how stupid it is. If they don’t understand, I walk away.
If the trial day is not paid, I walk away.
You may bend these rules given your experience, for example, if you need a job desperately, you'll have to accept some constraining and painful tests or an unpaid trial day.
Be careful though not to accept jobs in random companies you know little about, even if you’re a beginner: you could regret it later.
4. Project Management
Who’s in charge?
The way a company manages its projects is important for the developer team. If you don’t want to be constantly under pressure in an infinite death march, you might want to ask these questions:
Who’s managing the projects?
How many project managers are there? For how many projects?
Do they have other tasks except managing projects?
If the ratio of projects / project managers is totally unbalanced, prepare yourself for a chaotic work life with vague specifications and frustrating “coding for nothing” days due to misunderstandings.
Make sure that the project managers are not Swiss Army knives with a million and one things to do. They need time to… manage projects.
Choosing the project you will work on
Will you work on one specific project? Or all of them?
Not every project is managed equally in a company. If you work on a project important enough to have its own project manager, it’s a plus.
Ask the company if you can choose the project you’re working on and if you can switch projects easily. It’s always good to have the option if you’re bored.
Keep in mind that you will never be totally in your “project bubble”. Most of the time projects (micro services for example) communicate with each other. If some projects are not correctly managed in the company, you might still struggle with them indirectly.
The frightening deadlines
The pain point for every company I worked with.
Nobody knows how to measure deadlines accurately. Still, managers want precise measurements from their developers. Admire the contradiction.
You can ask these questions to your future employer:
How the deadlines are calculated?
If, as an answer, they come up with “precise” methods and calculations to measure them, you should be very cautious. If their estimations are considered as The Truth, they might pressure their employees to stick to them.
Are the deadlines flexible?
With a bit of luck the company’s managers understand that precise deadline estimations are hard. Therefore, they might try to keep the pressure low and calculate their deadline with a buffer.
Are the functionalities scopes flexible?
At least the scopes or the deadlines need to be flexible. Otherwise, prepare yourself for a lot of pain.
5. Working in a Team
Development is not a solo journey. You need to fit into the team to make sure they are really working together.
Again some questions I usually ask:
Do you do pull request?
What do you think about pair programming?
If they practice neither of them, it can indicate that everybody work in his little bubble without exchanging and learning from each other.
That's probably not what you want, right?
A developer should be striving to learn and grow as a professional. He should bring value to a company. He can only achieve this with a solid team and good communication.
Another important question you might ask: do the developers and the business-side work closely together? (By “business side”, I mean the people who decide the features developers should implement.)
If developers aren't allowed to provide their point of view on the applications they build, the job will quickly become boring, even painful. Do you like to implement dumb and complicated features which don't even answer the business' needs? Yeah, me neither.
If nobody listens to you or if you don’t even know who’s managing the projects, dumb implementation will happen a lot. In short: developers should work as closely as possible with the domain experts and the deciders.
This is the heart of Agile Methodology.
Get more specific information as well: does the company follow the Scrum or Kanban methodology?
Keep in mind that these are trendy words, the answer will be often “we use our own method, a mix of Kanban, Scrum and Lean”. If you don’t know what it means, you’re not alone.
Ask questions to know who is responsible for what. If everyone is working at their hierarchical level without collaborating with the level above or below, you should be worried. It happens quite often, even if the company claims “to be agile because they use Scrum”.
Waterfall is not a trendy methodology. Curiously a lot of companies are still following this model without even knowing about it.
For more information about what means Agile nowadays, Martin Fowler has summarised it very well.
Get a feeling for the developers
The best way to find out if you'll get along with the developers in the team is to meet them.
As mentioned above, a trial day is the best method to do this. On top of that, try to speak with them during lunch. You can learn a lot about the company, even if you don’t ask them direct questions.
Getting a feeling for the work atmosphere is super important.
6. Software Testing Processes
Automated tests should be a priority
Why should a company should be encouraging automated tests?
You don’t have to test manually each time you change the codebase.
It brings confidence.
Unit testing drives your architecture: difficult to test with too many dependencies and too few interfaces. Dependency inversion becomes your friend.
Functional / acceptance tests will make sure the application does what it’s supposed to do.
An application and its complexity can grow in parallel. Without any kind of test to support the development team, prepare yourself to enter (again) a world of pain.
On top of unit / functional testing (but not as a replacement!), having real people doing QA is a very big plus.
If your test suite is effective and well maintained, the QA team should have nothing to do. Since we are not living in a perfect world, it’s nevertheless always good to have them.
Having a little QA team only verifying that everything works with automated acceptance tests should be what a company wants.
The good, old anti-test crusades
You need to know if your future company is, at least, willing to test their applications. If they do it already it’s even better.
I worked for companies who were ready to “save time” and cut all the tests altogether. The reasons? A mix of deadline pressure and stubborn aversion against automated tests.
Arguing again and again in favour of tests is tiring and gets old very quickly.
My advice: be sure that your future employers know why tests are important before working for them.
7. The Schedule: Slave or trusted employee?
Flexibility is important if you have other obligations or simply to break your routine.
Home office and flexible schedule
Obviously if the company offers a flexible schedule and the possibility to do home office, it’s a big advantage. You can organise yourself better depending on your obligations or your energy level.
Be careful though: some companies will claim that employees can do home office… under conditions. Meaning, you need a very good reason not to respect the “normal” schedule or not to come to the “normal” workplace.
Always ask for details about these advantages.
A proof of trust from the employer
From my experience some companies are afraid to allow home office and flexible schedules simply because they think their lazy employees will take advantage of it and work less. This is a pretty common taylor-ist way of thinking.
However, a company proposing these advantages will show you something really important: employees are trusted by the management. You, as an employee, will feel empowered by trust. It’s also a good indicator about the company culture.
If you have colleagues (or employees) who can’t be trusted, you should simply not work with them. People who don’t want to work will always find a way, even barricaded in an office.
8. The IT team workplace
Would you like to spend 8 hours of your day in a dodgy office?
Always ask to visit the office when you have the occasion. Pay attention to these details while doing so:
Are the chairs comfortable?
Don’t hesitate to try them. Big surprise: developers spend their life on chairs. They are important. If you have the chance to have access to a standing desk, it could be even better.
Can you look outside from a window? Is there natural light in the room?
This is important for the mood. Natural light is better than flickering neon lamps in a cave. It’s nice as well to rest your eyes by looking outside and not always on a screen.
Is everybody in the same room? Is there enough space for everybody?
A tiny room with too many people will feel cramped and get you annoyed easily. Be attentive to the noise level as well: in any case, I advise you to buy noise cancelling headphones to be sure you can focus when you need to.
Is your future desk big enough?
Having space is important!
Will you find the perfect company?
I don’t think there are any perfect developers out there. Do you know somebody who hasn't create any bugs, is always focused, never tired, 100% reliable and has only ever has brilliant ideas?
Perfect companies don’t exist either: you need to know your priorities and balance the pros and cons. You will never find a company which answers every question of this article perfectly. You should make your choice depending on your actual needs, possibilities and preferences.
Obviously a developer with little experience might have to accept some more downsides. Be careful though: little experience is never an excuse for your employer to put ridiculous amount of pressure on your shoulder. Don’t let them crush your soul.
If I was you I would grab a piece of paper and write what you expect from your future company. It will help tremendously in your search and as you apply for jobs.
I've also gathered some questions over the years which I ask during interviews. I don’t ask everything, but cherry pick depending on the company and the job. So have a look!
Note: this article was first published on Matthieu's website The Valuable Dev