The Developers Conference

- 3 mins
event-sourcing recruiting process

This month I attended The Developer’s Conference in Sao Paulo together with my ThoughtWorks friends from Brazil. There, I presented three different sessions in three different tracks: Microservices, Startups, and Agile.

Event Sourcing & Microservices

Microservices are becoming mainstream in the last few years, specially after Sam Newman’s book. When it comes to both building new systems from scratch or decomposing legacy monoliths in smaller pieces, this architectural style gives you interesting advantages like deployment flexibility, technology heterogeneity, and governance decentralization.

However, in the traditional microservices approach based on REST over HTTP, there are challenges like performance, data consistency, distributed transaction management, and also the limitations of the HTTP protocol methods to represent user intent.

With Event Sourcing you describe the application data as a sequence of immutable domain events. Those events are caused by the execution of custom commands which represent user intent. In this scenario, microservices communication happens asynchronously by the broadcasting and listening of events. That style gives you important architectural advantages like auditing capability, historical analysis, and global consistency. These features are specially useful in domains like banking, for instance.

Based on recent experiences in the dense U.S. banking domain, I presented to the public a short summary on how Event Sourcing combined with Microservices was a successful solution to my team. The presentation included basic concepts as well as a description of technical aspects like CQRS, infrastructure, and technologies. Here are the slides (Portuguese only):

Interviewing Developers

It would be ludicrous to think of hiring a juggler without first seeing him perform.

DeMarco & Lister, Peopleware.

When it comes to recruit developers, the traditional approach with paper resumes, oral interviews, and whiteboard puzzles is seldom good enough to determine whether the candidate is a match or not. Instead, it is often more useful to put candidates to exercise their skills in a close to real world scenario.

For that to work, we need to setup an adequate environment and perform activities which would give the candidate a chance to experience realistic situations. Even though sometimes this is something hard to go about, there are some strategies you can adopt in order to simulate a good enough setup for technical interviews.

In the last decade, I’ve been interviewing a lot of candidates for ThoughtWorks and I’ve watched our recruiting process evolution closely. In this talk, I shared a short summary of that experience to the public, including highlights of what the relevant literature says, targeting technical interviews for developers. Here are the slides (Portuguese only):

Interesting fact is that this is the fourth time we speak about this topic publicly, which is a sign of interest from the public. The other appearances are:

Feature Leads

Have you - developer - ever felt your tech lead becoming a decision proxy or a information bottleneck? Have you - tech lead - ever felt overwhelmed with the amount of management activities and context switching? Feature Leads can be a good alternative for you, specially if you are in medium to large team with a medium to large backlog.

This was the topic of my last talk in the last day of the conference, in the Agile track. Based on the original Feature Lead/Champion idea described by Pat Kua and Ryan Oglesby, I described to the audience some recent experiences some of the teams I’ve been working with had with this technique. Check out the slides (in Portuguese):

Videos of all the conference talks can be found here. They aren’t free though :(

Related Posts

Vinicius Gomes

Vinicius Gomes

Software Developer

comments powered by Disqus
rss facebook twitter github youtube mail spotify instagram linkedin google pinterest medium