Forem: SinnerSchrader Engineers

Getting hired after finishing a coding bootcamp

SinnerSchrader Engineers — Wed, 27 Oct 2021 09:51:59 +0000

This article was written by Sandra Gläsner (Director Product Engineering).

If you've decided to reshape your career and successfully completed a coding bootcamp, you're probably now facing the challenge of finding your first job in a completely new field.

I'd like to briefly share my experience as a team lead who has had an increased number of applications from bootcamp graduates on her screen over the past few months. Maybe you can take something from this for your future applications and interviews.

1. Tell your career story

In his resume, an applicant (now colleague) once added a short statement to each of his previous job stations about what his motivation was. This created a coherent picture of what drives him and made it easy for me to understand why he developed his career the way he did.

Your decision to take a new career path in (web) development will definitely not have been made on a whim. Find the common thread that underlies your decision and tell your very personal story.

2. Reflect your personal strengths and interests

Most of you have learned the same content in the same short amount of time. I have seen many practical final projects that were very similar in terms of implementation. This is because of the nature of bootcamps, which usually teach a specific, narrow curriculum.

But that makes it very difficult for me to distinguish between the different applicants and their strengths. And this is where your personal experiences come into play: tell me why you chose this masterpiece, what you had difficulties with, or what you found particularly easy and had fun with. Maybe you liked the setup of build and deployment pipelines more than everything else? Cool! Or did you fall in love with the styling part? Wonderful! Or did you spend much time on finding out what best practices are used in terms of web accessibility? Nice, tell me more!

Reflect your learning path and where your strengths and interests lie.
And finally…

3. Decide what you want (to learn next)

A bootcamp can always be just a start. Think about what you have been missing in the bootcamp or what you would like to learn more about. Please don't be afraid of the vast amounts of knowledge you think you still lack. Be patient with yourself and take one step at a time.

My mentoring journey as a mentee (so far)

SinnerSchrader Engineers — Wed, 01 Sep 2021 12:29:53 +0000

Illustration by Casey Schumacher.

Mentoring connects experienced and entry level developers in order to provide some kind of personalized training and exchange for early career programmers. It frequently happens in the sphere of a company as an educational initiative for employees, but it can also happen outside of a company. At SinnerSchrader, we initiated, as we like to call it, a mentoring support group. Colleagues from various backgrounds take care of kicking off new pairings and offer their help along the way.

Mentoring can take many forms and is super diverse which is why we asked mentors & mentees to talk about their experiences.

This article was written by Alice Grandjean.

A mentor as Google defines it, is “an experienced and trusted adviser”. A mentee is someone like me! In this case, a junior developer with her head full of questions. It was a unique chance for me to have a mentor, but the mentoring process was not so linear to set up. This article is a small insight from my experience of being a mentee.

Part 1: The start of the journey

When I joined my company, I was not familiar with many aspects of the developer’s usual journey. I had some technical knowledge learned in an online bootcamp and I had some work experience collected in a previous company, but I used to always learn things the hard way: self-teaching. Mentoring was quite a foreign concept for me.

It took some weeks until the first mentoring session took place. My mentor and I were working on the same project. At the beginning, we kept our meetings casual and met every now and then. We mainly talked about the tasks from our common project. We would often pair program, go through programming solutions or discuss core concepts of JavaScript.

This situation went well overall. As a junior developer I was quite inexperienced and I enjoyed discussing my tasks with someone. Sometimes if we were in a rush, we would define a “period of exchange” where we would meet before the daily every day for 15 minutes. I much appreciated the flexibility of the team and the patience of my colleagues.

Six months ago, I got a new project and I had to pair with a new mentor. We were not working on the same project anymore. We decided to establish a different structure for our meeting: we would meet for one hour every week. I also decided to plan a little bit more in advance the topics of our meetings and I set up an agenda for it. That also helped me to keep track of our discussions.

Part 2: A well-designed frame for the meetings

I think the frame of your mentoring meeting is very important. As mentees, we should keep in mind that we are equally responsible for getting the most out of the meetings. I understood that eventually and I would come up with topics or precise questions to put on the agenda. My mentor would give me a new perspective on these topics and as I was keeping notes of them, I could easily go back to them later.

It worked very well. I can share with you the agenda we usually followed:

1) Opening questions: How are we doing? How are our projects going on?
2) One thing we learned this week
3) Blockers we experimented
4) Pair programming session
5) Exchange on tech news, tech speakers, Youtube channels

We would not go over all the points in one session but spontaneously decide what would make more sense to do.

This weekly one-hour space turned out to be very helpful for me. It was like an available window focused on me for specific questions. It forced me to gather topics and have a deeper look into them. It was also very beneficial to exchange views on a programming issue or the implementation of a feature. It happened many times that I had a different approach than my mentor. After discussion, I would see the task in a new light, and I would see possible solutions that I didn’t see in the beginning.

Part 3: Content of a session

In my opinion, pair programming brings the most valuable experience on the mentee’s side. It was also probably the hardest thing for me to ask for as it took me a lot of mental load. When you pair programming you cannot hide behind your computer, you have to find new ideas fast and you have to admit you don’t know when you don’t know. That is not so easy to do at the beginning, but I got used to it. I would really recommend using the extensions from VS code: Live Share and Live Share Audio. It’s great because it allows people to work on the same file simultaneously: each person can write code and “follow” each other in real time.

The best examples of pair programming we used to do were katas from Codewars. The word “kata” comes from Japan. It refers to a detailed choreographed pattern of martial arts movements to memorize and perfect alone. In the programming world, a code kata is an exercise which helps programmers master their skills through practice and repetition. Codewars is great because it clusters the katas into categories and levels of difficulties. After resolving a kata, your solution is saved and you gain access to the solutions found by the community. This offers the possibility of comparing the solutions between each other.

Recommendations of a fun kata: https://www.codewars.com/kata/57b4da8eb69bfc1b0a000b44 :)

Below you can find more topics from our meetings:

Tasks from the project (ticket, bug, blocker…)
Personal project (application, website…)
Katas
List of skills
Javascript challenge e.g.: https://javascript30.com/
Preparation of a small tech presentation
Conceptual questions: JS / Typescript / React / API / Node / architecture…
Reaction over Dan Abramov’s newsletter regarding Javascript mental model: https://justjavascript.com/
Discussion over some YouTube channels (this list sadly only has male youtuber, please feel free to share with me non-male tech youtubers):

Syed Maaz Ali Shah https://www.youtube.com/channel/UC5tOulpb9kv_87ZCW1S0XMA
Ben Awad https://www.youtube.com/user/99baddawg
Will Sentance Codesmith https://www.youtube.com/channel/UCAU_6P-M2VHKePIpu5736ag
Brad Traversy https://www.youtube.com/user/TechGuyWeb
Colt Steel https://www.youtube.com/channel/UCrqAGUPPMOdo0jfQ6grikZw

Part 4: Community & support group

I strongly believe that belonging to a community or a group can be very beneficial for a junior developer. In this time of remote work, it is easy to feel isolated and disconnected from each other. It can help to find a support group.

My company is quite big and the management set up a monthly meeting with every new junior developers. We would talk about our experiences and try to help each other out on difficult tasks or difficult situations. I really enjoyed these meetings. It was a time of self retrospection and a safe space to exchange. I realized most of us shared the same everyday challenges. Most of us also experienced what is called “impostor syndrome”. It is a psychological symptom where people tend to excessively doubt their skills or accomplishments. For me talking about all these sensitive topics was relieving. It also helped me to find new ideas for my mentoring sessions.

On the side of the mentors, the same kind of meeting happened as well in order to discuss ways to improve the mentoring process. I found this mirroring initiative great!

Conclusion

When I look back, I can see mentoring accelerated my progress curve faster than I would have thought at the beginning. I feel lucky to have found two amazing mentors. Besides positive outcomes like knowledge sharing or skills development I could feel our team spirit growing.

In conclusion, if I were to meet the “me” who started the beginning of her career 18 months ago I would say these things:

Be active (ask for mentoring and define yourselves the frame of your mentoring time)
Be patient and persistent (don’t try to learn everything but learn small steps at a time)
Be shameless regarding communication (if you think: “should I ask someone” stop thinking and ask someone)
Work on your technical communication skills
Keep track of your successes, failures, achievements
Measure your progress (in 6 months how would you see the same issue)
Keep yourselves up to date: reddit, hacker news…
Get inspired of people (your mentor, your colleagues)
Open yourselves to others when doubting
Look for a mentee community
Say thank you to the people who helped you grow

========================================================================

Ressources:

Live Share: https://visualstudio.microsoft.com/services/live-share/
Kata website: https://www.codewars.com
30 days Javascript: https://javascript30.com/
Javascript newsletter: https://justjavascript.com/
Youtube channel from Syed Maaz Ali Shah: https://www.youtube.com/channel/UC5tOulpb9kv_87ZCW1S0XMA
Youtube channel from Ben Awad: https://www.youtube.com/user/99baddawg
Youtube channel from Will Sentance Codesmith: https://www.youtube.com/channel/UCAU_6P-M2VHKePIpu5736ag
Youtube channel from Brad Traversy: https://www.youtube.com/user/TechGuyWeb

Be a yes-woman

SinnerSchrader Engineers — Wed, 07 Jul 2021 13:13:20 +0000

Illustration by Linda Gobeta

This article was written by Jana (Director Quality Assurance) for our internal International Women's Day website.

Editor's Note: Being a yes-woman is great, however, it is important to pay attention to your bodies’ signals and be a no-woman if this is what's best for you and your health.

We hear and read about strong women with great careers and achievements and want to be like them. We want to be strong-willed, confident, and successful. And if we hear someone who says they don’t want these things, then we think they’re lying.

Not everyone needs to be a career-driven person but imagine having those personality traits in other areas of your life…

Most of us are not confident enough to march into the boss’s office and ask for more money because we deserve it. Most of us are not stubborn to the point that we get what we want, to say our own opinion even if nobody else agrees. That is okay.

To change that is hard, but we can start with a simple step - saying yes to opportunities.

The “Yes” got me pretty far without years of worrying that I didn’t have enough skills or that I am not a good fit for the role.

I remember working as a receptionist at a small firm. It was the only thing I could do after graduating high school with no specialization. I remember getting a warning and losing bonuses after I arranged milk in the wrong way. Oh, those old times…

I made a lot of friends in the IT department and one day one of them came to my desk and said that he had just had an interview with an IT manager. They agreed that the role was too junior for him but he promised them that I would send them my CV and would interview for the role!

You can imagine my reaction. However, I said yes.

I studied books for two weeks, I googled a lot. And after a two-hour interview, I got the job of a junior tester.

The most important thing wasn’t the books. It was the “yes”.

After four years I started being pretty unhappy because I couldn’t find any common ground with my boss. It escalated so much that I found myself sitting with his boss and trying to solve the situation. Meanwhile, I was socializing outside of my project with other colleagues at the company, and one day another friend came to me, and, knowing my situation he suggested that I should change the project. He had changed his project a couple of months ago and was happy with the change.

He told me that one of the project managers was looking for a Test Manager for a new project which was about to start.

Wow! That was a role I wasn’t expecting to be in my career for another two years.

I found myself sitting in the meeting room with an infamous project manager in the company at that time (she’s still a badass there) where she was explaining her vision of my future work: come up with a test strategy, analysis, staffing my own team, leading the testing of two teams, and be a spokesperson for the client in any testing discussions.

After all this, she turned to me and asked me a simple question:

“Do you have the courage to do it all?”

My heart was pounding, I was sweating like a pig, in my head I was panicking. I didn’t have any idea about half the things she was talking about.

However, I said yes.

Another period of books and googling was awaiting me. This time I had two months before the project started.

I wrote a pretty good strategy for a newbie, I staffed a very good team that soon became self-sufficient and I advocated for our project team in front of the client.

The client was a tough one. The Test Manager on the client-side couldn’t accept that there was a young girl in the same position as him. He didn’t acknowledge me at the meetings for at least three months. I remember a lot of funny situations. Thankfully, our team was perfectly aligned about responsibilities and when he tried to get around me, he couldn’t. Soon, he learned to deal with me.

After two years I decided to leave the company and I came across a job ad for Head of Testing. Challenged and motivated because leadership became my favorite topic I sent in my CV.

The role was completely different. No project, no testing. It was a pure management role with a team of 50 people. I had a lot of interview rounds with the owners of the company and with sales and they were struck that I was not afraid to scale my experience from 5 teammates to 50.

I was afraid, a lot. This wasn’t about leading a defect meeting. It was about pitching to clients, sales, budget handling, hiring and firing, strategy and vision, KPIs, and decision making which could influence the revenue of the company.

I believed in my “yes” rule and I also recognized the only risk here: If I screw up the worst thing they can do is to fire me. Being in IT I knew I could get a new job in a week. I realized the risk is not that high.

So I said yes again.

It was a hell of a ride. I had no time for adjusting. In two weeks I was running in “production”. The start was so clumsy that I had to deal with the consequences the whole year I was working there. Especially with the team, I had to fire seven people in the first months. I had to come up with a strategy for how to get the competence into green numbers, I had to come up with a solution on how to handle 50 people because doing so by myself was insane. I won my first pitch, I came up with 4 new products to sell…

I burnt out four times during that year. My doctor was convincing me to leave when my stress level didn’t ease after a week of vacation.

However, this “yes” was all worth it. I learned a lot.

I left after the year due to my health and also due to some decisions of the owners I wasn’t in agreement with. I found a good, calm position at SinnerSchrader as a Director where I partially work on a project and I have a small team. The company lets me indulge in various topics as leadership, diversity, or mentoring when I want to. There hasn’t even been a day of stress and it’s been a year. :)

What to say to summarise? We can be scared, we can doubt ourselves, we can lack the self-confidence of successful top managers, but saying yes despite that is powerful and it gets you far. The opportunities will open before you and you’ll find out that there is nothing to be afraid of, there is a strong will inside you, and that in the worst case you will always manage to find the light in the tunnel and get out.

Say yes from the heart. Say yes to everything that you always dreamt of, or what seems to be interesting. It is worth it!

My Open Source Journal

SinnerSchrader Engineers — Tue, 15 Dec 2020 15:05:28 +0000

article by Mauricio Palma

Where am I coming from

One of the fields that I love the most about software development is the field of research and development. Usually, I pick or receive a topic and dive straight into it. I conduct studies, develop experiments, and all the fun stuff that reminds me of an alchemist looking for the formula to create gold. Other times it might feel a little bit more like Victor Frankenstein on his quest to create life.

Anyway, I continue iterating and validating my hypothesis until I find a feasible result. At the end of such a process, I usually end up with a small application or library as a validation of my research. I enjoy helping others to save time, benefit from it, and love to share my work. This is why I put it up on GitHub, feel all proud, and think to myself, I’ve created an open-source project!

Time went by, and I realized that my projects might be open source, but nobody is contributing to them, no bugs are being filed, no discussions are being held. There is not a community behind it. I started to wonder, why is that?
I had the great opportunity to showcase my work at some abroad conferences and expected that this might be the opportunity for me to gain contributors and create a community behind those projects I am so passionate about. But, no matter how hard I stared at the GitHub stars, contributors were still missing.

One day after a meetup in Berlin I met Ola Gasidlo, who is a principal software engineer with year-long experience in open source. She was willing to help me and take a look at what is holding contributors back. This is the journal of our journey diving into the world of open source from a research and development perspective. We used the Docfox project as a baseline.

Day one - The brainstorming

It has been around 10 weeks since I’ve been isolated because of physical distancing, and I am very stoked to have my first meeting with Ola. Honestly, I’ve been looking forward to this meeting for the whole week! The virtual chat has been set up, we are both preparing our coffees concurrently and having an incredible friendly chat. Creating a collaboration space where people feel comfortable and are having fun are the best requirements to get the best ideas going. 10 minutes into the call, and I realized I already had 5 pages of notes. There are several aspects I need to consider for my open source projects. Today I will give you a bird's-eye perspective of what these things should be.

Project 💜 contributors

Our role as project maintainers is to make contributions seamless, accessible, and a place to learn. This should become a place of inclusiveness, empathy, and collaboration around the projects we are building. We want to foster a healthy environment. Below you will find some bullet points of this bird-view and we will get into more detail in the next couple of days.

README.md
- What is the project about?
CODEOFCONDUCT.md
CONTRIBUTOR.md
- Developer onboarding
  - Install
  - Development
  - Testing
  - Linting
- Badges
  - Testing coverage (This is really important)
  - Build (pass / fail)
  - Deploy (npm / yarn in case it’s a released package)
- Issues
  - First PR - issues for people who have not previous project experience and very little experience in open source.
  - Starter - issues for engineers with some experience in open source projects.
  - Regular - create a template of the expected outcome (issue template)
Communication Channels
- Support
- Mentoring enablement
Website
- Guides
  - written in simple, inclusive language

Before we move on into the fun parts we have just discussed, I’ve learned that having an open-source project in a mono repository could prevent amazing people from contributing. There is a cognitive load implicated with larger codebases that are not directly related to the project itself. In other words, the time has come to move the Docs package into its own repository. We are splitting it from woodlike/wdlk to woodlike/docfox.

Day 2 - The README

The sun is shining, summer is full-on and we continue to practice physical distancing. The core functionality for the Gatsby Documentation theme has been written and I can finally show my progress to Ola. So far I can parse the MDX documents using the MDX compiler and Babel during Gatsby’s build lifecycle.

It has been such an eye-opener to realize that if we think about the README we are actually thinking about the user. Let me elaborate a little bit more about that. In the past, I’ve always had a combination of how to get the project running (deep inside with the hopes for someone to actually contribute to the project) and, how to consume the project. And that is by the way not quite right.

A lot of people will come to the README trying to figure out what exactly the project is. Our job is to explain what the project does and why it exists. Besides that, it should include all the necessary information required for the user to use the project as easy and frictionless as possible.
So, what does a README actually need? Below you will find the minimum bare bones of what the project requires:

Title
Description
Badges
1. Build
2. Test coverage
3. npm/yarn (optional)
The smallest code snippet you need to start/integrate the project
Documentation link
Support channels
Roadmap
1. Top feature requests
2. Top bugs
3. Newest bugs

The Description

Time flies by and we only have 10 minutes left in our meeting. I thought, can we please do the description together, and guess what? We did. We used the german “wer, was, wie” technique, which basically means “who, what and how”. The description should include no more than three sentences describing the project and the problem it solves in our case would be something like:

Docs is a Gatsby theme that programmatically generates visually polished and interactive technical documentation using MDX and Babel.

Let’s be clear on what a domain is

SinnerSchrader Engineers — Fri, 04 Dec 2020 13:44:54 +0000

by Daniela Kirchner

Being clear and precise is a main advantage of coding language. Compared to the clarity we lack in our spoken everyday language. It is very hard to use the precise words and expressions to make them understood in the same way it was meant.

I am a Digital Strategist and one of my jobs is translating. Not literally, but as I want to make sure that everyone in a team shares the same ambition, I heavily push for a shared understanding.

Recently we were talking about domains. I recognised that different things were mixed up: platform, URL and field of expertise.

If you look on Wikipedia, you’ll find various disciplines that make use of the term domain.In information technology there are several subterms such as application domain, programming domain or network domain. And of course, the topic goes beyond. Domain-driven design, for instance, is worth its own examination.

This broad field raises the question of if there is a common origin for the term itself. According to the Oxford Dictionary, the late Middle English “Domain” stems from the French “domaine” of Old French “demeine” for “belonging to a lord”.

This proves especially interesting as the word itself is a contronym: “domain” combines a meaning of both relatedness and separation in one.

Therefore, communicating a clear meaning of “domain” is imperative. I push for this definition: A domain is a distinct subset that specifies a particular field and relates to a certain owner.

However, The Oxford Dictionary’s definition is important for providing a baseline understanding for our field: domain is “a distinct subset of the internet with addresses sharing a common suffix or under the control of a particular organization or individual”.

The definition is very important. We need to be aware of it when we change the information architecture, adjust the hosting, compile backends, migrate URLs or define touchpoint strategies.

What do you observe when people talk about domains?
What are the fallacies you see?
Which other terms require clarification?

An outsider's view on the state and future of testing

SinnerSchrader Engineers — Wed, 21 Oct 2020 12:05:10 +0000

This talk is not from myself; I'm sharing it on behalf of my colleague Yorck.

About the talk

Yorck talks about the core insights from the scientific study published in the book Accelerate on how to build and scale high-performing technology organisations. In his opinion, the results of this study form a new 'north star' towards which organisations will need to align. After a general introduction into the study, he tries to reflect what it could mean for the discipline of software testing.

[pro:]TEST!

The talk was presented at and recorded from [pro:]TEST! a meetup in Czech Republic around testing.

Feel free to leave comments on youtube or here.