Mini bank application
I'm sorry to hear you got rejected - that's never any fun. I'll go through line by line, with some general comments at the end. 

Some of my notes are labeled as style suggestions; these usually mean generally accepted Java principles (naming conventions, etc.), so I'll try to point out where I'm trying to argue for a given style I personally recommend instead of giving a general rule.

import java.util.Scanner;

public class CreateAccount {


Style: classes should usually be nouns - e.g. Account or maybe AccountCreator, because you use them as Objects - so it makes more sense to have "an Account" than "a CreateAccount"

    int accountid;
    String accountantname;
    String IFSCcode;


Style: Java almost always uses Camel Case naming, so accountid should be accountID and accountantname accountantName, etc.

   public CreateAccount(int accountid,String accountantname,String IFSCcode){


Style: method names should start with a lower case letter EDIT: this is a constructor (my bad) and is therefore correctly named. Non-constructor methods should start with a lowercase letter.

    this.accountid = accountid;
    this.accountantname = accountantname;
    this.IFSCcode = IFSCcode;
   }

    /*//adding deposit money with the balance 


What is this comment supposed to tell me? The function is called depositMoney, so I expect that it will deposit money - you don't need to tell me that. Instead, it might be helpful to explain that the deposit amount comes from the user's input, or what the return value means

    public double despositMoney() throws MiniumAmountDeposit{

        double Currentbalance = 0.00;
        Scanner scn = new Scanner(System.in);
        System.out.println("please enter the deposit amount");
        double Depositamount = scn.nextDouble();
        Currentbalance += Depositamount ;
        System.out.println("your currentbalance="+Currentbalance);

        return Currentbalance;
    }*/


This method is a little busy - it would be nice if the functionality to get input from the user was somewhere else (in a separate function), especially because you need to use it for multiple commands.

Also, it really seems like Currentbalance (currentBalance, if we use Camel Case ;p) should be an object variable. 


  In the question paper they clearly mentioned that no data persistence is required.


BUT, I think what they meant is, no data persistence is necessary between program executions (you don't need to save account data to a file when the program shuts off, and read it back in when it starts up again). It would make a lot more sense to keep track of a user's balance while the program is running, and check, for example, that the user doesn't withdraw more money than they have in their account.

    //withdrawl money  and set daily withdrawl limit
    public void WithdrawMoney() throws InsufficientBalException, MiniumAmountDeposit{


        double Currentbalance = 0.00;
        Scanner deposit = new Scanner(System.in);
        System.out.println("please enter the deposit amount");
        double Depositamount = deposit.nextDouble();
        Currentbalance += Depositamount ;
        System.out.println("your currentbalance="+Currentbalance);

        /*double Currentbalanace = despositMoney();*/


See the above note - we probably don't want to force the user to deposit money before every withdrawal.

        //setDaily Withdrawl limit
           final double setDailyLimit = 2500.00;   


This is a configuration constant - it should go at the top of the class, before methods. If all users should have the same withdrawal limit, it should be declared static, too.

            Scanner withDraw = new Scanner(System.in);
            System.out.println("please enter the withdraw amount");
            double WithdrawMoney =withDraw.nextDouble();


        if(Currentbalance &lt; WithdrawMoney)
            System.out.println("you have less amount : your current balance is="+Currentbalance);

        else if (WithdrawMoney &gt; setDailyLimit)
            System.out.println("you have entered amount exceed than daily limit : your dailyLimit="+setDailyLimit);

        else 
            Currentbalance -= WithdrawMoney;
            System.out.println("your current balance is="+Currentbalance);

    }


These checks are good, nice job.

    /*public void setWithdrawlLimit()throws exceedLimit{
        Scanner scn = new Scanner(System.in);
        System.out.println("please enter the withdraw amount");
           double  enterAmount = scn.nextDouble();
        double DailysetLimit = 2500;

        if(enterAmount&gt;DailysetLimit)
            System.out.println("you have exceed daily limit : your dailyLimit"+DailysetLimit);


    }*/


I don't understand what this function is for.

    public String toString(){

        return "accountid="+this.accountid + "accountantname="+this.accountantname + "IFSCcode="+this.IFSCcode;
    }



    public static void main(String[] args){
        CreateAccount account = new CreateAccount(1234455533,"samy","ICIC09");
        System.out.println("you have created account : " +account);
    /*  
        try {
            account.despositMoney();
        } catch (MiniumAmountDeposit e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }*/

        try {
            account.WithdrawMoney();
        } catch (InsufficientBalException | MiniumAmountDeposit e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }

        /*try {
            account.setWithdrawlLimit();
        } catch (exceedLimit e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }


In general, you shouldn't leave auto-generated TODOs in submitted code. For an interview, I would be fine with leaving TODOs explaining functionality I wish I could implement but didn't have time for.

*/      
    }
}


And that's the end, so, overall: It looks like you have a solid start on the problem. The biggest issues I see (in order of importance (my opinion) for code turned in as part of an application):


The code looks a little rushed. Just like in a face-to-face interview, appearances matter for code that will be read and reviewed. Big chunks of commented code with no explanation, as well as misspelling / inconsistent naming schemes, won't make a good impression.
It seems like you're a little unsure of the problem specification. It can help a lot to think carefully about the input / output to each function, and what data will need to be stored in object variables, as you're writing your code - these things can change as you go along and understand the problem more. It's very helpful to document (write in comments!) the assumptions you're making about how the program should run.
There are some spots where you deviate a lot from established Java rules. No company has the exact same code style (here are Google's for Java), but there are some things (camel case, for example) that are very central to a given language. Not using camel case correctly when writing Java is a signal that you don't know Java very well - depending on the position you're applying for, this may or may not be a problem.


My biggest suggestions for improvement are: always submit the cleanest code possible, try to follow broad, important, rules for how the language should look, so it looks clean to the reviewer, and work on writing short, helpful comments around tricky or interesting spots in the code.