Ars Longa Vita Brevis
The above quote actually originates from an aphorism by the father of medicine, Hippocrates. It means Art is long, life is short. Hippocrates used it to remind medical students that “It takes a long time to acquire and perfect one’s expertise and one has but a short time in which to do it”
As a Java developer, I often see job adverts from companies and hiring firms. Usually they will have a long description of the company, what it does, what it expects of you and most importantly, the skills that the company is looking for in a candidate. Usually I just skip everything else and go to the skills because no matter how good the company is, if my skills don’t match the requirement, it doesn’t matter. Here is a job description for a Senior Java Developer position that I picked from LinkedIn:
Your Skills:
- Understanding of Agile Web development process
- Strong grasp over Object Oriented Programming concepts
- Hands on experience with programming languages like Java, Python, or C#
- Strong knowledge of Relational database design and SQL
- Familiarity with Unix operating system and scripting in Bash or Python
- Solid understanding of HTTP REST APIs, JSON, and API tools like Postman or cURL
- Experience with test automation and CI tools like Jenkins or CircleCI
Great to Have:
- AWS experience
- DevOps experience
- A unique hobby or two
Easy right? No big deal. Just about any Tom, Dick and Harry can qualify for this right? Well, let me introduce you to “modern” hiring processes.
The Coding Test
This is usually the first step in the interview process. Usually you will be subjected to a test from sites like HackerRank and Codility. You will most likely answer algorithm-based questions like “Find the minimum sum of array elements from either end of an array”.
Usually in order to pass you will have spent weeks practising on sites like LeetCode, HackerRank, GeeksforGeeks and TopCoder. Never mind the fact that most developers are simply too busy doing their jobs, learning new tools, methodologies and living their lives, to spend half their lives prepping for an interview.
However, if you are fortunate enough to get through this stage, then you move to the next stage:
The System Design Interview
It’s not always titled like that but essentially this is the stage where you will be analysed by a technical panel. You will be asked to design Twitter or Uber or a URL shortening service.
To a novice developer this might sound quite simple but in reality you are being tested on a lot of things. Some of the things you need to understand in order to get through this section is:
- Types of Databases: Key-Value, Document, Wide Columnar, Relational and Graph databases
- Caching: Caching systems, Cache invalidation etc.
- Load Balancing
- Software architecture: Monolithic architecture, Microservices architecture, Service oriented architecture, Event driven architecture etc.
- Messaging queues
- Network protocols
- Distributed systems
Each bulleted item actually represents several books and courses and actually goes so deep that no one person is an expert in all or even half of the above. Translation, it takes a good amount of learning and experience to be good enough to correctly answer a System design question.
Some recruiters understand that and will promote you to the next stage if you can even demonstrate that you have basic understanding of the above. You move on to the next stage:
The Interview with the Engineering Lead
By this time you are feeling good about yourself. It’s been hard, you’ve been practising for months, even a year. You weren’t sure you did all that well but hey, you’ve gotten this far right? You must be better than the rest who haven’t gotten this far or at least not as bad as you thought you were. You push away that Impostor syndrome and choose to believe in yourself, at least until you meet the engineering manager.
The interview starts easily enough. You answer questions on new features in Java 8 including; Functional Interfaces, default methods, Streams, Lambdas and Date/Time handling. You feel good until they move to concurrency and start asking you about Concurrent collections, the virtual keyword, Futures and improvements in concurrency handling in Java 8.
Honestly, concurrency is a hard topic and if you have not dealt with it in over a year, you will likely have forgotten all about it. Assume the Engineering manager likes you and you move to the next step:
The Behavioural Interview
Mind you, getting through the first three stages is no easy feat. You need to have studied and practised extensively even when you’ve been working as a senior developer for years. The reason being that the technical interview usually tests on many more skills than those that are actually required in your day to day job. However, not learning those technologies means that you may never get a job in the tech world.
The behavioural interview is not easy. You will be asked questions such as:
- Why should we hire you?
- Why did you apply for this job?
- Where do you see yourself in five years?
- Describe a time when you had a conflict with your superior.
- Tell us about your biggest failure.
- How do you respond to criticism?
Again, these questions look easy but they are actually testing on a lot of things like:
- How well you know the company
- How well you’d fit within that role
- How you would do in a team or working alone
Do NOT walk into an interview without having prepared ready answers to these specific questions. These answers need to be specific to the company and the role that you are applying for. Try to avoid being negative in any way but also don’t exaggerate or give common answers. You need to seem as genuine as possible while painting yourself as the best candidate for the job.
You may pass this stage only to be told that the company has withdrawn the job or that you were not successful. Then it’s back to the job search, back to working on algorithms and system design questions, learning tools and trying to learn something new that a potential employer wants. After all, you never really have all that an employer/recruiter wants.
After multiple interviews, sleepless nights, reading dozens of books and going through a number of courses, you finally land a job and here is what you find.
The Actual Job
Here are the actual skills you will require for the job:
- Testing skills — JUnit, IO RestAssured, Cucumber, Spock
- Build tools — Maven, Gradle
- Messaging standards and protocols — Restful, Soap, GraphQL, gPRC
- Software Methodologies — Agile, Waterfall
- Collaboration tools — Bitbucket, Jira, Asana, Confluence, Git
- Databases — PostgreSQL, MySQL, MsSQL, Oracle, MongoDB, Redis
- Messaging Queues — AMQP, RabbitMQ, Apache Kafka
- Container Orchestration tools — Docker, Kubernetes
- Web Frameworks — Spring boot, Quarkus, Micronaut
- ORM tools — Hibernate, JOOQ
- Scripting — Bash, PowerShell
- Cloud — AWS/GCP (This is an entire ecosystem!)
This is just a subset of what you will actually need to know. There are other things that you need to invest in learning as well including:
- Domain driven design
- Behaviour driven development
- Test driven development
- Continuous integration
- Refactoring
- Patterns
- Principles
- Best Practices
- Anti-patterns
- SOLID
- Design patterns
- Deployment
- Asynchronous programming
- Functional Programming
- Regex
- Performance optimisation
- Sometimes even knowledge of other JVM languages like Groovy and Scala
I can go on and on and on and I pulled all of this from my head. Imagine what more I could add onto this list with a bit of research. These are not things that are going to be put in your job description but without them, you are going to run into problems and will most likely end up getting fired.
A good example is, without knowing SOLID and Best practices, your pull requests will keep getting torn apart and you will never meet your Sprint goals. There’s a lot more to Software development than just code! Recruiters and companies might know this but they really have no idea on how to test for it.
This results in a tragedy both for hiring companies and candidates because as a candidate if I prioritise algorithms and system design and I get that job, then soon after the company will start to face problems for which I have no solutions. Why do I have no solutions? Well, maybe because the only solutions I have are to LeetCode problems. The company will no doubt feel they need more senior engineers and raise the hiring bar using the exact same strategies that didn’t work for them before.
When your codebase becomes too big to maintain, what you need isn’t someone who is the best in TopCoder competitions, what you need is someone who knows about modular design, design patterns, refactoring legacy code, refactoring tests. You need someone with an appreciation of good design principles (Codility won’t tell you that). You need someone who recognises patterns and anti-patterns of writing tests. Someone who knows which tools are heavy and should be avoided. Someone who understands that transactions usually get heavier when they cross process boundaries.
When productivity is low, you need someone who understands the continuous integration process. Someone who understands that trunk-based development and pull requests can become a bottleneck rather than an advantage. You need someone who understands how to run tests in parallel and which tests to run when and where. You need someone who knows how to handle automatic configuration management and basically, how to streamline the entire process.
Summary
Not all recruiters are bad or follow the above process. Some of the good ones will filter out most candidates based on skills and years of experience and then send a small take-home test for a small project. This will help the recruiter discover the candidate’s skill level. You can easily discover if the person borrowed the code by later asking them about it.
The above process does have merit for companies like the FAAMNG because they simply have too many job applications to handle. Google actually received 3.3 million job applications in 2019 alone. However, I am willing to bet that 90% of hiring companies cannot offer the same benefits and job security that Google offers.
Now, you may think that because I am ranting, I am poor at HackerRank challenges. I actually rank among the top ten Java developers in my country on the Java challenge in HackerRank. I can ace those algorithm tests and invest lots of time in passing interviews and I would pass those interviews. However, experience has taught me a hard lesson, that passing interviews is only the first step, keeping the job and having peace of mind is the rest of the journey.
