https://github.com/myturnyet/sixminuteinterview_java

https://github.com/myturnyet/sixminuteinterview_java

Last synced: 5 months ago
JSON representation

• Host: GitHub
• URL: https://github.com/myturnyet/sixminuteinterview_java
• Owner: MyTurnyet
• Created: 2021-03-31T04:24:40.000Z (almost 5 years ago)
• Default Branch: main
• Last Pushed: 2024-11-15T21:15:35.000Z (about 1 year ago)
• Last Synced: 2025-04-14T23:29:56.210Z (9 months ago)
• Language: Java
• Size: 60.5 KB
• Stars: 5
• Watchers: 2
• Forks: 3
• Open Issues: 0
• Metadata Files:
  • Readme: readme.md

Awesome Lists containing this project

README

          
## Six Minute Interview (Java version)

### First, the why...

This interview challenge is based on the six minute interview created by [LLewellyn Falco](https://github.com/isidore).

The idea behind this challenge is not to have the candidate solve the challenge, but to get an idea of whether the 

candidate understands certain principles of development.  

After 6 minutes, you should be able to answer several questions, with the most important being:

>__"Do I want to see more from this candidate?"__

This challenge works best as an _online screen_, because it is meant to be short and give you lots of information.

  You should be able to make a decision about whether to move forward (and see the candidate code for more time) fairly

 quickly (_say, 6 minutes..._)

 

 If you schedule the phone screen for a short time, maybe 15 minutes, you can get basic information from the candidate

 and then run them through this challenge.  If they fair well, ask them if they can continue for another 45 minutes and 

 make this a full hour interview.

 

 If they fair badly, you can cut the interview short without sending a huge let down to the candidate.

### Next, the how...

This is a quick test and, for a person with a development background, should be pretty straightforward.  However, there

are intstructions that should be read (or given) to the candidate.  

The most important point is to assure them that **they will not be judged on whether they finish** the problem.

Make sure the candidate is at ease with this.  This is much more about the process than the outcome.

Then, read them this script:

> This is a six minute code challenge.

>

> You will not be judged on whether you finish the problem, so please take your time and work through it as you 

would without a time constraint.

>

> The object of this challenge is to **make all the tests pass**.

>

> You will not finish this challenge.  That is okay.

>

> **Please talk aloud** about what your thinking as you go through the challenge.

> 

> You may **ask any questions**.  I may or may not answer them.

>

>  I may give you hints and help throughout the challenge.  That doesn't mean you are doing badly, it means I want to

 emphasize or help you along.

>

> At the end of six minutes, please stop typing where you are. 

Then after the challenge, you may engage a discussion if you think it would be beneficial to you or the candidate.

### And finally, the what...

Here are a ist of things to look for when administering this during an interview:

* __Do they know the IDE that you're using?__

    * You should be using the IDE that is used regularly as part of your work.

    * If they are having issues, ask yourself:

        * Do they know how to use antoher IDE?

        * Are they using Hot Keys or shortcuts?

        * If you tell them a shortcut, will they incorporate your feedback?

 

* __Do they know the language?__

    * You should be using a language that is used regularly as part of your work.

    * If they don't, it's not a disqualification, as long as you can answer _yes_ to the following:

        * Do they know another similar language?

        * Do they understand Object Oriented languages?

        * Can they learn this language?

        

* __Do they know about tests?__

    * Did the candidate run them? _(amazing how many times they don't)_

    * Did they run them before making changes to the code?

    * Did they run them all, or focus on a single test?

    * What were they focusing on in the tests?

        * Unit testing, Functional testing, Code Coverage numbers?

    

* __How long did it take to get a passing test?__

    * Did the candidate write any code? (_again, amazing how many don't get to it_)

    

* __Did the candidate refactor any of the code?__

    * Were they positive refactors?

    * Did they refactor the code, or the tests, or both?

    * Did they make sure the tests passed before and after refactoring?