Back in the day, being hired as a programmer was just a matter of paper qualifications and a few skills in programming. Things have changed drastically with time. Your qualifications and programming skills alone will not get you the job. The market is flooded with college graduates, some filled with pure talent and passion, and others who pretend to be so. The excess demand for jobs has forced programmers to sharpen their skills. The fourth industrial revolution has made programmers learn and study things in various other fields, as well. In other words, employers are hunting for the best programmers who also possess knowledge in other fields.

Another concern for programmers is their inability to prove their worth in an interview. You might be the best among the rest, but nailing a tech interview cannot be guaranteed. What follows are some great ways to impress your interviewer and prove you’re worth hiring.

Tips to Prove Your Talent

1. Contribute to open source projects

What is so special about open source contribution? Well, there is a lot. But what I found interesting is that you learn from the experts in the industry. Not all your contributions to an open source project will be accepted. This sounds bad, but it’s not.

Any contribution to the project will be reviewed by an expert before it’s merged into the actual project. Whenever you make a contribution, if there is any improvement to be made, you’ll get feedback with some guidance on exactly how to do it. It’s like someone mentoring you on how to improve your coding.

Apart from this, you also can learn a lot more of the skills required by a software engineer, such as meeting people with the same interests as you, learning people skills, etc.

If you have made any open source contribution, that’s a massive plus point to prove your talent and a sure way to impress the interviewer.

Here is a guide to how to contribute to open source projects.

2. Answer Questions on Stack Overflow

Stack Overflow is any programmer’s best pal. Whenever a programmer encounters a problem in coding, probably the first thing they do is find an answer on Stack Overflow. But wouldn’t it be great if you could answer questions on the technologies that you’re fluent in and earn some reputation?

Stack Overflow has a reputation associated with each account. Whenever you answer a question, based on the quality and accuracy of your answer, people can vote for you, which in turn will increase your reputation score. This score is a great way for employers to assess your talent since the score is generated by one of the best programming communities.

Here is a guide to how to answer questions on stack overflow.

3. Score on HackerRank, LeetCode, and GeeksforGeeks

HackerRank, LeetCode, and GeeksforGeeks are some great sites to improve your coding skills by solving different types of challenges. You can use your preferred programming language to solve problems. You also can select your own topic to practice with the desired level of difficulty. For example, you can select a problem related to arrays with the required difficulty level and start solving.

Based on the way you solved, you’ll be rewarded with a score. These scores will help to depict your talent in problem-solving, the use of algorithms, and data structures, etc.

4. Try out new projects

Coming up with creative ideas and developing your own projects is a nice way to try out what you have learnt so far. You might have learned various technologies and languages following various tutorials, but if you are unable to build a program, website, or a mobile app on your own, then your effort has gone in vain.

A web app about yourself, a to-do list app, or a weather tracking app are a few projects you can try out while you are free. These will not only improve your coding skills, but you also can use them in your day-to-day life.

5. Write articles

Writing articles is a great way to express your passion towards what you love. Writing requires knowledge of what you write. Whenever you write something, you tend to study and do a small amount of research on what you are about to write. This helps to improve your knowledge to a great extent.

It would be great if you can write articles on topics other than programming, as well. You don’t have to write specific things related to other fields, but you could write something generic, adding some technical aspects that will show that you have some basic knowledge in other fields, too. Additionally, it’s a way to exhibit your written communication skills, which is a requirement most programmers lack.

The post 7 Ways to Prove Your Programming Skills first appeared on NRGSOFT.

You will become a better engineer if you do, I promise! You will raise the bar for software development.

Problems That Arise With Bad Code Reviews

In my career as a software consultant, I’ve seen many organisations put blind trust in their engineers. Imagine I’m one of the large companies right here.

I pay my engineers enough to expect them to know what they’re doing, right? They have been working in the industry for years. I’m pretty sure they can recognize bad code, right? —

Uhm, well…

In reality, this is often not the case and it leads to real issues:

Some people don’t participate in reviews. They hand them out to people that are experts in a particular domain. They don’t take the advantage to learn, because they don’t know what to look for. The opposite exists as well. We all know that kind of people that always want to give their opinion! Don’t forget to include them or they will get angry! Sometimes we even call those the architects of the organization. They participate in every single damn code review, you heard me right. Every single one.

This might upset someone, but I’m gonna say it anyway: everyone has an equal say. We are all developers in an agile team. We are all equally responsible for the code being produced.

Code reviews are not hierarchical. Someone less experienced has an equal vote as someone with many years of experience. I simply do not care how many years of experience you’ve got. We are all doing our job and it’s one of human’s key characteristics to make mistakes.

Every developer of your team has an equal approval vote.

People give the same remarks, all the time. This can have multiple reasons, but this is a really bad thing.

On one side this is a sign of a missed automation opportunity. If you give the same remark over and over again, can’t a system detect this kind of warning?

On the other side, you might lack good evaluation: your colleague makes the same mistake over and over again! This means they have stopped learning and doesn’t care about the quality of your product. That is the hard truth, believe it or not. Otherwise, they would have done something about it!

Both cases are a potential risk. Some of this code is and will be overlooked and eventually, one way or the other, some will get through.

In our current team, we still remember those times something got through a review. It’s an acceptable thing if it’s because of a funny comment. Which makes me smile as I sit right here. But if it’s something you’ve said hundreds of times, you can end up being disappointed in each other.

Easy approvals. We all know that one backend developer that looks at the merge request of frontend code and says, I guess this is fine, so let’s just approve this, right?

If you are not an expert in a domain, team up with someone who is knowledgeable, get their help and list things you could look for in code reviews together. Learn from each other.

Do not give blind approvals! Trust me, I’ve seen really experienced engineers that do this. Engineers capable of doing the most wonderful things in their code editor. Things other engineers can only dream of. However, they were domain experts and excelled at some parts of their job. At other parts of their job (e.g. reviewing frontend code), they simply underperformed.

If you don’t understand what you are reading, get help.

Your code review process takes too much time. Do you recognize the following situation? Your team is working on stories of their own and we don’t treat code reviews as urgent. What we often forget is that teams should actually maximize the throughput of stories. With the lack of a process, a lot of time can be wasted.

It can take hours before someone actually starts reviewing code that is not delivering any value in this state.
Comments have been given, and it takes time to process them. Sometimes people even start to work on something different and leave the review untouched. You can’t blame yourself for doing so — after all, nobody likes having nothing to do.

If you have to go through the process of waiting and processing comments multiple times, a lot of time is just thrown out of the window.

Do you recognize this? Well, I’ve seen it, so I bet at least some of you do. If you do, stop this nightmare. Stop it now, stop it today! Keep on reading to find a solution to this problem.

Every hour your story is “untouched” in code review, is an hour of value lost for the customer.

Can you review this, please? You might recognize the situation that you, the developer, feels the need to start polling others for reviews. You want to finish your work. And of course, that’s only natural. But people shouldn’t ask others to review their code.

This “almost mergeable” story, bug or refactoring is, in fact, everyone’s top priority as soon as it meets the requirements. You communicate to the team that you are ready for a review and it should be picked up as soon as possible. In reality, this is often not the case.

We might work so-called “sprints”, but in a marathon, we need everyone in our team in order to set a great pace. Often we feel like we are running alone in the last part of the race, which is also the part that matters most.

In a self-managing team, everyone is involved in delivering value.

The post How to Review Code in 7 Steps first appeared on NRGSOFT.

Soft skills are a set of competencies a person should develop in order to empathize and do a better job, especially when working with teams. They’re no more or less important than technical (aka hard) skills. They are peers — they make relationships more human.

I’ll start with some insights from Gordon Haff (Red Hat). The following quote is from an article in which he introduces metrics to be used in open-source projects, but I believe the wisdom goes beyond that subject:

Community management is certainly an art. It’s about mentoring. It’s about having difficult conversations with people who are hurting the community. It’s about negotiation and compromise. It’s about interacting with other communities. It’s about making connections. In the words of Red Hat’s Diane Mueller, it’s about “nurturing conversations.”

Let me highlight a few disciplines from that piece of text: mentoring, negotiating, interacting, connecting. These are mentioned in the context of open-source community management, so they have everything to do with teamwork. Teamwork, surely, has everything to do with software development. Makes sense?

Now, please stop reading and take a few seconds to guess what all of these disciplines have in common. What’s the fundamental thing you need to succeed in all of them?

My answer: Good communication!

Yes, I believe good communication is the most important soft skill. Good here means clear, succinct, and non-wordy. Communication should be as brief as possible, especially when written. Keep in mind people are smart and busy!

I don’t know if this is exactly the truth, but I believe the challenges I’ve faced over the past decade has helped me to develop a sense of how communication works. Now I leverage it to be a better software engineer and team member — hopefully, my teammates agree!

The post Communication Skills for Software Engineers first appeared on NRGSOFT.

Today, I have three tips to help you find inspiration to build beautiful interfaces that you’ll be proud of.

1. Visit Websites that Showcase Creative Work

There are several websites that showcase outstanding front-end work to help inspire other creative professionals, designers, and developers to create more awesomeness. When visiting these platforms, you’re bound to get an idea or two that you could use or tweak to make yours better.

Dribbble

Dribbble is one of the very best places to find amazing user interfaces built by professional designers. You can find everything from dashboards, to login pages, to mobile design.

Awwwards

Awwwards awards the best, creative developers who push front-end developments to the very limits with amazing “braingasm” inducing websites.

CSS Design Awards

CSS Design Awards is a platform that awards outstanding web developers and web design and showcases them in order to inspire other developers.

2. Get Some Inspiration from your Competitors

One of the best places to find inspiration is in people who have gone before you — people who have already built something similar to what you’re making. Going through their interface, you could pick a thing or two you could add to and make even better. While I’m not advising you to make a clone of your competitor’s website, I’m saying you could take bits and pieces from it to make yours even better.

3. Find a New Perspective

Sometimes, when one is uninspired, it’s possible you’re looking at things the wrong way, or the brain is just exhausted. My advice: take a break and do something else. Do something you truly enjoy that will take your mind off work.

One of the best ways to gain a new perspective is to take a step back and look at things from a different angle. Doing things fun outside of work releases “feel-good” hormones like dopamine. When you’re happy and rested you can get back to work with much more energy — you get the mental fortitude to see things from different angles.

Another way to gain a new perspective is to seek another pair of eyes. Show your design to someone else — a fellow developer, a designer, or someone who isn’t even into tech. Often, I find just having to explain what I’ve done to someone else, who isn’t the least bit interested in tech and doesn’t even want to be there, is all I need to figure out what’s missing.
Sometimes, something someone says in passing — something they can see — is all you need to see things from a different light.

Conclusion

Whether or not your users use and stay on a site depends a lot on the look and feel of it, which is determined by the front-end developers. Front end development is thus a crucial and delicate job.
While it’s very easy to lose inspiration and feel everything is crap, I believe the list of tips above will help you to create amazing interfaces.

Did I miss anything? Is there something else you do when uninspired? Please feel free to leave a comment so we can help someone else find their inspiration.

The post 3 Ways to Find Your Inspiration as a Front-End Developer first appeared on NRGSOFT.

Part 1: FAQ for Virtual Interviews

Video and virtual interviews differ from in-person interviews. While the questions asked are largely the same, the way we speak, introduce ourselves, and practice for these interviews requires a different approach. Here are the most commonly asked questions about virtual interviews, with actionable interview tips in response.

What are virtual interviews?

Virtual interviews are any kind of interview not done in person. It could be an online assessment, a phone call, or a video chat using a webcam. Virtual interviews are often used in the early stages of the interview process for initial screenings and assessments, and they’re becoming more popular for large companies because they save time and streamline their interview processes.

Phone and video interviews require different focuses. For a video chat, it’s common to use programs like Google Hangouts, Zoom, or Skype. These interviews are more similar to in-person interviews, since the interviewer can see you and respond not only to your words but also your clothing and body language.

Phone interviews, on the other hand, may remove some of the pressure over how to hold yourself, but they also present the challenge of tone. Since you can’t use your body language to express yourself, the way you use your voice and the tone you carry means a lot to the receiver. Some virtual interviews require other tools or programs, where you may be asked to code in GoogleDocs, CodePen, or CoderPad, amongst others.

How do you introduce yourself?

Many people are accustomed to in-person introductions and get confused about the best way to start a phone or video interview. Here are some basics to follow for virtual introductions. A general rule of thumb: keep it simple and natural.

For phone interviews, follow the cues of the interviewer. When you answer the phone, introduce yourself professionally with a statement like “Hello, (insert name) speaking” or “Good afternoon, this is (your name)”.

If you are calling the interviewer, which is less likely, simply wait for them to respond and follow the social cues. For example, if they answer the phone with an introduction, respond with a simple, “Thank you for speaking with me today, (interviewer’s name). This is (insert name)” or “I am looking forward to our chat. This is (insert name)”.

For a video interview, follow the cues of the interviewer. A video interviewer will likely introduce themselves first, prompting you to respond. Others may just say “I am ready when you are”, and you can respond with a simple introduction like “Good morning, thank you for having me today. My name is…” You could also begin by checking that the technology is working with an introduction like “Hello, thank you for talking today. This is (your name). Is my audio coming through on your end?”

What setup should I use for a video interview?

A tidy background. It’s important to have a professional background for your video interview. Since your interviewer will see you and your surroundings, you want to make a good first impression. I recommend sitting at a desk. This will help with your posture and sets a professional tone. Make sure the space behind you is clean and free of anything overly personal or unprofessional. The simpler the better.

It’s a good idea to close any unnecessary tabs on your computer to avoid distractions or unwanted notifications. Imagine that the interviewer can see your screen.

I recommend having a pen and paper with you during the interview for taking notes. You may even consider writing some talking points or questions you want to ask in the interview ahead of time. You can keep this to the side for reference.

Part 2: Process of Remote Coding Interviews

Coding interviews are notoriously challenging, so it’s important to know what lies ahead. In the past, coding interviews were typically conducted in-person, but currently, during this global pandemic, interviews have become remote. While the skills being tested are generally the same, how you’re asked to demonstrate those skills has changed. Let’s walk through the process of a remote coding interview to get you familiar with the new process used by big test companies.

Keep in mind that this is just the general process. Every company has its own unique process for coding and behavioral interviews.

Step 1: Online assessment

Some companies start their interview process with an online assessment. Adobe, for example, provides an online technical assessment to gauge your aptitude and coding skills. You can take a look at their questions here.

In most online assessments, you’re asked anywhere from 40–70 questions with a decent time window to complete it (around 2 hours is normal). You can check on Coding Interview to see which companies require an online assessment.

To successfully complete an online assessment, you should do adequate research based on the questions that will be asked. Don’t forget that they will ask behavioral questions, so you also need to brainstorm for these.

You will need a reliable working space, strong internet connection, and paper for working out problems. I also recommend setting aside more time than you need. Make sure that you won’t have any distractions or interruptions.

The post A Comprehensive Guide to Video Interviews for Programmers first appeared on NRGSOFT.

But more than just coding skills differentiate the senior developer from the mid-level and junior developer. So what exactly are the differences?

Knowledge

Obviously the senior developer has far more knowledge than the junior and mid-level developer. Knowing design patterns, architecture, automating testing, performance, security, etc. is a good way for a junior developer to close the knowledge gap with the mid-level and senior developers.

It’s important to know how things in software development should be done. But just knowing all this stuff doesn’t make you a senior developer. Knowledge isn’t the biggest difference between developers—it’s just one of the factors.

Coding

Despite what most people think, coding is not about communication with a computer. Coding is about communicating with humans and instructing computers. Eventually, code gets compiled and translated to zeroes and ones.

Code has to make sense for other developers that have work with it in the future. A new team that has never seen the code before should be able to open the code and start working on new features or bug fixes. This is where the big difference is between junior and senior developers.

I will leave out the mid-level developer in this comparison because the mid-level developer is kind of a gray area when it comes to coding skills. Obviously, it is somewhere in between the junior and senior. It probably leans more towards the senior side. This mainly has to do with experience, since mid-level developers have probably been through the whole development cycle at least once. They have made a lot of the most simple mistakes and learned from them.

How to sniff out the junior developer?

Junior developers are inexperienced. Some just graduated and are starting their first full-time job. The mindset of a junior developer often is to just make the code work. Working software and good software are considered the same.

Programming straightforward code is hard. And it’s something that junior developers don’t do. Junior developers write fancy code. You can recognize the junior developer by quirky one-liners and overly complex abstractions. This is the junior developer’s way of showing off and letting the other developers know how good they can code. And it’s wrong.

Junior developers focus on the computer side of the code at the expense of the human side.

And what about the senior developer?

When looking at the code of a senior developer, you might think: is this all there is? Where’s the rest of the code? A senior developer writes simple, straightforward, and maybe even dumb code. This is one of the biggest qualities that a developer can have when it comes to programming. A senior developer follows the KISS principle: Keep it simple, stupid.

A senior developer thinks about their code in a different way than the junior developer. Code written by a senior developer will be made with maintainability and scalability in mind. This is a totally different mindset than the junior developer has—the senior is thinking about the people who have to work with the code, while the junior is just thinking about making it work for the computer.

More Than Just Coding Skills

Besides coding skills, there are some other factors that can tell you who’s what type of developer.

Junior developers, in general, do the most simple tasks or tasks with low impact. They don’t do any design of architecture. Mid-level developers are not designing solutions either, they just perform tasks. The difference with the junior developer is that they perform those tasks with less supervision as long as they are assigned to relatively routine tasks. Senior developers can develop an application completely on their own.

It doesn’t mean that the senior developer doesn’t have any questions along the way. Every developer has a lot of questions every day and that won’t change. That’s no different for senior developers.

The difference is that senior developers know how to ask the right questions and how these questions get handled. Mid-level developers can ask the right questions when it comes to their relatively routine tasks, but need help on more complex tasks.

The senior developer is never lost and knows how to follow up the question with the right action. This doesn’t mean that a senior developer can’t ask help from other developers. Sometimes the best way is to just ask other developers with experience in that area for help.

The mid-level developer should be able to ask the right questions as well, as long as he doesn’t get assigned highly complicated tasks that require an in-depth level of knowledge.

You shouldn’t expect a junior developer to ask the right questions straight away. Since junior developers are inexperienced, they need guidance from a more experienced developer. The junior developer needs to get provided with the necessary resources or a big push in the right direction.

The post The Differences Between a Junior, Mid-Level, and Senior Developer first appeared on NRGSOFT.