Reminds me of a recent take home test for a SRE role I completed recently.
Normally when it comes to take-home tests I set a hard limit on actual working time to 3hrs. This doesn't include any research or reading I will do ahead of time.
The test itself was:
> We have 3 services that we want to have running in a kubernetes cluster.
> The first service is a software application called JIRA which will be used internally for the company, so we only want to be accessed by specific IP’s.
> The service needs to be highly available, have failover tolerance and able to restore from backup.
> The other services are a golang application and a python application which we provide the code.
> Inside the go-service folder we will find the golang application which exposes 2 HTTP endpoints, one of those endpoints, talks to the python microservice through GRPC protocol.
> It has 4 environment variables:
> - PORT (the port on which the http server will run)
> - SERVICE_ENDPOINT (endpoint to the python service)
> - REQUEST_TIMEOUT (request timeout in seconds)
> - IDLE_TIMEOUT (idle timeout for requests in seconds)
>
> Inside the python-service folder there is a python microservice, which only supports GRPC Protocol. This service does not have to be exposed to the outside world, and it can only be contacted by the go lang service.
> The python microservice supports a single environment variable:
> - PORT (the port on where is going to be running)
>
> These services also require high availability, failover tolerance, and also they need to scale according to the load they receive, as our external clients consume them.
> Deliverables:
> - Dockerfiles for the 3 services
> - Full yaml configuration for the services to be deployed in a k8s, taking into
consideration the remarks above.
> - A diagram explaining the whole infrastructure and how it is connected with each other.
> - Paper with ideas on:
> - Monitoring
> - Instrumentation
> - Security
Now, to be perfectly fair, I knew much more about how kubernetes works than how to deploy services on it, so it might have taken me a little longer to create the deployments. However, there's no way that I can make that all work in 3 hours. Not to mention that the backend code I was given wouldn't compile so I had to fix bugs.
Additionally; if I spend more than 3hours on a test, I might as well spend 6 hours, or 12 hours, or a week... At some point it becomes impossible for you to interview at multiple places. The idea of spending 9hrs of my day at work, then coming home and spending another 3hrs+ every night because I want the opportunity to keep spending 9hrs at work is insane, I'm physically unable to do that. When I get home I'm usually burned out, so these kinds of tests are done on the weekend.
Anyway. Where I work, we also give a take home test, and I apply the same principles:
If one of our team can't do it inside of an hour, we don't send it. We expect a candidate to be able to do it within 3hrs. The point of the take home test is that it's something we can discuss later, too. It's really obvious if someone struggles hard or finds it too easy.
Normally when it comes to take-home tests I set a hard limit on actual working time to 3hrs. This doesn't include any research or reading I will do ahead of time.
The test itself was:
> We have 3 services that we want to have running in a kubernetes cluster.
> The first service is a software application called JIRA which will be used internally for the company, so we only want to be accessed by specific IP’s.
> The service needs to be highly available, have failover tolerance and able to restore from backup.
> The other services are a golang application and a python application which we provide the code.
> Inside the go-service folder we will find the golang application which exposes 2 HTTP endpoints, one of those endpoints, talks to the python microservice through GRPC protocol.
> It has 4 environment variables:
> - PORT (the port on which the http server will run)
> - SERVICE_ENDPOINT (endpoint to the python service)
> - REQUEST_TIMEOUT (request timeout in seconds)
> - IDLE_TIMEOUT (idle timeout for requests in seconds)
>
> Inside the python-service folder there is a python microservice, which only supports GRPC Protocol. This service does not have to be exposed to the outside world, and it can only be contacted by the go lang service.
> The python microservice supports a single environment variable: > - PORT (the port on where is going to be running)
>
> These services also require high availability, failover tolerance, and also they need to scale according to the load they receive, as our external clients consume them.
> Deliverables:
> - Dockerfiles for the 3 services
> - Full yaml configuration for the services to be deployed in a k8s, taking into consideration the remarks above.
> - A diagram explaining the whole infrastructure and how it is connected with each other.
> - Paper with ideas on:
> - Monitoring
> - Instrumentation
> - Security
Now, to be perfectly fair, I knew much more about how kubernetes works than how to deploy services on it, so it might have taken me a little longer to create the deployments. However, there's no way that I can make that all work in 3 hours. Not to mention that the backend code I was given wouldn't compile so I had to fix bugs.
Additionally; if I spend more than 3hours on a test, I might as well spend 6 hours, or 12 hours, or a week... At some point it becomes impossible for you to interview at multiple places. The idea of spending 9hrs of my day at work, then coming home and spending another 3hrs+ every night because I want the opportunity to keep spending 9hrs at work is insane, I'm physically unable to do that. When I get home I'm usually burned out, so these kinds of tests are done on the weekend.
Anyway. Where I work, we also give a take home test, and I apply the same principles:
If one of our team can't do it inside of an hour, we don't send it. We expect a candidate to be able to do it within 3hrs. The point of the take home test is that it's something we can discuss later, too. It's really obvious if someone struggles hard or finds it too easy.