This blog post was originally posted on my blog, The Valuable Dev.
Here you are! In front of a powerful CTO of the best we-will-disturb-the-market startup in town. You answered a job offer promising money and glory, soon they will be all yours.
To warm you, the mighty CTO begins to ask you to draw a B-Tree on a shiny whiteboard. Easy peasy, you draw a wonderful tree you saw in a garden today.
Then, he gives you a sheet of paper to test "your skills". You have to "code" on it a complete Chess application in 5 hours, AI included.
Finally, he asks you some "questions relative to the business", as usefull as explaining how to compute the Fibonacci number in Lisp with recursive procedures and an iterative process.
At the end, he finally asks you if you have some questions.
You look at him like a cow look at a train. Your brain is damaged, the meeting room looks more like a dungeon where the worst tortures are given. You are empty. Soulless. You go out as fast as you can, wishing for your favorite teddy bear, feeling like a fraud.
Can I help you dear reader? Some companies love to have illogical hiring policies. So far I worked for 6 different companies in 8 years and did a lot of interviews.
Instead of writing another blog post "how to be sure to nail random tests which will assure you to work with fizzbuzz professionals", I will show you how you can simply judge if a company is a good fit for you. Hint: the one which ask you to solve tricky tests from MIT are not necessarily the best.
1. Gather as Much Information as You Can
What this company is about? Is it worth applying for a job there? These are the first questions you need to ask yourself.
For quite some time I was feeling so inexperienced I was applying to everything and anything. The result was very disappointing 90% of the time.
The Software Developer Job Offer
The job offer itself can say a lot about the company.
Is it again an offer promising glory, money and fame in the best environment ever?
Do you feel them more honest, not trying too much to hide the problems they face?
A lot of offers will look too good to be true. If you have some doubts, write them an email and try to know more about these "incredible opportunities" and "out-of-this-world advantages".
Do they ask to be good in multiple fields (backend, frontend, devops, making coffee)?
This one is dangerous: burn out can come quickly when you need to take care of everything.
In short:
- Look if the offer is consistent with the business model of the company.
- 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 to you, the next step is 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 they try to attract? What are their market target?
Let's take an example: you see a job advertisement on Internet and you go looking at the company's website. If you don't understand who they try to attract or even what they are doing, big chances are that their potential customers either.
Obviously it depends as well on their business model. If they are in a very specific market niche, maybe you don't have the domain knowledge to understand what they are doing.
Other than that, if everything looks confusing, it's a smell:
They don't know how to market themselves. If it's a small company they might not survive for very long. A startup which is not in a good shape can be very stressful and put a lot of pressure on their employees.
If the company's way to market their products look irrational, nothing prove that their internal management decisions are better. It includes as well employee's management.
At least expect a lot of complaints from their employees on the clunky business model.
Preparing 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 a positive answer comes you need to:
- Get even more information about the company. You need to understand in what you're stepping in.
- From there you will have questions. Write them on a sheet of paper and bring them to the interview.
- Write as well what you expect from the 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. In the worst case they will negotiate.
- What position you would like to have?
- What do you want to learn?
- If they didn't tell you, ask them if there will be a coding test and how long it will take before going to the 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 dreams 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 search a company to expand your skills and reach your middle / long term goals with a decent salary.
- The company search a developer who can use your knowledge, ideas and skills to create some business value.
You give them something, they need to give what you want in return. You need to evaluate them as much as they try to evaluate you.
That's why if they don't really answer your questions and if they only try to test your skills and knowledge, I would advise you to just walk away:
- Difficult to know if you would be happy working for the company if your questions stay unanswered.
- If they don't want to listen to you during an interview, they won't do it either when you will be an employee. You don't want to be a brainless code monkey 8 hours a day.
How is the Company Managed?
The interview itself can 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 the week end?
The two last indications are obviously pretty bad: even if I worked way more than 10 hours a day at the beginning of my career, it's not the path to follow. First because you will do more harm than good in your codebase and second because you risk to burn out.
If they don't speak about it, take the first occasion to precise that you won't work the week end. Explain gently that you need to have a life and rest from time to time to be efficient at work.
Working more doesn't mean being more productive. Not at all. I would advocate the contrary: a fresh mind can solve problems more easily than a tired one.
Even better: a tired mind can hallucinate specifications and find solutions to problem which don't even exist. A very effective way to create technical debts.
How Have The Developers Been Hired?
Do you have the impress that the people interviewing you know how to evaluate developer's skills? Do they ask you questions to see if you can fit to their company culture?
If they look like amateur speaking mostly about the weather, keep in mind that the other employees might had the same interview process.
It means that your future colleagues can be totally incompetent or even worse: not interested by their job. If they don't fit the company's culture, they might complain about it a lot. Your motivation will quickly go down.
Obviously if you can meet your colleagues you will know if you want to work with them. We will come back to that.
Do They Try To Evaluate Your Soft Skills?
Soft skills are as important as pure programming knowledge. My experience tells me that bad communication always drives bad implementation:
- Bad communication between developers will lead with inconsistencies, misunderstanding and aberrations in the code. Ultimately you will have bugs and bad orchestration between applications / services.
- Bad communication between the developers and the business (product managers / product owners / mighty CTO) will create software which doesn't do what they are supposed to do.
Remember: the goal of a good developer is not coding per se ; it's to bring value to his company. Soft skills should be an important part of our skill set.
In short do they try to:
- Judge your communication skills?
- Judge your capacity to solve problems?
- Judge your adaptability?
I will never stress enough that soft skills are important, especially communication. You're not (and you shouldn't!) 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 want to judge your skills he can:
- Look at your Github profile. Of course, you should have some code in there.
- 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 others.
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 are not lying.
- You have indeed skills and experiences.
If you claim that you know how to code in 5 different languages even though you work as a developer for only two months, there is a problem somewhere.
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. Big surprise: it's rarely the case. Most of the time, they are random questions which are not linked at all to the real tasks the developers nail in the company.
What I can tell you is the result: these tests can push away the developers potentially good to add value to a specific business while rewarding academic without any professionalism, addict to Kata.
You can of course train to nail coding tests (some websites like hackerrank are specialised in that) but I would not spend a lot of time on it. Why?
First, 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 tests, 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 code on paper. For obvious reasons:
- It's confusing.
- You don't have anything a modern IDE / editor can provide you.
- A software developer spend a lot of time Googling stuff. Try to Google on a sheet of paper. It's not easy.
Asking somebody to code on Windows 98's Notepad would make more sens. At least you have a keyboard and you can execute your code.
Another trend I saw too often: the whiteboard interview. The mighty CTO / Tech lead will ask you to write a bunch of code on the new shiny whiteboard in the meeting room.
You know what will happen:
- Your curly braces will look terrible.
- You won't write straight.
- You will do some stupid syntax mistake ; replace a screen and a keyboard by a whiteboard and a pen and you will feel the confusion.
- You will put a lot of ink on your new geeky t-shirt, trying to wash out this horrible syntax error.
- Your writing will be too big and then too small.
Who likes to have people just staring at you and judging your code? Nobody. Who likes it on a whiteboard? Less than nobody.
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 it.
- 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: you know it and you can even set it up in advance. They work with docker? Install it before coming there.
I'm working on Linux and I did countless tests on mac: it was a pain. Add on top editors and tools I didn't really use before (I hate Sublime Text for that) and you have the best setup to screw up everything 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.
Keep in mind that you need to bend these rules depending on your experience. If you need desperately a job, you might accept constraining and painful tests or accept to work for free during a trial day.
Be careful though not to accept every jobs in random companies you don't know anything about, even if you're inexperienced: you might regret it later.
4. Project Management
Who's in Charge?
The way a company manage its projects is utterly 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 some questions:
- Who's managing the projects?
- How many project managers do you have? For how many projects?
- Do they have other tasks except managing projects?
Obviously if the ratio 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 some Swiss knives doing one million things. They need time to… manage projects.
Choosing the Project you Will Work On
Will you work on one specific project? All of them?
Not every project are managed equally in a company. If you work on a project important enough to have its own project manager, it's definitely a plus.
Ask the company if you can choose the project you're working on and if you can switch project 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 if you're attached to your sanity:
- How the deadlines are calculated?
If, as an answer, they come up with "precise" methods and calculations to measure them, you should be very careful. 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
Coding Together
Development is not a solo journey. You need to fit in the company's team and 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.
Should I precise that it's not what you want?
A developer should be striving to learn and grow as a professional. He should bring business value to a company. This can only be achieved with a good team which communicate efficiently.
Agile Methodologies
Another important question you might ask: does the developers and the business side work closely together? By "business side", I mean the people who decides what features developers should implement.
If the developers are not allowed to provide their point of view on the applications they build, it will be quickly boring, even painful. Do you like to implement dumb and complicated features which doesn't even answer the business needs? Me neither.
If nobody listens to you or if you don't even know who's managing the projects, it 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 the Agile Methodology.
You can try to 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 does what. If everybody work at his hierarchical level without really collaborating with the level above or below, you should be worried. It happens quite often, even if the company claims "to be agile because we use Scrum".
The best would be deciders working with the whole developer team as closely as possible and at every step of the project.
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 summarized it very well.
Get a Feeling About the Developers
The best way to know if you can get along with the developers is to meet them.
As mentioned above a trial day is the best to do so. On top of that, try to speak with them during lunch for example. You can learn a lot about the companies, even if you don't ask them questions directly.
Having a feeling about the atmosphere is really important.
6. Software Testing Processes
Automated Tests Should Be A Priority
Why a company should be encouraging automated tests?
- You don't have to test manually each time you change the codebase.
- It brings you confidence.
- Unit testing drive 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 very in parallel. Without any kind of test to support the development team, prepare yourself to enter (again) a world of pain.
Quality Assurance
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 favor of tests can be pretty tiring after a while.
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 sometimes 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 organize 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.
For example, you might need to have 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 it. It's a good indication about the company's 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
Do you like to spend 8 hours a day in dodgy offices?
Always ask to visit them when you have the occasion.
You should 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 utterly important. If you have the chance to have access to 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 be very annoying very quickly for everybody. Be attentive to the noise level as well: in any case, I advice you to buy noise cancelling headphones to be sure you can focus when you need to.
- Are your future desk big enough?
Having space is important!
Will You Find The Perfect Company?
I don't think there are perfect developers out there. Do you know somebody who doesn't create any bug, is always focused, never tired, 100% reliable and has only good ideas bringing a lot of business values?
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 answer 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 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 a company. It will help you tremendously when you apply for jobs.
I gathered myself some questions over the year I ask during interviews. I don't ask everything of course, I cherry pick depending on the company and the job.
Top comments (0)