Aligning needs and opportunities in the workplace

Careers and Employment Journal

Subscribe to Careers and Employment Journal: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Careers and Employment Journal: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Careers Journal Authors: Mat Rider, Hiren Y, AppDynamics Blog, SmartBear Blog, Lacey Thoms

Related Topics: Careers and Employment Journal, MySQL Journal

Blog Feed Post

MongoDB Certified Professional Spotlight: Ulrich Cech

This week in our MongoDB Certified Professionals Blog Series we’re talking to Ulrich Cech, a Developer/Architect at Deposit Solutions in Hamburg who became certified as a MongoDB developer in 2016. A longtime lover of IT and programming, Ulrich discusses how he first discovered MongoDB, how it compares to relational models, and why he believes getting certified keeps you in the Big Data loop.

Ulrich Cech, MongoDB Certified Professional

EG: Hi, Ulrich! Let’s start by discussing how you got into tech; what interested you about the industry? What do you like about your role at Deposit Solutions and what inspired you to become a developer and architect?

UC: IT and programming have always been my favorite hobbies; I like programming because with little environment and minimal limits, you can construct awesome things. It’s kind of like building your own small universe, which behaves according to your design and desire.

My first job was at a software company that focused on foreign trade and German customs. It was a very cool company in Stuttgart, and I was able to learn a lot working there. Currently, I work at Deposit Solutions in Hamburg as developer/architect, specializing in the real estate bond area. Since moving to Hamburg, I’ve had the opportunity to work on some very cool projects. In my role, I try to help to think about using the right architecture and design for the given domain, project, or product.

What most inspired me to become a developer and architect was a desire to avoid “cargo cult programming.” The latter has been one of the biggest problems I’ve encountered in projects; essentially someone says “we need framework A and library B and architecture C” because they’re new and exciting, but no one considers whether or not this structure will actually fit the current problems. This lack of planning results in tremendous code production, which in the end turns out to be completely useless.

EG: How did you first discover MongoDB? In what projects have you used/are you in the process of using MongoDB?

UC: I first discovered MongoDB at DreamIT GmbH in Hamburg, where it was used for a gaming platform. I had heard of NoSQL databases before, but my background was in the relational world. When I first saw MongoDB in action, my immediate thought was, "That cannot be real, that is too easy.” After working with the database, I grew to like it more and more; what specifically impresses me is that you don’t have to "convert" or change object-oriented thinking as you would with a relational database.

At Deposit Solutions, I am interested in employing MongoDB for a new Microservices project. As for my private projects, I use MongoDB in conjunction with Morphia as a document-to-object-mapper; I like that MongoDB enables an easy setup and the perfect match with domain-driven design.

EG: What other databases have you worked with, and how does MongoDB compare?

UC: In my former projects I dealt with Oracle, but it was mostly abstracted via Java Persistence API (JPA). Currently, I have to deal with MySQL, which is not fun. PostgreSQL is also a database I’ve worked with, and it is my favorite database to use when I’m required to use a relational database.

What I like about MongoDB is that it is incredibly easy to use. You can set it up in no time, even as a cluster on a local machine, since there is no complicated setup and installation process. Another great advantage is that you don't have to split your domain objects into relational thinking. Instead, you have your domain object and you can (nearly) insert this one-to-one into your database. And finally, you don't have this awful time-consuming process of schema updates, because MongoDB is schemaless. Sure, you should use some kind of structure, and shouldn’t put everything into one collection ;-). But if you decide to change a field for your data type, or add or remove a field, the operations don't require you to change databases.

MongoDB does lack transactions across multiple documents. In most situation, the need for transactions is due to the relational design, so this can mostly be avoided in MongoDB completely. But in some situations, you need multi-document transactions. I hope these transactions will be introduced in upcoming releases – I know it is a high priority topic for MongoDB ;-)

EG: What inspired you to become MongoDB certified?

UC: I like to prove my knowledge. In general, certifications show one’s personal ability to constantly self-educate. Unfortunately, there are many certifications out there, which usually cost a fortune. But MongoDB’s certification prices are affordable. Plus, MongoDB is relatively new on the market, so a deep knowledge of the database can be helpful in the future when it comes to new job opportunities.

EG: What was challenging about the courses and what was rewarding?

UC: The course I took – M101J: MongoDB for Java Developers – was well structured and provided a good starting point to learn the basics; topics like the aggregation framework, for instance, though challenging information to absorb, can be extremely powerful. But the courses alone should definitely not be your only means of preparation. Those hoping to be certified need to read the official documentation for MongoDB and for the individual courses in order to ensure that they can work fluidly with the database. The more you query and play with data, the more familiar you can become with all the features of MongoDB.

EG: Since becoming certified, what have been some of the benefits, personal or professional, that you’ve experienced? How have you applied – or how do you intend to apply – what you’ve learned to your future projects?

UC: Well, on a personal level, it is always a good feeling to be certified ;-). Unfortunately, in my current work projects, MongoDB is not being used. But like I mentioned above, I am actively trying to introduce it into one Microservices project.

When it comes to things like sharding and clustering, you have to understand how to correctly set up and employ these concepts. Because of this, the knowledge absorbed through preparing for MongoDB certification is a great benefit. But there is more to this, too. For successful MongoDB usage, you cannot adopt the old relational thinking.Thorough knowledge of domain design in the database comes with experience, either through projects or through playing around in a private environment, wherein you can test things and find the right solution for the right use case. MongoDB’s certification offers the necessary and fundamental platform to begin to gain this experience.

EG: Looking back now, can you share any advice for those studying for (or retaking) their exam? Are there any specific preparation strategies you found useful?

UC: Personally, I think the best strategy is to educate yourself and learn as much as possible. I know this sounds self-evident; it is. But the more you know and the more knowledge you have, the easier it is to answer questions. Like I touched on previously, you shouldn’t rely solely on the courses. They are a good starting point, but you need much more in-depth knowledge. It’s a must to read the official documentation; there are many use cases described in depth, which are very helpful.

While preparing for the certification exam, I also read through the MongoDB Definitive Guide, which I found very helpful. The guide’s third and most updated edition is forthcoming this year.

Finally, and perhaps my most important suggestion: Use MongoDB, query the database, and create indexes, analyzing if and how they perform. Use the Aggregation Framework, trying to think of some questions your datasets can answer, and build these queries and pipelines on your own. Model multiple domains and think about how the data will be best stored in MongoDB. Set up a replica set, even a sharded cluster, and add and remove nodes. The best strategy is to get hands-on knowledge of the database.

EG: And finally, what has been your greatest takeaway from your experience getting certified? Why would you encourage others to pursue certification?

UC: I think my greatest takeaway has been the confirmation that knowledge can never be bad. MongoDB is often used in the Big Data environment, and this domain is becoming increasingly important in the tech community. Because of this, demonstrating experience in this domain can be critical to finding a suitable job opportunity. And finally, it doesn’t take a lot of effort to become certified. As I mentioned, you don't have to spend a fortune, and if you prefer, you can take the courses and the exam at home and on your own time. For me, this was absolutely great and time-saving.

Thanks for sharing your story, Ulrich! If you’re interested in getting professionally certified, you can learn more about the MongoDB certification process. If you’re already certified and would like to be featured in a future blog post, let us know at [email protected].

Read the original blog entry...

More Stories By Mat Rider

MongoDB is a document database with the scalability and flexibility that you want with the querying and indexing that you need.