When young engineers start their career, they are usually overwhelmed by the amount of information thrown at their direction. There are many challenges during the first year when you become employed, and it is my goal to highlight some of them in this article. I hope it will help my readers to focus their efforts and accelerate their careers faster and more efficiently.
After working as a verification engineer for almost ten years, I have came to a better understanding what are the typical challenges young engineers face and I decided to compile a list of skills, habits and set of behaviors, that are very important for a proper career kick-start.
This list is reflects my personal opinion and there are probably many more things that can be added to it. Still, I do believe that my knowledge and experience may help juniors to better understand what is out there and what they should focus on.
Well, let’s jump in! I emphasize that this list is written primarly for a verification engineers, but I dare say that most of what follows, can be applied to many similar positions in the industry.
How to communicate with the client
One of the first things you will find yourself in, is communicating with the client. This is usually done via email and Skype/Teams. When I was a junior, I remember I was often very nervous, when I was supposed to talk to a client, being affraid that I will say something “wrong” or that I will not know the answer to their question. In time I have learned that both of these are perfectly fine. When you don’t have the answer to the question you’re asked, openly say that you don’t know and ask for more time to obtain it. They will appreciate the honesty, much more than if you try to squeeze yourself out of it.
Most of your correspondence will involve explaining complex issues related to RTL logic, and it is normal that initially you don’t know how to communicate it properly. Your team leader should help with this, but in time you will learn how to best explain what you’re trying to say. Make sure you understand the preferences of the client, when it comes to communication: whether they like emails with long, detailed explanations, or short ones. Maybe they prefer a lot of pictures, and no words, or maybe they just prefer to call you and talk directly. Once you understand this, you will be able to calibrate your communication style to that of the client’s, and from that point on, communicating all the challenges and tasks, is much easier.
Personally, I love using a lot of pictures in my emails, as they tend to be self-explanatory, but this does not necessarily mean it’s good in all occasions and for all recipients. Consider example shown below. Picture like this allows me to use fewer words in email, when I’m trying to explain a complex issue:
Again, the leader of your team should help you with this, so you don’t have to reinvent the wheel.
Explore cultural differencies
You will probably work with clients from all over the world. Make sure to familiarize yourself with their culture (both corporate and non-corporate), so that you can better understand what’s going on, when you’re talking.
I remember how former client of mine once said “Milos, excuse us for a moment, we’ll talk in our mother tongue to discuss it quicker. It will look like we’re fighting, but we’re not really.” And indeed, they started yelling at one another so loudly, I was almost scared. But, it was just how they comunicate.
Being aware of cultural differences will help you better understand emails you receive and not to misinterpret tone in them. Maybe it sounds harsh to you, but it’s really nothing personal.
Having said that, I am not a communication expert, but I did learn over the years that you need to adaprt your style, depending on who is on the receving end of the email you’re sending.
How to communicate within the team
Equally important is the communication within the team. There are many books and courses related to this topic and I encourage you to explore what is out there. My goal here is to simply highlight the importance of this. You will work with various people in the team and each of them may have different communication model. In time you will learn how to approach everyone, while being mindful of their own communication preferences.
Goal of the whole team is to deliver the results to a client. Working together and creating a good synergy within the team is a requirement for being successful in this work, and without a proper comunication, this will be a significant challenge.
How to debug
As a verification engineer you will spend big portion of your work day debugging (don’t let this sound demotivating – it’s quite an interesting part of the job really).
Debugging is also something for which the whole book can be written, but what you need to know is that you will get better at it in time. I still remember my very first error which I had to debug (I really do remember it). It was something like this: “Value in link_control register is not as expected“. I was like – okay, so, what am I supposed to do now? While there are no strict rules when it comes to debugging, the process usually involves:
- Inspect RTL signals and analyse their behavior. Of course, you will not know where to look right away, but your more experienced team members will help initially. In time, you will learn exactly what parts of the RTL to investigate.
- Running the same simulation with few different seeds. This will give you additional information whether failure is seed specific (randomization issue), or is common for all seeds. If the latter, it is probably a configuration issue. In both cases of course, a bug may be found.
- Change some configuration and run for the same seed. For instance, run the test with 1 packet in total and 50 packets in total. If one of these simulations passes, and the other fails, that means there may be some specific requirement you may not be aware of – e.g. you need at least 30 packets for FIFO to start working. But either way, you will get additional information out of it.
After a few months, you will become adept in debugging, but rest assured, every new task and project will bring new challenges. And that’s why I love verification.
How to write reports
Ah, this one is one of my favorites. Report writing. Every client has their own requirements. It is your team lead responsibility to guide you and explain how to write reports. But it will still be a challenge, since you will usually have to tell a lot, with as little words as possible, since reports don’t have to containt every single detail of your work. This isn’t something you can formally learn, but in time you will develop a sense for doing it.
How to set goals, so you can focus your learning efforts
I have written a separate article for this, you can read it here.
How to know when to ask for help on task
Young engineers often strive to prove themselves, and they will work very hard to solve some problem. Now, this is perfectly fine, however, you need to know when you have to stop and ask for help. In some cases, you may be trying to do something which is impossible to do to begin with, and you are just wasting time. Maybe you’re just missing one piece of information. I cannot tell how many times I was trying to solve something for hours, just to hear afterwards “oh, yeah, for that you need to add define -ABCD in your run script”).
At the end of the day, our goal is to help launch the product to the market as quickly as possible. That means limited amount of time to solve all the problems we have. In time I have learned to detect situations in which I should always ask for help or additional information right away, as well as those when I can spend three hours debugging it. When you receive a task, work on it and when you hit a wall, make a small break. Walk around. Admire the beauty of the sun or sound of trees. Stretch a bit. Do something else. And then, if you don’t manage to solve it afterwards, go and ask for help.
As a junior, you will of course need a lot guidance initially and don’t feel bad for asking for it.
Don't be affraid of mistakes
There are dozens of quotes on mistakes, I personally like the following:
Anyone who has never made a mistake, has never tried anything new
Albert Einstein
Actually, some argue that word “mistake” is too harsh and should not be used. What I am trying to say here, is don’t be affraid to try new solutions and ways of doing your every day job. If they don’t yield results, refine them and try something new. But you will learn from the process, that’s for sure. If you are always affraid not to fail, not to say something wrong or do something wrong, you will never develop as an engineer. You will be making a lot of mistakes – get used to it, it’s all part of the career
Giving estimations
I plan on writing the whole separate article on this, as this topic is hot. 🙂
How to write code
There are many methodologies out there, which explain how to write a better code. This is something that comes with the experience, but I encourage you to activelly seek to improve your coding style. Results will come a long way. Some of the books you may want to read on the topics and which I liked are:
- Design Patterns: Elements of Reusable Object-Oriented Software
- Refactoring: Improving the Design of Existing Code
Â
The Pragmatic Programmer
Note that these are not related to verification per se, but concepts explained in them are universal and timeless.
Conclusion
My goal in this blog post was to highlight some specific skills which you as a junior engineer should be aware of. In time you will become better and better in all of them, but I really think it’s useful to posses the awareness of what you actually want to learn, so you can be proactive and seek to develop those skills all the time, every day.
If you are interested to learn more how you can become more “effective junior engineer”, feel free to contact me, and I will be glad to help.
Good luck, great career awaits!
