doryz

How to Remote Debug Node.js

Finding and fixing bugs is not always easy, especially if someone else wrote the code!

I know that engineers in general have NIH syndrome, but I am one that doesn’t share that view. Technology is an enabler, meaning it’s not an end goal, it is there to provide a service (or at least that is how it is most of the time).

As such, we must sometimes make fixes to our code, or to other people’s code, and that requires debugging. I’ve seen many people use console.log/logger/printf – heck, sometimes they even suggested that I do it that way. But as much as I enjoy waterboarding myself, I’d much rather use a debugger whenever I can. Debugging a node.js project isn’t complex, it just requires a little bit of setup, after which you can debug a local app or even a remote production/staging/test environment.

The first step is to run node.js with the special debug flag and the optional port:


node --debug <-- run node with debugging on port 5858

node --debug=4455 <-- runs node with debugging on port 4455 (you change the port)

node --debug-brk <-- run node with debugging and will break on first statement

If you’re using gulp/nodemon etc, be sure to include those flags in a separate task and/or pass the relevant params to your node app.

// Nodemon task
gulp.task('remote_debug', function () {
return plugins.nodemon({
script: 'server.js',
nodeArgs: ['--harmony', '--debug=5577'],
ext: 'js,html',
});
});

Then you can launch your app, or do it via the task, and your node.js app is running and allowing any debugger to connect to it.

You can use any node.js you choose. I personally use phpstorm/webstorm. While it’s not a perfect product and has some issues, I’ve had very successful debugging sessions with it, and I’ll try and outline how to set that up.

First install webstorm/phpstorm. Both IDEs are great and very similar, except Phpstorm also allows you to edit and work on PHP files, whereas Webstorm mainly concentrates on JS files and web files.

After the install, launch the app and go into the plugin:

Go to File->Settings and in that screen click on the plugins menu item.

plugins_screen

The click on the “Install JetBrains plugin…” button and in the new window either scroll down or search in the top search box for NodeJS plugin.

Once the install is finished, you should have NodeJS installed and you can go ahead and open your projects directory in the IDE. (File->Open Directory, obvious I know, but still… šŸ˜‰ )

In the last step we need to configure the remote config for our node project.

Click on Run -> Edit Configurations… Menu.

And Click on the + button and select Node.js Remote Debug.

node_remote_debug_new_config

Then in the main window just setup the server address and port (this can be used to debug a remote machine or a local machine)
And you’re all setup to start debugging your server!

node_debug_local

Then click ok, select the configuration from the top right-hand side menu and click on the little bug icon button:

remote_debug_launch

At this stage you’re up and running. If you look at the bottom debug tab you should see you’re connected and then you can put a breakpoint anywhere in your code and solve any bug you come across like a hero (at least in theory! šŸ™‚ ).

***** Important note *****

While Phpstorm/Webstorm is wonderful, I’ve had some issues with debugging performance. This issue relates to some settings in the software so to ensure you do not get frustrated waiting for the first breakpoint to hit, I would suggest you configure Phpstorm/Webstorm as follows:

1) Click on help -> “Find Action” (ctrl + shift + a)
2) In the searchbox type: Registry.
3) Then start typing (or scroll down) and find
js.debugger.v8.use.any.breakpoint – turn off

Happy Hunting!

doryz

What is the secret to successful remote software engineering?

My recent experience is that many companies insist on having engineers on site. When they hear “remote” or “not in the office” many people have a very negative perception. They either believe it’s cheap labor or they believe they require people to come into the office each day in order to get good results. While I do understand the bad experience many companies have, this is not always the case. Many are highly successful with distributed remote engineers, or even a remote team. While there are many places with highly talented engineers all over the world I see again and again companies that insist on hiring people only from the local eco-system. And it’s true that there are certain skills that only exist in Silicon Valley / Tel Aviv / NYC and other places where people have successfully built large companies, however a large percent of the work can still be done in a different place where the talent is more loyal, at a lower cost, while not sacrificing the skill-set of the people. It’s very difficult and expensive to hire engineers in SF or NYC or TLV, and as there are so many offers for talented engineers there, retention becomes just as hard as recruiting.

I’ve been highly successful at finding and retaining talent world-wide. I’ve also been working with companies for around 6 years, remotely. Either personally for my own start-up or providing development services for companies. I’d like to share my thoughts on what are the secrets to making such an environment flourish.

My experience with remote teams

Today my time is split between the US, Israel and Eastern Europe. I’ve been working for the past 6 years or so in and with remote environments and teams. I’ve used remote teams to build a complex password manager running on multiple web and mobile platforms,Ā and inĀ 4 years it has reached over 70,000 paying customers. I’ve also been successful at building products for US companies with teams in Eastern Europe and getting results using the latest front-end and back-end technologies.

Working in a remote team as an individual

When I first started out, I had doubts: how does this remote thing even work, if at all? While I’d heard of companies doing it, up until then I was used to waking up in the morning and going into an office. At the time I’d just started working with my new co-founder, with his company that has sold over 3 million dollars of mobile software products, and has worked with over 20 developers from all around the world. I was fascinated by this. Slowly but surely I saw the way he works with them and why he was so successful in doing so. It actually took me a lot of effort to get him to start meeting regularly (as we lived 2 blocks away) and we ended up meeting once every 3-4 weeks in person. We worked night and day and would communicate via skype, email and other methods. We built an amazing product together and got some great offers for partnerships and acquisitions.

Working with a mixture of remote and local teams

For the past 2 years I’ve been working with US-based companies, where most of my development work is done either by me, or by using teams of people in Eastern Europe & the US. I’ve built products and I know that there is a clear difference between a remote single contributorĀ and a remote team. Remote teams are very similar to regular teams, except you might have other people in other countries as your co-developers, product managers, or product owners, and you must manage this process. There are many similarities to being in a remote team and being a remote single contributor. I am not going to go over the differences as I want to focus on the core elements of working with remote teams / single contributors and what is common to making any remote environment work.

The secrets to making remote work

Finding good engineers is hard, no doubt. However using good engineers remotely requires the remote team or remote lead person on that team to have additional skills in order to make it work.

  1. Be Proactive & Driven – This is the single most important quality for any remote engineer / remote team manager. The reason is that when someone is sitting in the office, you can instantly see if someone is not engaged, or stuck. You can just tap him on the shoulder and ask what’s up buddy? Is there anything I can do to help? What are you working on? etc. In remote teams that is not possible, so you need to ensure the person on the other side, and possibly in the other time-zone, is proactive. He will get on call at strange local times, he will email you that something isn’t working. He will flag that he finished his tasks and needs more work, or even let you know that while you’ve planned it before, seems he is finishing early. He will be the type of person tapping himself on the shoulder and not requiring anyone to chase him. EVER! This type of person will make or break your remote / outsource / not in the office work environment.
  2. Resourceful – Resourcefulness goes hand in hand with being pro-active. When working in a remote team, many times you will be faced with integration issues. Integration issues are the ones that take up a lot of time. The back-end RESTAPI that is suppose to return X returns Y. Break. Your mobile app / front-end app cannot read / write the data and the work cannot continue, or perhaps it can? While the proactive perosn would raise the issue, a resourceful one would also find a creative way to continue his work. For example, many times I will create mock data / a mock server when I can’t get the back-end to work. This can mean the difference between 24-48 hours delay in the work, to zero down time, or just 1-2 hours to fix a bug. A resourceful person will find an alternate path to continue his work, create solution to a problem or just move to another task. Resourcefulness is highly important for any engineer, but in remote teams it is vital as it can be the difference between making the remote team work, and reaching the conclusion that remote teams do not work.
  3. Understand Product – Finding a good engineer that can also understand product is very difficult. However when working remotely this not only becomes a nice to have, it becomes vital. Understanding product means thinking in terms of user experience, and what is the easiest and most intuitive way to use the application. Many talented engineers can produce great code per requirements or spec, but do not think in terms of what the user needs. When this happens in house, the product lead can very quickly do a course adjustment: “Hey, I thought that would work, but on second thought let’s scratch that andĀ move this button over here.” With remote teams these iterations might take more time, and so it’s important to have someone you trust that would adjust the course himself. Someone who would understand what the “real requirements are” or what the functional requirements are, and build the right usability for the user. Even if not perfect, then the product person would have a much smaller adjustment to make. Understanding product is not simple, but once you find the right person that can do that, you’re setting yourself up for success with remote teams / engineers.
  4. Result Oriented – Most people hate micromanagement, and while sometimes management does need to intervene in the remote environment, this becomes almost impossible. That is why in remote environments, your engineer / lead must be result oriented. He is not focused on completing a feature, or getting his “workload” ticked off. He should be focused on making sure your business goals are achieved, and that his part is playing it’s role in the global scheme of things. A result oriented person would ask about your business deadlines, when do things need to be done by, and why. This means that person is not about just counting the hours worked, but about making sure he is helping you get to where you need to be.

TimeZone Issues

I’ve worked with teams in many time-zones, and when I meet new customers they always raise that concern. I wouldĀ like to use the end of this post to crush any time-zone concerns people have. Is having developers in different time-zones a challenge? Sure it is! Does it mean it won’t work? Not necessarily. If you’ve found a good engineer or engineers, that have the list of skills I’ve mentioned, you won’t be suffering from time-zone issues. These types of people, with these skills, are leaders. They will work at many times that overlap with your hours, they will be answering emails at 2am in the morning their time, they will jump on call at strange hours as they commit to your success. Furthermore, how many times do you really need to talk to your engineer 8 hours a day? Most of the time you’d rather not do that, as if you are, you might be hurting your own performance atĀ the same time…

I’m a big believer in remote teams and when done right they are a wonderful asset. The right team / person can build you amazing software that works very well. It’s all of matter of understanding how to work it, and what to look for. I hope this helps and feel free to contact me if you have any questionsĀ about creating a successful remote software team.

doryz

Choosing an MVC framework: Why I picked Ember & why it was an awesome decision

When I started working with Originate on a new project, I was givenĀ the freedom to choose my own stack. The CEO’s requirements were simple: create an MVP to replace the current process of resource planning that we use today. This meant creating a replacement for their Excel based process using a web app. I told the CEO: Donā€™t worry, Iā€™ll get something out to you in two-three weeks.
So there I was, staring at my computer, having absolute freedom to choose my tools. I should’ve been happy.

I wasnā€™t. I was stressed. I really wanted to impress them, to use the latest technologies.

I knew JavaScript very well, and Iā€™d done a few node projects, so I picked that. I didnā€™t have too much relational data, so I picked Mongo.

But which front-end frame to use to make a snappy single page app?

The Decision process:

I really wanted to pick the best one, but as getting hands-on with a framework can take anywhere from a few days to weeks, I just didnā€™t have that time to spare.

So which one should I pick? Angular? Knockout? Backbone? Ember? Meteor? I was in a bit of pickle.

Iā€™ve used many technologies over the years but I hadnā€™t really experimented with Angular, Knockout, orĀ Ember. Iā€™ve used Backbone, but itā€™s just too messy for my taste and not really structured.

So I started reading about all the technologies.

The instant ‘No’s:

  • Meteor seemed amazing – really smart people building such a great concept. The idea of front-end and back-end in the same system seems incredible. I actually wrote similar code in one of my past projects to move models from the back-end to the front-end, so I instantly connected with the concept. However, it was still very early days for Meteor and no big production environment was running it at the time, so it was out. AfterĀ checking on them recently I notice they seem to have made great strides and are doing very well. That’s one tech that Iā€™d keep my eyes on personally.
  • Backbone ā€“ I never liked Backbone that much and I’m not a huge Marionette fan either. I just felt itā€™s too messy for my taste.

Now there was theĀ tossup between the ones that were left:

  • Angular– the most popular one at the time, with lots of support due to it being aĀ Google product. However,Ā Iā€™d read complaints about it using its own idioms and engineering concepts that one must learn in order to use it. Still, itĀ was the most popular and most commonly used MVC, so I was not going to dismiss it easily.
  • Ember ā€“ As I was reading about Ember and doing my background investigation, I leantĀ that out of all the frameworks Ember is the most opinionated and that using it requires following a very particular structure, whereas Angular is more configuration based. I also learntĀ that Ember is stable and used by quite a few serious companies.

My decision wasnā€™t simple, but ultimately I picked Ember for two main reasons:

  • Ember and Angular seemed to me the most stable, and the ones that have some serious customers using them in production.
  • Emberā€™s convention over configuration. Ember forces you to follow a particular structure, which can be a very good thing as it solves many of the engineering decisions for you. Plus,Ā no one has to be the ā€œcode policeā€ that makes sure you put files in particular directories, or call classes with certain names. I liked that, and since Iā€™m not only the engineer but also the project manager and team lead, and needed to put more developers from various time-zones on the project, I thought that would be awesome. Boy, was I right.

Getting Started With Ember:

Now, once I’d chosen my tools it was time to start getting some hands on experience in building my MVP.

Naturally I started on the Ember official tutorial. However their tutorial was based on used Ember-Data. Ember-Data is an ORM like layer that is separate to Ember. It provides the front-end with models, and all related operations and uses dependency injection to inject an object called the “store” into all parts of an Ember app. While the concept is wonderful, at the time I was starting out Ember-Data was separate to Ember, and they had mentioned it would soon make it’s way into the main branch. As such I decided it was too big of a risk to rely on it and developed my own data layer, using my own store. At the time of writing this post it has not made it’s way in, and went through many breaking changes. As such this decision was spot on.

The first week with Ember was painful. The concept of convention over configuration means there is the Ember way, and the Ember way. Trying to do things in a none-Ember manner just creates frustrations and will get you no where, so the best way is to understand what Ember expects and to do it that way. For example, let’s say you’d like to update certain elements, hide or show etc. While in traditional jQuery you’d just bind to an event, the Ember way would mean you should add an action to some element.

Ember a couple of months in:

Once you do understand how Ember works, and what to do, you become super productive and you can crank out code in a fraction of the time it would otherwise take you.

Ember has a very particular way for all objects in the system to interact. Ember gives you an excellent router, with each route having a very particular point in which it loads the model (Either stand-alone model object, POJO, or the ember data models), a controller object that wraps around your model, and can provide various computed fields, or connect various models together, handle actions and more, and the view that wraps the templates, which uses HTMLBars (ex. Handlebars) templates. Here is an anatomy diagram:

Ember_Anatomy

Ember really gives you a framework to do great stuff in a very easy to use manner (once you understand the manner as it’s perceived by Ember); I found myself completing whole pages, and complex UI components, in lighting fast speeds, with it being re-usable in other places later on. Once you’re up to speed with Ember, you’re going to love it (or at least I hope so).

Ember Decision Epilogue:

My Ember journey has been very exciting. It started with Ember 1.3 and now I’m Migrating to Ember 1.10 with Ember-cli. I have written a complete data layer for my Ember app, and the application today is 150,000 lines of code and used by a significant company in production. I have gone through performance optimization and made a few interesting observations about Ember:

  • Us geeks tend to love technologies for technological reasons. But the reason I love Ember is from a business perspective – convention over configuration. This means that you can move new engineers on and off a project, and as long as they understand Ember they can start to be productive very quickly.
  • During my work on this project, I assisted the company with implementingĀ a new consulting agreement. Having the customer use Ember made it very easy for me to detect design flaws, and to do isolated re-factoring, rather than a complete throw away!
  • The company had another codebase that everyone suggested was a throw away. The code was indeed poor in many ways, but since it was Ember it was easy to salvage, to re-factor and shift snippets around, to make it usable and re-factorable, saving the company months of work.
  • I have hired a few engineers to work on this project, from multiple places around the world. I was amazed at how fast they have picked up Ember, and even though they are junior, Ember has allowed them to be highly productive from day one.
  • The Ember-Cli build system is an awesome addition that takes care of so many things, there is no other MVC framework that provides it.

I’m finding more and more companies are using Ember, and I’m the big advocate of convention over configuration along with Ember. True, there is the downside that Ember has forced its users into making constant re-factors to it’s code-base, but I suspect this is still better than Angular 2.0’s throw everything away! Also when using the latest and greatest you should expect things to change, and overall Ember provides developers and product owners with lots of bang for their buck. I think it’s more complete and my #1 choice for CRUD like application, front-end MVC.

<

p class=”page-break”>Thanks for reading and I hope you’ve found my experience helpful.
Cheers
Dory šŸ™‚

doryz

How To Hire Awesome Engineers?

I get approached daily and weekly by people wanting to hire me, on LinkedIn, email, and through various other means.
I really don’t mind it, and while I’ve been in software for quiet a while now, and I’m not claiming to be an expert on anything, I do believe I understand the engineer / geek mindset and, having successfully hired many people and been hired many times, I think there are a few key elements and success factors to hiring engineers that so many companies and people miss completely. I’m writing this post in the hopes of helping others improve their hiring process for the good of all of us out there. šŸ™‚

The Wrong Cold Call Email

Personally I don’t mind getting cold call emails / messages. Everyone is doing their job and that is actually good! However, I know many people that hate this. I think the main problem here is that people don’t invest much time when they’re about to send an email to someone they do not know. Before you contact anyone you don’t know, spend some time making sure you understand why you’re contacting them. Here are two examples of horrible methods that will rarely get a response from anyone and if anything, might even get you tagged as spam and blocked:

HowNotDoPitch

BadTemplate

It’s fine that you have a template part, many times your message has some core information that doesn’t change, so leave that in. But show the other person you know why you’re contacting them. These guys didn’t even bother, they are probably sending emails to everyone. The firstĀ person was impressed by my LinkedIn profile, which is great, but do I really believe her? What is she impressed by? My background, my Ember skills or my pretty blue eyes (they are really brown)? You get the picture. I had no doubt she didn’t even read my profile or find anything impressive on it – she is machine gun emailing. And the second guy was doing so much copy and pasting he missed getting my nameĀ in the template right. However, it’s also not always this clear. Sometimes I get emailed with a lengthy one or two paragraphs talking about who they are and what their companies is, etc, etc. Why do I care? Why does anyone at all care about that?

The Right Cold Call Email – 80%+ Response

If you’re going to address anyone, not just in regards to hiring but any cold call email, you need to spend time and construct it properly:

  • Pre-approach – This will take you some time. Use Google, LinkedIn, Facebook, and research the person you’re contacting. Look for their personal site. Read about the companies they’ve worked for. Try to get a mental image of who they are before you contact. Make sure you actually do want to contact that person, and that he is the right person you should be talking to! Don’t just copy and paste stuff. Spend time in what is called the pre-apparoch. It will pay dividends, ensure you’re actually contacting someone you want to talk to, and will show the other person you care about them. In the same wayĀ you’re asking them to invest time, you’re investing time too!
  • The opening paragraph – I always open my emails with highly personalized content. But not just any content – I try to find the reason and the basis to try to reach out to the other person on a personal basis! I try and connect on a personal and professional level. I try to understand the mindset and why what I’m offering suits their mindset and persona. For example, if I see someone that is an Ember fan I would talk about why I think Ember is great and why I’d love to contact them. If I’m looking to hire a developer I look at their Github and their stack overflow and see what they have been doing, do a little code review for them, and only then address them: “I checked out your Github, and I loved your angular auto-complete directive.” I always close this paragraph with a clear indication of why I’m contacting them. People have little time, so be precise and direct. People will breeze through your email / message. If they understand what you want – great! If they feel it’s spam they will mentally tag it and will not continue to read, but press delete instead.
  • The info paragraph – This is where you are allowed to provide copy and paste info. If you’re looking for work, write about your background, provide links etc. If you’re looking to hire, explain about yourself, your company and what you’re looking for. If you’re looking for customers explain what you can provide, what other customers you’ve worked with, etc. Include links and information but try to keep it short and sweet. Too lengthy becomes lecture-like, and people don’t like that, they tend to skip it as spam.
  • End with why now and a call to action – I like to end these emails explaining why I’d like to contact them now (currently hiring, just finished a job and looking for a new things, currently in two for two weeks, etc). Don’t make this generic, explain why the time-frame is real, it creates urgency and authenticity. Again don’t make this up, really explain why!
  • Language – Long gone are the days of writing fancy emails with fancy language. They super quickly sound too hyped up and too pretentious. I’ve been using a tip I got from one of my co-founders. Think like you’ve having a normal conversation with a friend over a beer or lunch and write your email in the same language. Be modest and confident, stick to facts and talk on eye level. These tend to make people feel like they’ve received an email from a human and not an email sending machine. However, please do be passionate and alive, explain why and show that you care. People tend to respond to that. They see and read your effort and tend to appreciate your energy.
  • Follow ups – If after 3-5 days you get no response, feel free to send a quick 2-3 lines follow up email. If that doesn’t work try again after 3-5 days. Most of the time people have either gotten it in a spam folder, or just have been too busy with other things, don’t take it personally. And if still no response, just let it go, you probably don’t want to do business with them anyhow, as they aren’t really mindful of you or your time. šŸ˜‰

The Next Step – Initial Call

After you do get some interest to your email, I suggest you setup an initial call. This should be an intro call with someone that has some technical knowledge. Do not send out a test task right away!Ā You want to get to understand the other person better, you do not want to put them off.

During this call, let them talk about themselves, what are they doing, who they are, what they want to do. Ask open ended questions and listen. It’s the first time they are talking to you, so let them feel at ease. Get a sense for who they are, only after that should you spend a little time talking about you, your company and what you’re looking for. After about 30 min introduction try to do 30-45 min of tech phone interview, just to make sure the person you’re interviewing does understand the basics.

The Joel on Software blog describes this call very well. Try to get in a few questions. Ask to describe some algorithms. Talk about the technology the person uses, and try to probe. If you don’t know the tech the candidate uses, try to get someone else on the call to probe about it. It’s not critical that the person has or doesn’t have the right tech fit, it’s important that he really understands the tech stack that he uses. If it’s JavaScript he should understand why == is not the same asĀ === or what is prototypical inheritance and explain about certain gotchya’s! Feel free to also ask them to do something simple like write a function that reverses a string, etc.

You can also ask them what’s the different between pass by value and pass by reference. I really like to say something that is totally wrong and see how they respond: in C++ you cannot pass by reference. It shows how they respond to conflict. Try to get a sense of whether they do understand the tools they use and the basics of software. If this goes well, setup an in-person interview. If not, move on. So many times you’ll find that candidates that seem like they are amazing end up being total duds and vice versa. So try to get this right, the person on the other end will appreciate you for it too! Also it’s a good time to ask about salary expectations etc, to make sure you’re on the same page, or you can wait until after the interview / test task. This depends if you have a set budget or not, or if you don’t mind paying the market rates or not.

The In-Person Interview

The interview is a stressful time for most candidates – they want to impress but it’s not the natural environment for most of them. So start again but having some casual conversation. Try to find a quiet location and try to make the other person feel comfortable. It’s not about stressing them, they are probably doing that job very well by themselves. It’s about making them feel as natural as possible so they can really perform at their best and so you can understand what their best is!

This shouldn’t be a one sided discussion or an informal chat, you should have an agenda. Talk through, look at their body language and listen. They should be talking as much as you are talking. Ask them about their work history. About projects that didn’t work, about conflicts and how they resolved them. Get a sense for what their everyday job looks like. If they manage people, how do they deal with failures? What is their outlook on failures? etc. Be sure to tell them about yourself and about your company and role.

Then you should get into the technical side of the interview. Do not ask questions with a light bulb moment! You might love them and think they are clever, but they prove nothing to be honest, except that the person can solve your riddle. It is the same withĀ complex algorithm challenges with one solution. Again they provide you with very little insight into how good that person will be as an engineer, and that’s the goal right? To find someone intelligent that can deliver results! So good questions are:

  • Ask them to completeĀ a simple code exercise, not too trivial but not too complex. Chances are that the other person won’t write optimal code and it might containĀ bugs. This is a great chance. Tell the person he has bugs and wait to see if he finds them and fixes them. Look to see if they didn’t write code to handle invalid input. They should ask you about it, or if not, they should notice that. Then ask them to optimize their code. Many times the code they write isn’t dry or optimal. Iterating together will show you a lot about the way that person handles not only code, but also do they persevere or do they give up? You want people that don’t give up! This is a great test for anyone you work with!
  • Ask them to design a system. Any OO design question would be good here (Deck of Cards, Elevator System, Etc). These are good questions as they show how that person approaches development design, how they architect and how they think in terms of Objects. Again, this is a good question as you can ask them why they did it this way or that way and gain insight into their thinking
  • Then I always try and find some challenging task I had and give it to the candidates. Something I have already solved but thought it was complex to solve myself. This is another great example, as I’ve had people solve a complex problem faster than I did! They aren’t suppose to come up with a complete solution, just with the concept behind it, and maybe explain how it would work. This is very insightful!

I try to wrap up the inteview by thanking that person and tell them I’ll be in touch. Try to send out emails to everyone that interviewed with you showing that you value them and their time, and that you respect them regardless of what the outcome might be.

The Test Task

This is something that is so misused in my mind. On one hand it’s a great indicator and way to learn how it is to work with someone. You can see if they understand instructions and how it would be to work with them, but so many companies abuse this. Never send out a test task right away, it shows you don’t really care about the other person or even value their time. I’ve done a few test tasks, some as first point of contact. And while many did like my work, I never ended up taking work with companies that do this.

The proper way to do a test task is as the last step, to see how it would really be to work with that person. I like to find some block I really need, and to give that to the other person as a paid task! Yes, paid. Many times engineers will even agree to do it for free, but always offer a paid task. Just as you wouldn’t go to the doctor and ask for a free checkup, just to make sure he is the right doctor, don’t expect a good engineer to work for free, they have too many options. But with a paid task, I can see that the other people value my time and respect me, and I also do these very gladly. Yes there is a risk that the other person will write crappy code, but it’s better to pay a few wrong people than hire the wrong person. It shows me people are motivated to complete the task and it’s a great way to mini-test your working relationship.

Final Notes

I find that following these steps makes people feel at ease not only with leaving a current position and moving to work for you, but also for you. It ensures you find great candidates and hire only the best people that mesh well with you and your team. It’s not rocket science but it is a craft, and so many companies have such bad hiring processes that it frustrates the people they are trying to hire. So even if you don’t follow my suggested steps, please be mindful of the other person, show you respect for their time and try to treat them the same way you’d like to be treated!

Cheers
D.