New Feature: Dynamic Tests

Our customers tell us that they often wish each Candidate being assessed is given a different Test. The idea is to have a pool of questions of a similar kind, and have the system select a subset of questions to present to each Candidate.

HackerRank for Work has long supported shuffling of Questions in a Test. In this model all candidates will see the same set of questions, but the order in which the questions are presented is different for each candidate. Today we are very excited to launch a new feature – “Dynamic Tests” that helps users automatically build an entirely different Test for every candidate based on specific rules.

The first thing you would do to start using the Dynamic Tests feature is to add tags to the questions you are interested in using in your Test. Make sure similar questions are tagged with the same labels. For e.g. add the ‘Easy’ tag to all questions you consider easy, or ‘Polymorphism’ to all questions related to object oriented inheritance concepts, and so on. Note that questions in the HackerRank for Work library are already extensively tagged.

Once you have your questions tagged, you can enable this feature by going to the Tests’ Advanced Settings page, Miscellaneous section. Once this feature is enabled, you will be able to add one or more rules, with each rule specifying the Tags to be matched and the count of questions to be picked with those tags.

Pasted_Image_21_04_16__7_57_PM

Note: You can specify multiple tags in a rule. For e.g. you can choose 1 question that has both ‘Easy’ and ‘Algorithms’ tags. You can also specify a second rule to select 2 questions for Logic or Data Interpretation, etc.

Take this feature for a spin, and let us know what you think!

Unified login across CodePair and HackerRank for Work

As a HackerRank for Work user, if you start a CodePair interview while already logged in to your HackerRank for Work account, it is reasonable for you to expect that you don’t have to log in a second time. Unfortunately that is not how it was. With a change that we are releasing today your HackerRank for Work and CodePair sessions share information so that you have to only log in once.

Here is what you would see if you visited a CodePair link while being logged in to your HackerRank for Work account from another browser tab.

CodePair sharing cookies

 

This login sharing works in the opposite direction too. If you start a CodePair session, and then visit you HackerRank for Work account you will not be prompted for a password.

Finally, it is important to remember that if you log out of your HRW session while a CodePair is going on, you will be logged out from both places. Don’t worry that does not mean your data will be lost, it only means you will have to log in again to access your pad.

Any questions or comments? You can leave a note below, or write to us at support@hackerrank.com

Scheduled Maintenance on Oct 21, 2015

HackerRank for Work will be down for scheduled maintenance on Oct 21 from 01:30 AM – 04.30 AM PDT. We’ll be performing some system enhancements that’ll make your user experience even better (and faster) than it already is. During this time no one will be able to access the HackerRank platform.

Frequently Asked Questions

How does this impact Test Candidates

The Tests interface will not be available during the maintenance window. Candidates will see a notification to come back at a later time. Further we will ensure that candidates are allowed to start their Test only if they can complete it before the start of the maintenance window. For e.g. if candidate Tom tries to start the “HackerRank Java Test” that is of 90 minutes duration after midnight on that day, he will be prevented from doing so as the scheduled end of the test will overlap with the maintenance window.

How does this impact CodePair Sessions

New CodePair sessions cannot start during the maintenance window, and upto 90 minutes prior to the start of the window. For sessions that are live as we approach the window, we will show warnings to the participants so they can wind up their interview. Please be assured that interview data recorded before the maintenance window starts will be safe.

How does this impact my Reports

You will not be able to view reports or dashboards during the downtime.

As always, if you have any questions, please give us a call at +1 415 900 4023 or e-mail us at support@hackerrank.com

Internal Notes comes to all Question Types

Earlier this year we implemented a feature that allowed Coding challenge creators to add internal notes. The feature has been a hit with our customers, and many requested us to extend it to other question types. So here it is. From now on you will be able write internal Notes for all questions, just below the Problem Statement.

Just to recap – Internal Notes appear in the Question view in your HackerRank for Work account, and candidate test reports. Candidates cannot see them. So go ahead and use them to document what a reviewer should watch out for while manually grading a question, or to note down why a particular question is worthy of being included in your library, etc.

Internal Notes

 

SSL Cipher Change Notification

As a standard part of our security review process, we will be changing the set of ciphers supported by our web servers in our AWS ELB cluster. The changes will go live on Thursday, 18 June 2015 at 12:00 Hrs UTC The following ciphers are being dropped:

  • DHE-RSA-AES128-SHA
  • DHE-DSS-AES128-SHA

With this change we are effectively enabling the “2015-05” pre-defined security policy available on Amazon’s Elastic Load Balancer. You can find more information about the security policy here.

Qn: What does it mean to disable an existing cipher? A client (such as a browser) typically supports multiple ssl ciphers. As part of the handshake the client and server agree on one specific cipher. If the server rejects a requested cipher (because it is no longer supported) the standard protocol is for the client to request another cipher from its list of supported ciphers. All standard browsers and most API SDKs work on these principles and the change should be completely transparent to end users.

Qn: Why is this change required? This is a standard part of keeping our security infrastructure up to date. It is security Best Practise to replace ciphers that have been shown to have theoretical vulnerabilities with more robust ones.

Qn: I am using a custom API integration with a highly bespoke SSL wrapper and I use one of the ciphers that are going to be disabled. What should I do? You can test your software by requesting one of the supported ciphers listed in the AWS page linked above. If any of them work, you can configure your wrapper to request that supported cipher instead of one of the disabled ones.

Qn: Will there be any disruption of service during this change? No. There will be absolutely no disruption if you are using a standard web browser to interact with our application, or if you are using any standard SSL SDK.

Qn: I need more help. What can I do? We are happy to help. Please leave a comment below or send us a note at support@hackerrank.com

Test Report Emails – Change of Source Email Address

When one of your candidates completes a test, some key details are sent over to you as an email. The email is sent to the recruiter who invited the candidate and any one else you have explicitly configured in the Test’s Advanced Settings.

The email used to be sent from reports@interviewstreet.com. As part of an ongoing email infrastructure revamp we are retiring that address. The report emails will come from reports@hackerrankforwork.com starting immediately.

If you have any email filters in place please make sure to update them.

SSL Cipher Change Notification

As a standard part of our security review process, we will be changing the set of ciphers supported by our web servers in our AWS ELB cluster. The changes will go live on Tuesday, 26 May 2015 at 12:00 Hrs UTC

The following ciphers are being dropped:

  • ECDHE-RSA-RC4-SHA
  • RC4-SHA

The following cipher is added:

  • DES-CBC3-SHA

With this change we are effectively enabling the “2015-03” pre-defined security policy available on Amazon’s Elastic Load Balancer. You can find more information about the security policy here.

Qn: What does it mean to disable an existing cipher?

A client (such as a browser) typically supports multiple ssl ciphers. As part of the handshake the client and server agree on one specific cipher. If the server rejects a requested cipher (because it is no longer supported) the standard protocol is for the client to request another cipher from its list of supported ciphers. All standard browsers and most API SDKs work on these principles and the change should be completely transparent to end users.

Qn: Why is this change required?

This is a standard part of keeping our security infrastructure up to date. It is security Best Practise to replace ciphers that have been shown to have theoretical vulnerabilities with more robust ones.

Qn: I am using a custom API integration with a highly bespoke SSL wrapper and I use one of the ciphers that are going to be disabled. What should I do?

You can test your software by requesting one of the supported ciphers listed in the AWS page linked above. If any of them work, you can configure your wrapper to request that supported cipher instead of one of the disabled ones.

Qn: Will there be any disruption of service during this change?

No. There will be absolutely no disruption if you are using a standard web browser to interact with our application, or if you are using any standard SSL SDK.

Qn: I need more help. What can I do?

We are happy to help. Please leave a comment below or send us a note at support@hackerrank.com

Candidate and Tests API v1 Sunset Notice

Two of our oldest APIs – The Recruit Candidate API and Recruit Test API – are being deprecated with immediate effect and they will be completely shutdown on 30 April 2015. The older APIs are replaced with a much improved v2 of the HackerRank for Work API, documented here: http://apidocs.hackerrank.com/hr4wv2

 

Most of the changes are backward compatible and many users will simply need to use the new v2 end points. You can read about all the changes in our Migration guide, and if you have any questions about this or need any assistance migrating to v2, please drop us a note at support@hackerrank.com

Scheduled maintenance update

We are having a scheduled maintenance on 19 March 2015 from  09:30 UTC to 12:30 UTC. During this time the following pages will not be accessible:

  1. The test report timeline view
  2. The consolidated candidate activity view

Other than the above mentioned pages you will be able to invite and review candidates without interruption. Candidates attempting tests will not be affected in any way.

If you have any queries about this migration or any other related issue drop us a note at support@hackerrank.com

 

Unified Candidate Timeline

If you are a recruiter using HackerRank for Work who wanted to pull together a comprehensive view of all Test and CodePair activity of a particular candidate, you would have realised that is not possible. Well, till today! We are happy to announce the launch of a simple but exciting feature that unifies all of your interaction with candidates. We do this by creating a unique page per candidate that consolidates all the activity related to that candidate, such as invite sent, test attempted, CodePair interview scheduled, etc.

Here is a sample unified timeline:

Unified Candidate

Here you can see Shikhar’s personal profile – as captured in your Test forms, a profile photo picked up from Gravatar (if available), and all Test / CodePair activity neatly shown along a timeline.

Entry Points

Anywhere you find a candidate email address as a link, clicking on the link will take you to that Candidate’s page. Currently there are four types of pages where you can find these links:

  1. The candidate search results (what you get from using the search box in the common header found on all pages of the app)
  2. Reports tables – invited, completed, and all other report tables where we display the email address of a candidate
  3. Within a Test Report
  4. Within a CodePair Report

 

Privacy and Information Seggregation

One word of reassurance before we wrap this up.

Your company’s interactions with a candidate is your data and will not be shared with anyone else, just like you do not get to see any other company’s interactions with said candidate. The candidate timeline you see is just the candidate’s interaction with your company.  In fact the candidate page URL contains a unique identifier that a candidates gets assigned for your company. Even if this same candidate has taken a test or CodePair interviews with another company they would be assigned another identifier. This logically separates candidate records across companies and protects your data.

Any feedback or enhancement requests? Drop us a line below!