JuniorLearnsToCode

Once you have been to a certain number of interviews, you will notice that there are a lot of common questions that you will be asked by different interviewers. Sometimes differently worded, but most of the time the similar knowledge check will be required of you. This is especially the case if you are applying for a tester role for the first time, it may be for your first job ever, or a career change in IT, or if you're coming from another background. The goal of this post is to help people ace their interviews, and also to stimulate them to learn more about testing. Simply memorizing answers by heart will do you no good in the long run - you might find yourself in a situation where you bit off more than you can chew, let's say you find online a bunch of common QA interview questions, just memorize them without any understanding of the topics, bluff your way through the interview and you start working - the employer things you know what you claimed and expects a certain level ...

This is not one of those yes or no questions, the answers is "it depends". The world is not black and white, one size does not fit all and as adults we often need to make trade-offs and compromises. In this blog post, I will try to list both pros and cons when it comes to working for smaller IT companies, compared to working for a larger IT company. You know, different strokes for different folks and all that. We all have rather unique needs and motivations and while one person might thrive in a more casual environment, that same atmosphere could hamper someone else's growth.  Working in a Small Company Since it is easier to manage a smaller number of people, there will be less management layers and generally, smaller companies have less official administrative procedures involved - for example, getting your vacation approved might be just a matter of checking with your team and updating the company's calendar. Another thing typical for smaller companies is that the p...

This is going to be a short post, as I just wanted to explain why you should not be intimidated by the official job requirements. I often notice that a lot of junior people complain about job postings, saying that job reequipments are too strict and that the list of required tools/technologies is too long. It is true that lot of jobs have inaccurate descriptions, as sometimes they are written by non-technical people and there can be a lot of copy/pasting involved, to include hot an trendy technologies, which my not even be used by the company that is posting the job! Another reason is filtering candidates by using a lot of "intimidating" buzzwords, this way company scare of many enter level applicants as they will give up without even trying. But let us look at this from a different angle. I have witnessed first hand that very often you will actually be working with just a small portion of tools mentioned in the official job posting. Many people I have talked to also confirme...

The Three Amigos is a software developer approach that is often used in Agile environments. It a highly collaborative development strategy. It places a large emphasis on communication. Perhaps it's biggest selling point is the fact that different experts are working in union, complimenting each others unique skills, thus being able to gain a broader perspective on things. This approach helps out to get clear understanding of the requirements and agree on the "Definition of Done" - what exactly is need to put the story in the "Done" status. Roles Involved in the Three Amigos We need the following roles in order to utilize this development strategy: BA  - the Business Analyst would help ensure that team understands what is expected from the user stories, so the team realizes what business value would the customer receive. In places where there is no BA, the PO (Product Owner) will take place of this amigo. Dev  - the developer can help in understanding the require...

This is another blog post inspired by  Bloggers Club June 2021 - if you are a tester (or interested in testing) be sure to check out the Ministry of Testing, it's wonderful community of smart and helpful people and their forum (called the Club) is great place to get help, get inspired and to discus stuff to stimulate those little grey cells. This month's topic idea appealed to me straight away. I try not to have regrets, per say, but there I decisions from the past that, from today's perspective, I would have made differently. If I could, pretty much only thing I would have done differently is that I would have left support sooner (I worked in tech support for about two and a half years) and gotten into testing sooner. I spent a lot of time trying to find myself, I was learning WordPress and doing freelance consulting, learning Angular, React, PHP, Java, .NET/C# and other development technologies, mostly (but not exclusively) front-end oriented. I recently  blogged about ...

We often hear that everything is a matter of perspective and in light of that notion I have to admit that there was a time in my career when I wanted to give up on testing. Due to having seen testing in a wrong (and rather shallow) light, I pondered hard about leaving it for good for a career in web development. So, let us get into the meat of things. Now, when I talk to people I offer hear them describing me as someone who enjoys testing and is genuinely passionate about software quality. So how was it that I found myself in a situation where I wanted to quit being a tester if I love it so much? It was many years ago, and while I can't disclose exact details, I can talk about it in general terms. This blog post is in part inspired by my personal experience and also by observations I made while talking to lot of testers trough the time - and most of them relatively similar experiences to share, from some point at their career. It is my hope that by discussing things such as this on...

Various types of work attract different kinds of people, some of us like a dynamic work atmosphere, while others function best if things are more predictable and stable. Working for a big enterprise client is a lot different compared to dealing with clients directly while freelancing or working for a SaaS (Software as a service) in which case the company is it's own "client". I've worked in all three mentioned scenarios - currently, I'm working on a big enterprise project, in the past I've worked for several years for a company that was selling its own product and done some freelancing for a couple of years, as well. Bellow I will strive to list the advantages and disadvantages of all three types of jobs, in hope that this may prove useful for people looking for their first IT job. With memes, as always. So let's get started! Working for a SaaS Company Working for a SaaS, Software as a Service company, you usually won't have any interaction wit...