Interviews

Developers Corner

PART 2: UNDERSTANDING MySQL CLIENT / SERVER PROTOCOL USING PYTHON AND WIRESHARK

In this article we’ll learn how to write our own native MySQL client from scratch using no connector or external libraries.

In the previous article we researched MySQL Client / Server Protocol using WireShark. Now lets start to write our code in python to simulate MySQL native client. Final codes are here: Github repo

First of all we have to create MYSQL_PACKAGE class. MYSQL_PACKAGE class is the parent of all other package classes (HANDSHAKE_PACKAGE, LOGIN_PACKAGE, OK_PACKAGE and etc.)

It accepts resp parameter on initialization. Resp is the binary response received from the server in bytesarray type. One of the important and interesting method of this class is next method.

Method next reads a portion of the bytes from the binary response. When we call this method, it reads some portion of bytes and puts a pointer to the last position where reading ended (changes a value of self.start and self.end properties). When we call this method again, it starts to read bytes at the point it last stopped.
Method next accepts five parameters: length, type, byteorder, signed, and freeze. If freeze is True it reads some portion of bytes from the binary response but does not change pointer position. Otherwise it reads a portion of bytes with given length and changes the position of pointer. If length is None then method reads bytes until the end of response bytesarray. Parameter type can be int, str, and hex data types. Method next converts a portion of bytes into the appropriate datatype according to the value of type parameter.
Parameter byteorder determines the conversion of bytes to integer type. It is up to the architecture of your computer. If your machine is big-endian, then it stores bytes in memory from the big address to the little. If your machine is little-endian, then it stores bytes in memory from the little address to the big. Thats why we have to know the exact type of our architecture to be able to convert bytes to integer correctly. In my case, it is little-endian, that’s why i’ve set the default value of byteorder parameter to “little”.
Parameter signed is also used in conversion of bytes to integer. We tell the function to consider each integer as unsigned or signed.
A second interesting method of this class is encrypt_password. This method encrypts a password with the given algorithm.

This method accepts two parameters: salt and password. Parameter salt is the concatenation of two salt1 and salt2 strings from the Greeting Packet received from the server. And parameter password is the password string of mysql user.
In the official documentation password encryption algorithm is:
password_encrypt_algorithm
Here “20-bytes random data from server” is concatenation of salt1 and salt2 from the Greeting Packet received from server. To remember what the greeting packet is look at the previous article
Now I want to explain the encrypt_password method line by line.
bytes1 = sha1(password.encode(“utf-8”)).digest()
We are converting password string to bytes, then encrypting it with sha1 function and assigning to bytes1 variable. It is equal to this part of algorithm:
password_encrypt_algorithm1
Then we are converting salt string into bytes and assigning to the concat1 variable.
concat1 = salt.encode(‘utf-8’)
password_encrypt_algorithm5
Third line of the method is:
concat2 = sha1(sha1(password.encode(“utf-8”)).digest()).digest()
password_encrypt_algorithm2
Here we are double-encrypting password string with sha1 function and assign it to the concat2 string.
Now we have two concat1 and concat2 variables. We have to concatenate them into one byte array:
bytes2 = bytearray()
bytes2.extend(concat1)
bytes2.extend(concat2)
password_encrypt_algorithm6
Then we have to encrypt concatenated bytes with sha1 function and assign to the bytes2 variable.
bytes2 = sha1(bytes2).digest()
password_encrypt_algorithm3
So we have two variables with encrypted bytes: bytes1 and bytes2. Now we have to do bitwise XOR operation between these variables and return the obtained hash.
hash=bytearray(x ^ y for x, y in zip(bytes1, bytes2))
return hash
password_encrypt_algorithm4

CLASSES FOR DATATYPES

In the previous article we’ve learned about Int and String data types of MySQL Client / Server protocol. Now we need some classes to be able to read fields from received packets.

INT CLASS

Int class implements INT data type of MySQL Client / Server protocol. It accepts package parameter on initialization. Parameter package should be the instance of any package class inherited from MYSQL_PACKAGE class. Method next detects the type of integer (int<fix> or int<lenenc> (see previous article) and calls the next method of package object to read the byte portion of received response.

STR CLASS

Str class implements STRING data type of MySQL Client / Server protocol. It accepts package parameter on initialization. Parameter package should be the instance of any package class inherited from MYSQL_PACKAGE class. Method next detects the type of String (String<fix>, String<Var>, String<NULL>, String<EOF> or String<lenenc>. See previous article) and calls the next method of package object to read the byte portion of received response.

HANDSHAKE_PACKAGE CLASS

HANDSHAKE_PACKAGE class is used for parsing the Greeting Packet received from server. It is inherited from MYSQL_PACKAGE class and accepts resp parameter on initialization. Parameter resp is the Greeting Packet response in bytes type recieved from the server.

Method parse reading fields from the response using Int and Str classes and puts them into a dictionary and returns.

LOGIN_PACKAGE CLASS

This class is used for create Login Request packet.

This class accepts handshake parameter on initialization. Parameter handshake should be the instance of HANDSHAKE_PACKAGE class. In the __init__ method we call the parse method of handshake object and get all fields of the Greeting Packet received from the server.
Method create_package prepares the login request package to be able to send to the server for authentication. Accepts user, password and packet_number parameters.

OK_PACKAGE & ERR_PACKAGE CLASSES

OK package and ERR package are the response package of server after authentication or after sending query to server on command phase.

MYSQL CLASS

MYSQL class is the wrapper class which creates TCP connection with server, sends and receives packages from server using above classes.

I think everything is clear in this class. I’ve defined __enter__ and __exit__ to be able to use this class with “with” statement to automatically close TCP connection. In __enter__ method i’m creating TCP connection over socket. And in __exit__ method i’m closing created connection. This class accepts host, port, user and password parameters on initialization.
In the connect method we receive greeting packet from server:
resp = self.client.recv(65536)
return HANDSHAKE_PACKAGE(resp)
In the login method we create Login request package using LOGIN_PACKAGE and HANDSHAKE_PACKAGE classes and sends to the server and gets OK or ERR packages.
That’s all. We’ve implemented the connection phase. To avoid making this article too long I will not explain the command phase. Because the command phase is easier than the connection phase. You can research it yourself with the knowledge you’ve accumulated from this and previous articles.
Demo Video:

By Oct 9, 2020
BoundarylessEnterprise

Ashu Garg is Bullish On Boundaryless Teams as the Future of Work

Ashu is equally bullish on the role that remote, distributed teams will play in the future of work. Join us and learn why Ashu likens the Bay Area today to Florence during the renaissance, why the world is flat, and why the companies he believes in incorporate boundaryless teams in their plan from the start.

In today’s episode of our podcast, we meet Ashu Garg, General Partner at Foundation Capital.

Ashu loves puzzles and making bold predictions, including the prediction he made in 1998 that the IT Services Industry would grow by 100x in the next ten years. A decade on, that projection proved prescient.

Today, Ashu is equally bullish on the role that remote, distributed teams will play in the future of work. Join us and learn why Ashu likens the Bay Area today to Florence during the renaissance, why the world is flat, and why the companies he believes in incorporate boundaryless teams in their plan from the start.

By Feb 10, 2020
Hiring developers

Vetting Candidates for Remote Work | Turing Hire

What you need to know about a candidate to make a great long-distance hire Hiring remote, global talent is tough. Most of the usual signals you rely on when hiring someone in the US don’t apply. You may not recognize the school a candidate attended. You may never have heard of the companies a candidate… View Article

What you need to know about a candidate to make a great long-distance hire

Hiring remote, global talent is tough. Most of the usual signals you rely on when hiring someone in the US don’t apply. You may not recognize the school a candidate attended. You may never have heard of the companies a candidate has worked for, and you may not have any idea if the people providing references are genuine. You also can’t rely on recruiters because they’re likely dealing with these same problems.

So how do you make sure a remote prospect is up to the task and won’t simply slow you down?

Overcoming sourcing challenges with rigorous vetting

When the usual means of identifying talent are likely to fail you, a new process is needed. At my current company Turing, we’re working to solve this problem. In this article, I’m going to share with you what I’ve learned during hundreds of technical screens. My goal is to help you identify best practices for vetting prospects and making sure your placements are going to be capable of delivering the results you require.

At Turing, we match developers from all over the world with positions at some of the world’s best and most interesting startups. Every time we make a placement, we put our reputation on the line. In other words, we can’t afford to make bad matches.

Since we are unable to rely on typical signals that would allow us to determine if someone is good enough for our clients, we’ve developed a system that provides unbiased feedback about a candidate’s skills in all of the areas critical for their remote-work success.

Core to our approach is a highly structured vetting process that incorporates sophisticated automated testing as well as detailed, in-person technical screening for individuals that have been able to successfully pass our coding examinations.

All of our testing is intended to help determine key facts about the experience, skills, and capabilities of a candidate. What we’re trying to understand through our tests and interviews will help us determine if a person has the skills they claim to have and whether they’re capable of performing basic tasks, managing projects, and people, or even leading entire projects from conception through implementation.

So, at a baseline, we’re trying to determine if someone can contribute to a codebase in a meaningful way. Maybe their skills only support accomplishing scoped, individual tasks. For example, can this person add a button that does x, y, and z on this web page and build it in a way that takes into account the full technical stack of the application?

Or can this person go in and add unit-testing to some kind of already written back end piece of logic? Generally, can they contribute within an already established structure and do things that won’t upset that structure, if given functional requirements?

Then, there’s a level of complexity beyond that. Can this person take a direction like “Hey, we want this larger-scope feature built?”, and successfully run with it? And can they execute at that level of complexity, something that is going to be composed of many tasks? Can this person, for instance, build a new signup flow, or build a new matching algorithm for some sort of matchmaking service? Can they individually make the sorts of principled tradeoffs in design and implementation that is inherent to successfully building at that level of complexity requires? Does this person have the sophistication to read between the lines and identify functional requirements implicit in a higher level and more coarse-grained specification?

But most critically, at both the task and feature-based levels, we’re trying to determine if this person will be able to contribute to an already established infrastructure, both technically and procedurally.

Identifying coders, leaders, and project architects

For more senior placements we start getting into higher levels of architectural complexity. Can this person start an entire project from scratch if they’re only given a general direction? If they’re tasked with building and deploying a new Android app that does something novel, can they deliver? Or if a company is expanding their product into a whole new space, can the developer take some rough business ideas and some rough sketches about how the company would like to go about doing this, and then build out a full-stack product, from the UI to the backend architecture to the design of the database models?

Can they manage the entire process from system architecture design to writing elegant implementations? Do they possess the depth and breadth of experience, as well just general horsepower, to be skilled enough to implement the MVP from the front end to the backend to the database as well as whatever infrastructure they’re going to use to actually deploy the code?

Even vetting somebody in terms of their technical acumen from a general level that seeks to get a signal on someone’s “seniority” is a really complex thing to do. Proper vetting needs to understand whether a person can design systems at a very high level. Can they understand how pieces fit together and how those pieces talk to one another? And then you start getting down into deeper levels of abstraction. Does a candidate understand how this feature fits into the greater scope of the product?

Can they assimilate to use the tools in a particular company? Can then adapt to the cadences and workflows of the team that they’re on, and work with other people to be part of a bigger whole? And then, at the task level, you need to determine if someone has fundamental baseline computer science abilities? Will they build efficient pieces of code? Do they understand notions of runtime and space complexity, and how that might apply to the code that they write, and the specific problems they are being asked to solve?

Are they able to conceptualize how their code will typically be used and how the stuff that they write will actually be run?

But the most critical thing to keep in mind is that it all comes down to code. Code has

a dual purpose.  It is going to be executed by a computer, and it’s going to be executed at certain cadences and using certain pieces of data and memory. But it’s also the stuff that people are going to read, and have to maintain.  People will have to go in and either edit or understand what your piece of code is doing in order to write their own piece of code, to modify or extend the functionality of a given application. Designing abstractions and writing code that can be comprehended by another human is extremely important.

AI versus Human Vetting

It’s almost an overwhelming list of skills that somebody requires to be considered a “good” software engineer. Trying to vet them all in an hour-long phone interview is very difficult. At Turing, we’ve realized that it’s possible to take the human out of it. To a point.

We do have an hour-long technical interview that we use with some of the most skilled developers that we’ve found on our platform, where we validate and extend upon things that we find through automated testing.

The technical interview allows us to screen for things that we find are very, very hard to test for. Of course, we’re interested in their communication capabilities, but we also like to test some technical things in an interview in addition to an automated test.

 Why Both?

During the course of developing Turing’s platform, we found that automated tests are really good for testing someone’s facility with specific technical stacks. For example, with programming languages like JavaScript, or Python or frameworks like React, or Node JS, or Laravel. We found that we can test someone’s knowledge of how to use those particular things pretty well in an automated test format.

We can get a really good signal as to whether somebody actually knows a particular framework or whether they speak a particular language. What’s really nice is that we can provide skill-validation to clients who are looking to get somebody up and running with the stack that they’re using as quickly as possible.

We’ve also found that we can automate testing of more general-domain kind of format

For instance, we can find out if the candidate knows how to build a server. Do they know and understand how a database is going to interact with a server, and how that server might interact with a front-end client? Do they know common design patterns that might be encountered in software engineering, and how those patterns might best be applied?

Is a candidate familiar with the types of algorithms they might encounter in software engineering? Or, given this piece of code in a language that you purport to know, can you tell us what you’d expect to happen if it was run with a certain type of input? We’ve found that those types of questions are really good for the types of automated testing that we currently do.

And we think that we get a pretty good signal on a developer’s mastery of a specific type of coding, say front-end development or back-end systems development, or mobile development or database design.

There’s really good tooling that we’ve built upon, that allows you to run code in a browser. And this allows us to do things such as automated live coding tests. We can do automated live algorithm testing in this sort of format with a significant degree of success, in terms of being able to test algorithmic correctness and efficiency.

We’re able to test whether or not somebody can write code that fulfills a particular function within a particular amount of time, and with a particular amount of like memory. We’re really excited to expand upon this method and see what further coding-based automated tests we can do.

Where automated testing breaks down

But even in a live coding format, there are holes that we have in terms of our automated tests.

Right now, it’s still very hard to get a computer to tell us what the elegance of somebody’s code is. Or how well it was organized, or how readable it is, or how well abstracted it is.

That’s where I really feel like a technical interview comes in handy. Because then I can present candidates with situations they might encounter during their work and they can walk me through how they’d design the solution to the problem. Doing this during a technical interview can help me understand what a candidate’s thinking is, and what kind of code, organizationally, they’d spit out to approximate a solution. This really helps me get into a prospect’s critical thinking. I can really see how they handle problems with uncertain specifications, how they ask questions about getting required specifications, and more generally a get a clearer idea of what the nature of their programming abstractions and elegance might be.

“Automated testing establishes a bar that filters people out. The in-person interview confirms the testing and tests the candidate on critical things that are currently hard to measure in an automated way.”

In general, what we’ve learned at Turing is that a well-designed and comprehensive automated testing facility is very cost-effective when you need to screen a large number of applicants blind. If I had to do an in-person interview, or even review and background check every candidate that wanted to work with Turing, there wouldn’t be enough hours in the day or enough days in the year.

And as our testing capabilities continue to evolve it makes our ability to find the best candidates and then invest our time where it’s most productive; doing technical screens for the top-tier applicants only.

What to do if you don’t have automated testing

In my next post, I’ll talk a bit about what you can do if you don’t have an automated testing facility. I’ll also dig into the way you can make the onboarding process simpler, and how you can spot early signs that a remote hire is struggling or even failing. Stay tuned!

By Feb 5, 2020
Hiring developers

How to Become a Remote Developer | Turing Jobs

My goal with this post is to tell you how to prepare yourself to get your first serious remote gig.

Thinking of becoming a remote developer and also want to work for a top tier company – hopefully, one based in Silicon Valley – but you don’t live in the US and you haven’t been able to secure a visa. Don’t despair. More and more of the latest valley startups have discovered that there’s a ton of talent offshore. This means that today might just be the best time in history to become a remote developer.

As someone that’s been working remotely about as long as it’s been possible, my goal with this post is to tell you how to prepare yourself to get your first serious remote gig. Today, I work for a company called Turing that places developers with opportunities all over the globe. We have some of the most advanced developer testing and vetting of any company in the world. What I’m about to share with you are key insights I’ve developed first, as a person that’s gone through Turing’s testing and vetting process as well as someone that now works on making that process even tougher and better.

First Things First, Be Prepared to Show Your Work

If you’re a developer applying right now, make sure that you’ve got a portfolio of some work that you’ve done before. It could be code you’ve submitted to GitHub. It could be some art design work that you have worked on. Maybe some websites that you’ve worked on, or maybe applications on the App Store.

Being able to showcase completed work is a very good thing. When we’re evaluating candidates that have passed our tests look at prior work. Additionally, many Turing clients want to see examples of the work a potential match has completed. The other thing that can help you stand out is if you have a good CV. But be careful! Attention to detail is critical. Make sure there are no errors in any documents you share to showcase your skill.  Nothing will shoot you in the foot the way an obvious mistake can. Believe me, I’ve seen so many people with errors in their CVs. To me, it’s a red flag if someone submits such an important document with mistakes. It says you’re careless and don’t take the time to check your work. So, no errors on CVs!

It’s also really important to have relevant information included in your portfolio. If you say that you have a particular skill make sure that there’s a corresponding project where you have actually used that skill. You’d be surprised how often someone will say they are proficient at coding in a certain language but then they don’t provide a single example of their work in that discipline. If you say you’re good at something, impress me by showing me an example of your great work!

Another critical skill for someone remote that wants to work for a high-profile US company is to have strong English. I know there are many people that are not native English speakers so it’s always good to make sure that your English is very concise. If this is a weakness, don’t ignore it. Do whatever it takes to make sure that you understand English very well and that you’re proficient in communicating in English, too. It’s the language your team is going to use, it’s the language you’ll be using to comment your code, and it’s probably the language of the people that will be using the product you want to help build. It’s easy to think people will overlook weak English skills, but if there are two candidates that have the same experience and have performed equally well on the automated tests, the one with better English skills will perform more strongly in a live technical screen.

How to Ace Your Automated Testing

The key to a superlative performance on automated testing is to be very well prepared.

Ensure, for example, that if your area of expertise is Python, you have prepared yourself in terms of the coverage of the topics in Python.

Be sure you’re prepared to cover that language end to end because the questions will try to test your coverage. The exam will cover your in-depth knowledge as well. if it’s algorithms and data structures that you work on be sure you know everything from the most basic concepts all the way to graphing algorithms and runtime complexity.

How Long the Automated Testing Should Take a Skilled Developer

For a skilled individual, I estimate that our current automated testing will require about eight hours. So, maybe a day. But of course, you may not want to put all that pressure on yourself to finish everything in one day. My recommendation is to allocate two hours per day and give yourself roughly a week to do just about all the MCQs in the qualifying exams.

Technical Exams – Where You’ll Sink or Swim

Just like with the automated MCQs, your performance during the technical interview will come down to how well you’ve prepared yourself. During a technical screen, we want to understand your in-depth knowledge. We also try to validate your performance on the MCQs and to understand if you have good working knowledge of design patterns.

For whatever programming language you use, it’s critical that you know everything from the basics to some really advanced techniques. And since we only pass the top 1% of developers you need to be prepared to talk about the projects that you’ve worked on in a little bit of detail.

You also need to be able to answer system design questions. System design questions are very important for a screener to understand how you are able to visualize a product from an architectural point of view. You should also be able to go deeper, all the way to the code, and even how it is going to be deployed on the final environment where it’s going to run. So, you need to be prepared to discuss all those things related to end-to-end software development.

For example, if you are a Python Django developer, you should be prepared to answer any questions relating to that language in depth. It’s also good if you’re capable of answering questions about system design and also planning as well.

Where Developers Get Tripped Up in the Technical Screen

During a technical screening, most people are not prepared to go into detail on algorithms and data structures. Again, it comes back to preparation. We often have people complain that they don’t need to know this stuff for the work they do but being competent with both algorithms and data structures is very important for high-level work. Another thing I see a lot of candidates struggle with is when we ask them to explain various concepts in English. I’ll emphasize again, that having strong English communication skills is vital to ensure placement with top-tier US opportunities.

Final Words of Advice

To wrap up this post, I want to emphasize a couple of the key points I’ve made above. In Silicon Valley, it’s very competitive to find good work. If you’re trying to get into this market as a remote engineer, you have to be truly exceptional. Turing’s tests are designed to filter out all but the best candidates to be matched with our clients.

If you’re really serious about securing one of these most in-demand positions, my advice is as follows:

  • Preparation is critical. If you have a weakness, work to improve it
  • Don’t underestimate the importance of understanding algorithms and data structures because if you do, you’ll fail the MCQs or the technical screen
  • Make sure your ability to communicate in English is up to the task. If it’s not, take action to improve it
  • Be sure to have a portfolio that includes projects related to the languages you claim to know
  • Polish your CV. Scrub it of mistakes because if you don’t, we’ll notice them and that will hurt your chances

Next Time

In my next post, I’ll be talking about what you should expect once you’ve passed the MCQ and technical screens, how candidates are matched with opportunities and what you should do to ensure that your onboarding process goes as smoothly and quickly as possible.

 

By Feb 5, 2020
BoundarylessEnterprise

The #Boundaryless Remote Distributed Teams Podcast with Murray Newlands:

In today’s episode of our podcast, we meet Jonathan Siddharth, CEO and Co-Founder of Turing. Jonathan built his last successful company, Rover, using remote, distributed teams. His new company, Turing, is based upon the idea that talent is global, while opportunities are not. Please tune in to discover how to hire remote employees and what it takes to build your company with a fully distributed team.

The #Boundaryless Remote Distributed Teams Podcast with Murray Newlands:

In today’s episode of our podcast, we meet Jonathan Siddharth, CEO and Co-Founder of Turing. Jonathan built his last successful company, Rover, using remote, distributed teams. His new company, Turing, is based upon the idea that talent is global, while opportunities are not. Please tune in to discover how to hire remote employees and what it takes to build your company with a fully distributed team.

About the Boundaryless Remote Distributed Teams Podcast:

The world has changed. In the past, companies were built with locally-hired teams, operating out of the same office. But today, entrenched competition, brutal commutes, exorbitant real-estate prices and more global distribution of talent have upended this practice. Now, billion-dollar companies are now created with teams working remotely and distributed all around the world. Creating #boundaryless companies is hard but we will give you the tools to succeed.

By Feb 4, 2020
Tweet: Women in the Gig Economy
Interviews

A 7-Point Checklist for Remote-Employee Success in 2020

Forbes contributor Diane Mulcahy recently interviewed Krystal Hicks on the topic of “why companies don’t trust their employees.” (Krystal Hicks is the founder of JOBTALK – a resource for career-curious professionals throughout every phase of their journey.) When I read Krystal’s observations in this article/interview, it occurred to me that they were so good, they could easily serve as… View Article

Forbes contributor Diane Mulcahy recently interviewed Krystal Hicks on the topic of “why companies don’t trust their employees.” (Krystal Hicks is the founder of JOBTALK – a resource for career-curious professionals throughout every phase of their journey.)

When I read Krystal’s observations in this article/interview, it occurred to me that they were so good, they could easily serve as a Checklist for 2020 Remote-Employee Success.

So I decided to organize them into that list! Here are some highlights from the interview, along with my added seven checklist points (in bold headers.)

1. Do You Trust your People?

Diane Mulcahy asked Krystal why so many companies are slow to implement remote or flexible work policies. Krystal’s response? “It’s trust. There’s no trust. And the mistrust stems from leadership.”

To quote Krystal further,

“Companies that are attracting incredible talent demonstrate that they trust their employees. They provide people with a choice about where to work, and the tools, like video conferencing, to make sure that they’re successful… Trust is the new currency, and the best talent wants to work for a company that trusts them.” 

2. Do You Measure Productivity Effectively? 

Krystal told a story about a client of hers who was concerned that remote workers wouldn’t work as hard if they were unsupervised. Her response to this fear is excellent:

“The real question for companies and leaders considering remote work policies is: How do you measure productivity when employees are at their desks in front of you? And if you do not measure them in the office, then it’s difficult to assume that people are going to be less productive at home. Companies need to figure out how they can implement metrics to measure productivity for everyone, no matter where they are working.”

3. Do You Have The Right People Managing Your Remote Teams?

“The Achilles heel of most organizations is promoting the wrong people into people management roles,” Krystal said.

“I think we have this epidemic of people who were great producers who received promotions into management, and they are terrible managers. There was an assumption made that because they were a great performer, that they would be a great people manager. And I think those are two starkly different things. And I’ve seen it be such a devastating move at so many of the clients that I’ve worked with because bad managers will chase out great employees.”

4. Have You Shifted from Blockbuster to Netflix?

 Diane Mulcahy asked Krystal what she means when she uses the term Managerial Darwinism. Krystal explained that what she’s saying is “adapting or dying. It is the understanding that there is Blockbuster and there is Netflix – you have a choice about which one you’ll be.”

5. Do You Accept That You Have Less Power/Control Over Employees Than You Used To?

 “Employers have less power because they no longer have the same level of control over their employees. Most importantly, they don’t own the financial future of their employees anymore. More employees have side gigs and no longer rely on their employers for 100% of their income. They’re earning money outside their full-time job, and that changes the power dynamic.”

6. Do You Hold Retention Interviews?

According to Krystal,

“I’ve heard of a lot of people say that they do exit interviews, but I believe there is such good information in retention interviews, where you talk to people that have been at the company for 3, 5, and 10 years and learn: What has kept them? Companies have amazing employees that they are not leveraging as a source of information.”

7. Do You Budget for Consultants? 

Krystal has observed that companies are thinking about consultants differently.

“They’ve either already had success working with a consultant, or they hear about other companies that have had a good experience, or they’re watching their high-performing employees leave to become independent consultants. Companies are realizing and recognizing that consultants are a reliable source of talent.

I’m also now seeing companies start to budget for consultants, which is a significant shift, and a strong indicator of demand, because when a company has a budget, they’re going to spend it.”

One more quote from Krystal Hicks helps conclude our checklist:

“The stakes are high for companies to figure out remote work because employees are really demanding it.”

By Dec 6, 2019