DEV Community: Maciej Płatek

5 topics you should touch on during the recruitment process

Maciej Płatek — Thu, 20 Apr 2023 09:46:53 +0000

The recruitment processes can be weary and after answering countless questions you only think about leaving the interview, but you should never lose an opportunity to ask your interlocutors some questions. Why? There are a couple of reasons. First of all, there are a lot of things you should know before you accept the job offer. Another reason is more practical, when you are asking questions you look less intimidated and more experienced and so why not score some more points?

It’s important, however, to keep in mind that you shouldn't ask technical questions to HR people and vice versa, which can lead to uncomfortable situations. If you want to address any technical doubts you can ask if you may rise them on the next step of the recruitment process or maybe the recruiter can get you in touch with someone who can answer them.

I don’t want to crush you with an overwhelming list of all possible questions, because it may bring only more confusion. I present to you which topics you should stick to during the conversation to finish it with the most possible amount of information that should be handy.

1. Work organization

If you think about work organization, probably the first thing that comes to your mind is how your typical work day will look like. And that's the correct approach because that defines how your life will be going. Ask about hours, is it typical nine to five? Are there any office hours? Or maybe the company is totally flexible and you only should stick to the meetings? After you get the answer you will be sure if such day's composition suits you. So we already covered the meeting topic and to be frank - meetings can be harsh. Ask how many meetings you are scheduled to attend in a week. Some people prefer fewer meetings and if you are not sure what your preferences are - trust me, you prefer fewer ;)

Usually, based on the job offer, you already know if it is a remote, stationary or hybrid position, but even so, you should ask about that. Sometimes companies interpret remote jobs as “2 times a week in an office” or hybrid as “1 time a month from any location”. So better be sure than sorry. If you are expected frequently in an office, ask for free parking, because that can be a really big struggle in cities.

At this point you should know where and how you will work, so your next concern is equipment. Will the company provide you with a brand-new Macbook Pro? Can you expect to expand your home office to 8 monitors? Are peripherals even an option? Or will you need to use your old PC with a keyboard that is a house for a family of spiders?

2. Responsibilities and technicalities

Technical people should have technical responsibilities, that is obvious. Or at least it should be…but it’s not always the case. That’s why you should always ask about your responsibilities - what you need to do from starting working on a task till you mark it as “Done”. Will you be responsible for one project? Maybe besides the project, you are expected to handle something extra? Be inquisitive about it, and stick to this topic until your curiosity is satisfied.

After you finish the cross-examination about responsibilities, ask more specific questions. What does the technology stack look like? Which version of the framework is currently used? Unless you like working with legacy code, that is a good sign if a company uses one of the latest versions.

Another good idea is to ask about some advanced subjects. Is there Continuous Integration/Continuous Delivery used? How big is the test coverage? Are you working in Test Driven Development? Such questions will get you some bonus points.

3. Team organization

After you get knowledge about your responsibilities, now is the time to ask about people who will be sharing them with you. Will you be working in a team? How big is the team? Do teams cooperate on the same product? What roles do people have in your team? It is really important to know that. Workflow varies significantly between a team of 5 programmers and a team of 3 programmers, QA and Product Manager.

The next step will be to ask about the methodology the team is working on. Is it Agile? Maybe Scrum? Waterfall? Or some in-house implementation of principles? Trust me it is more important than you can think. If the recruiter is avoiding the answer then you can assume that something is wrong with the team organization (or it's not for just one particular project!).

4. Your future

Your future should always be your concern, even if you are treating the company as a temporary stop. Courses, conferences, training, and certifications are the things that can positively affect your future and have a really good impact on your career. For junior developers such opportunities can be even more valuable than financial benefits. Ask if there is any budget for such activities.

On the other hand, consider asking about your career in the company. How often can you expect an evaluation meeting where you can ask about a pay raise? Can you get a promotion to higher positions? Don’t be afraid to ask that, it will not be considered rude, but rather appreciated that you are looking forward to developing and planning to build a career path.

5. Benefits and events

The last position on our list is focused on benefits and events. Benefits consider all kinds of bonuses you can expect from a company. For example, it can be private insurance, private healthcare, a lunch card or some kind of sports card. It varies between companies, some of them are giving you a lot of benefits, while others prefer giving you more on your paycheck.

Other things considered bonuses are company events. Such an event can be a typical activity that is helping build bonds with a team, so parties in restaurants, go-karts, bowling etc. Even if you are a hardcore introvert and you have no interest in them you should know what to expect. But social events are not the only activity you can expect a company to host. Ask about a hackathon or some kind of internal knowledge-sharing meeting.

Summary

Repeating “don’t be afraid to ask” can be a good summary of my pieces of advice list ;).

Treat recruitment meetings as a source of information, both for the recruiter and you. Before accepting a position be sure that there are no unknowns. This is especially important if you are in more than one recruitment process because you shouldn’t decide on an offer only salary-wise. Asking important questions should get you a brief understanding of how a company is doing and if it is the right place for you.

Good luck with your next job interview, I’m sure that you will make a good impression!

A ‘wise’ guy tactic for effective code review practice? Use checklist templates!

Maciej Płatek — Tue, 05 Apr 2022 08:13:08 +0000

I think everybody agrees on how important and useful practicing code review is. It helps you catch bugs early in the process and reduces long-term development time. It also has the benefits of sharing knowledge, improving estimation skills, and keeping the code consistent with established conventions within the project. In one sentence - it improves the overall quality of code. But how do you do it like the 'wise guy' from this article's title? The answer is simple.

Sometimes being a developer is all about trying to be structured - simply following rules and using the right tools. I know that performing Code Review (CR) can be a problem for some devs. To avoid all the traps and make the whole process easy and effective I recommend using checklists. They should be the first choice when you're performing semi repetitive tasks. So what's the argument against using them as templates? Yea, I don't know any either.

Basic rules - keep the lists short
The principal rule is to keep it simple. Lists that are too long are overwhelming and can backfire. Stick to the fundamentals and focus on the most important parts, however, it is meant to be useful so don’t hesitate to fit it to your needs. Rules should be listed in a specific order, because in most cases if one of the points is not fulfilled you should stop reviewing and contact the author. Of course, a checklist is beneficial not only for the reviewer, but the author of the code should be able to use it before submitting PR to remove obvious mistakes.

Automated tools are the key
Any automated tools that are used in a project must succeed. If any static program analysis or automated test reports a problem it has to be fixed before review. Automats are the first obstacle you need to overcome to start CR.

Are changes ready to be merged?
If PR has conflicts with the target branch there is no point in checking the code because you will probably need to perform a review one more time. This should be obvious, but often changes that are merged earlier can lead to new conflicts, and resolving them is the responsibility of the PR author.

Are commits messages correct?
Before you take a look at the code, check the commits messages. Comments like “Minor fix” or “Added new feature” are meaningless. Developers must stick to the commit convention used in the project, with no excuses.

Is PR small enough?

Neither you nor me have Chuck Norris' skills. Our perception is limited, so if PR consists of 3000 changed lines, you will have problems understanding changes. Remember to keep it small, but without forcing strict limits, because it needs to be flexible. If you have worries that your PR is too big, it probably is, so just check out the new children’s branch.

Are requirements met?
Requirements are the reason why the feature branch exists, so always check if changes fulfil them. Believe me - you don't want to spend time reviewing the whole code if requirements are not met. Been there, done that. Don't recommend it. Check ticket description, look if something is missing or is incorrectly implemented, and immediately report to the author if there is a problem.

Do you understand the code?
The question may seem odd, but it's important. To perform CR you must understand the code and be able to do it in a reasonable time. So code should be self-explanatory. If some functions don’t make sense or classes look messy, the code probably needs to be reorganized. You may be the next developer working on this part of the code, so take into account that this code will be merged to the main branch after your acceptance. Clicking the merge button or accepting the code review means you are now sharing responsibility.

Dev's first commandment - stick to the coding guide
I'll say it one more time - always stick to the coding guide. No excuses. Ever. Check if everything is correctly named, files have the correct structure and if the approach is consistent with principles, DRY, SOLID, or any other clean code rules team is using.

Do we need a library for that?
Libraries are a double-edged sword. Sometimes developers import huge and resource-consuming libraries and use only one function. It is only justified in cases when we can use more of it in future tasks. The second case is when developers add libraries that are similar to one already present in the project and duplicatesare never welcome. The last thing is to check is if the library is not maintained any longer or marked as deprecated

Duplication is not welcome
In most cases finding unnecessary duplications can be a part of the coding guidelines, but it is worth mentioning it as a separate point on the checklist. New team members in particular can have problems with creating duplications, so just point out which part of the code they should use. There is no need to reinvent the wheel, use language features and already existing functions instead of implementing similar features.

Test, test, test!
Yes, writing tests is also part of a task so check if they are correctly implemented and cover all coding paths. Just like normal code, tests should also meet coding guide standards and be consistent with project assumptions. Verify that all tests are passing for the right reason and take a second and think if there are any edge cases that haven’t been tested.

Documentation is a must
Right now you and the author of the code know what is going on. But will other team members be able to easily catch up and use or develop it? If you are reviewing API - check if all endpoints are correctly notated and documented. For frontend checks, you can confirm if everything is available at Storybook or another component explorer. Any libraries used or architecture solutions must be put into a decision log.

A ‘wise-guy’ conclusion ;)
This article provides you with several suggestions, but a good CR checklist must be agreed with the whole team. Keep in mind that checklists should be a live organisms, if you encounter problems in the development process just add new points or keep more than one type of CR template based on task type.

There you have it. Good luck with your next code review!