Category Archives: Recruiting

Simple tips for applying for a new development job

For several years, recruiting has been a part of my job in software. A few times I’ve been on the other side, looking for a job myself.

There are many low-hanging-fruit-type tips that can really make a difference when we look for a job. By making mistakes myself, seeing them made while recruiting, and by talking to colleagues, it’s now possible for me to list a few. Some may seem obvious to you — if you haven’t yet recruited, you’re in for a surprise over how common they are, and how much they affect the chances of someone getting a great job.

Learn about the company first

Before starting your application, spend no less than an hour attentively studying the company. Go to YouTube, try to watch videos involving top leadership. Read articles and learn about the people there.

Apply only to companies you care about

If you are in full application mode, apply to no more than 3 companies per day. Ideally 1 company.

If the company’s purpose doesn’t resonate with you, recognize the fact and move on.

Look at companies’ careers pages

Several companies, often the best ones, don’t advertise open jobs. They have their own careers pages and, relying on their reputations, will wait for applications.

For people who like to work remotely, Remotive’s company list has been helpful to a few people I know: https://remotive.io/remote-companies.

Don’t wait to apply

Once you’ve learned about a company and feel enthusiastic about it, apply immediately. In the global development market, good companies receive hundreds of applications on the first day or two after they post a job.

Apply to many jobs

While not applying to just any open job, do apply to as many of them as you truly like. Statistically, odds are low that you will be called for one given opportunity.

Start early

If I am suggesting you do not apply to too many positions each day, but to apply to many positions, by consequence I am suggesting you start early in your job search. Maybe practicing going through recruiting processes even before you need or want to do it can be ideal.

No spelling or grammar errors

Make it perfect in the language the company operates in. Pay someone, or a service, if needed. Great companies will quickly screen out applications that have language mistakes. By writing minimally well, expect to go to the top 10% of all applications.

Add a Github link to your CV

This is a huge differential. Prefer Gitlab or Bitbucket? Great, use your favorite. Don’t have public repos? Add repos of things you study, it’s perfectly fine. Make sure you add very good READMEs enabling visitors to run and test your repos.

Nothing like relationships

All the above may not be necessary if you have good relationships with former colleagues. You may be sought out before you need to look for a job. For this to happen, it is not enough to be very proficient at the technical part, people have to like spending time with you.

My Year in: Tech

I started the year of 2019 as a front-end developer at Toptal’s core team. Just a few days later, I was invited to be Team Lead for a brand new team.

My emphasis turned, again, to working with people. That was a delight and I fully embraced the opportunity to help build a team. We had a few company veterans enlisted to start the new team, all of whom I had not worked with before, and we needed to hire two more front-end engineers.

The first recruitment process was for an excellent React engineer. It was done very deliberately and unhurriedly, to make sure we raised the overall level of the team on the React stack. It took us a little over 2 months until we found a great guy, who has contributed a lot this year.

The second engineer was a gift to us, as he was initially hired for another team. Happy to say he’s also doing tremendously well.

We quickly became a real team. It seems we did a few things that helped: communicating a lot, admitting mistakes and ignorance openly and quickly, and being real human beings.

One teammate brought along the Personal Questions call from his previous team. This call has a simple structure: one team member asks one or two questions, personal as the name says, to everyone on the team.

The questions are as simple as “What was the best trip you ever took?”, or “What is your favorite dish?”. It’s up to the team to let this call become just a little window on who they are, or a huge gateway to people’s souls. Yes, it’s possible to cry while listening to someone tell you about their favorite food once they tell you the story behind it. The bond I felt with the team was immense.

Dedicating at least one or two hours per week of each team member’s time to building rapport makes a big difference, particularly in new teams. Next year I will work to learn more ways of doing that.

I made my share of mistakes. The one that comes strongest to mind is about having patience before giving feedback to people you may like personally but don’t think are doing a good job — especially when they are not reporting to you. Convincing people to change is hard enough as it is, doing it without mutual trust and knowing their motivations is likely to backfire.

Another lesson I was reminded of by a mistake of mine is the “no surprises rule”. It’s often hard to know, in advance, how sensitive some task or decision may turn out to be. Next time something I do starts to deviate too much from what was agreed-upon, I should remember to share that early on, and avoid surprises, because the surprise itself may make people react negatively to something fundamentally desirable, or I may have the wrong assumptions or decisions and other points of view will help me see that.

I stayed with the team for a total of 9 months, we launched a good chunk of the new application we were developing, and then I was enlisted to start a new team from scratch: to recruit every single engineer, and help recruit designer and product manager.

It was painful to say goodbye to a team I loved so much.

Soon it was back to recruiting, this time a few weeks of full-time effort, and we are still at it. We seem to be close to hiring two people, and have one more front-end and one more QA person to bring onboard on the engineering side.

This recent team switch gave me time to study programming after a several-month hiatus. I am focusing on new React APIs, from Hooks to Context and Suspense, as well as testing, TypeScript and, soon, Apollo.

I did continue to study the Elixir language source, something I’ve done for maybe 3 years now. This year I did relatively little of it. I love Elixir just as much as always, and am thankful for having learned so much from its community.

I plan to go multi-team as soon as I have a chance, be it in an Engineering Manager or CTO role. Thus I dedicated more time than ever to reading about leadership, management and communication, often with a big emphasis on tech. Especially for people who are new to management, I recommend The Making of a Manager by Julie Zhou.

A personal take on interviewing programmers

A few months ago some members of the team I lead at Toptal’s core team started interviewing programmers.

The fundamental questions that popped up were simple and deep: What should I look for in the interviewee? How do I know I should pass or fail the person?

I really like the priorities my own former supervisor, Timo Roessner, advocates: to look for—in decreasing order of importance—a team player, a good communicator, and a technically excellent person.

The person should ideally be very good at all 3 requisites. The main point, however, is deemphasizing technical wizardry in favor of interpersonal skills.

How to assess team-playing chops in a 90-minute interview with a coding challenge

Team-playing chops and communication chops seem intermingled, and in fact I believe one potentializes the other, but they can be assessed quite separately in software engineers.

As you facilitate a coding challenge or nearly pair-program with the interviewee, try to make it as close to the interviewee’s normal workflow as you can. Don’t use CodePens, have the interviewee use the editor or IDE of her preference. Apart from the technical things you need to evaluate her on, encourage her to use her favorite tools and procedures.

What you need to evaluate the candidate on is up to the needs of your company or team, but in general I prefer to give the candidate a wide-open small project instead of some algorithmic or procedural task. The reason is you will get a chance to role-play being the customer or Product Manager, and you can talk to the interviewee as such and see if she is able to conduct a dialog like this.

Calibrate, as you go along and get a sense of the candidate, how high-level or low-level it’s better to be. That is, is this person more concerned about the coding nitty-gritty or about what the entire project should do? Both are fine and necessary programmer inclinations, but the quicker you spot the candidate’s preferences, the quicker you can develop a rapport.

As the coding challenge starts, pay attention to the questions and shared thoughts. It should be clear to you, given some experience, if the candidate has mileage or a willingness to openly express thoughts. If they don’t say anything at all, probably this person will behave the same way at work.

Avoid, or delay, “helping” the candidate. Generally, in a coding challenge lasting 1 hour, I may interfere 1 to 3 times. But when you do, try to make it very meaningful and make it so that the proposed change of course really takes things in a different direction.

For example you propose the programmer develop a simple game. She starts by crafting the algorithm that will define if the game is over. As the interview goes past half its allotted time, and if the candidate has shown a good direction regarding the solution, propose she create the UI (if she is a frontend developer), or suggest creating a way to store a leaderboard (if she is a backend developer).

The way the candidate reacts to such proposals can be telling of a team player.

Also, very often candidates will do or say things that you don’t know anything about. Tell them you don’t know anything about that and see how they react. Do they explain it to you? Are they surprised? Do they convey a sense that they respect you less for that? But don’t pretend you don’t know something you know—you don’t need any trickery to interview people well.

How to assess communication chops

Assessing communication skills is a bit easier than assessing team-player inclinations. Start with the basics: can you even understand what the interviewee is saying? Often that is not the case. If and when you don’t, tell them that in a gentle way. This happens particularly often in international interviewing when spoken languages are not native to you or the candidate.

The opposite can happen: the candidate does not understand you. You should, of course, try your best to communicate clearly, and if the candidate still has a hard time getting what you are saying or asking, notice if they have the energy to ask you to clarify. If so, that is a good sign.

Being able to listen deeply is what differentiates an ok communicator from a good or great one. Does the candidate flow from what you are saying? In other words, can you notice them using and reshaping pieces of your discourse? Repeating things back to you transformed? Those are good signs. If they just respond things that seem unrelated to what you have been saying, then clearly this is a minus. More often things fall around the middle, and with time you will develop a feel for how good the candidate seems to be, plus the courage to use your intuition when the decision is not clear-cut.

How to assess programming chops

This is the easiest part if you yourself are a programmer, but it’s still challenging sometimes. Granted, it’s easy to reach a conclusion in extreme cases: if the candidate did really poorly or just brilliantly in the coding part.

When things fall more in the middle, which is by far the most typical, your skill can make a huge difference in the decision to say Yes or No to a candidate.

I always like it when a candidate writes, in human language, something like a list of things that need to happen in the program. For example, if the proposed task is to build a search user interface: to jot down that the screen has an input and a submit button, the user will type a string in that input, then press the submit button, and so on. This helps the candidate “think like a computer”, it allows her to expose her thought process to the interviewer and, if her assumptions are off-base, to know early. The worst that can happen is to end up with a little algorithm of what to code.

TDD, or anything similar to that, is a huge positive differential. It is a kind of planning ahead.

I must say it’s very rare that anyone uses TDD in interviews I run, and I’ve run a few hundred of them at the very least. It has never ever happened that a candidate wrote down point by point what should happen in the application.

Finally, good code architecture early on is one of the strongest signs that the candidate is good. If they refactor continuously, improve variable names often, and order things in their codebase without losing their train of thought, you are looking at a hire. And that’s why giving people much harder tasks than they will face in their work is typically not a good idea: you need to see how they can make code understandable to fellow programmers.

So if they start one file and fill it up with disorganized, commented out code and huge blocks of attempts, unless you asked them to do something too hard, in general consider this as a potential flag. But don’t get stuck to this: it’s not uncommon for great developers to seem quite sloppy the first 15 minutes in, and 10 minutes before the hour, to start deleting code and apply a final layer of improvements that leaves the code looking quite wonderful.

If you give the candidate a project that is larger than the hour you have to interview, something I support you do—as long as you set the right expectations, otherwise you will have a frozen person in front of you—, and you enabled the candidate to own the code in her machine, the bonus point is them continuing the project on their own. Until recently I sometimes suggested they do it. Nowadays I don’t even suggest that. If they have a way to reach me, they can do it if they want. I certainly take it as the strongest sign of interest in the part of the candidate if, hours or even a couple of days later, they get in touch with the completed project.