[Java] Print out numbers of Fibonacci Sequence

Java - Print out numbers of fibonacci sequence.

In preparation for my Microsoft interview, I am going over some different ways to do the Fib sequence. Here is a simple iterative method to print out n fib numbers.

public static void main(String[] args) {
  // TODO Auto-generated method stub
  Scanner s = new Scanner(System.in);
  
  System.out.println("Enter n:" );
  int num = s.nextInt();
   int n0 = 1, n1 = 1, n2;
   System.out.print(0 + " " +n0 + " " + n1 + " ");
   for(int i = 3; i < num; i++)
   {
    n2 = n1 + n0;
    System.out.print(n2 + " ");
    n0 = n1;
    n1 = n2;

   }
   
 }

The interviewer could ask a number of questions from this point. E.x. Where might errors arise?

1. No cases defined for n=0, n=1, n=2
2. What if a non-number is given in input?
3. Negative number ?
4. What if a huge number is given in input? 99999999999?

These are all error-prone areas they will expect you to know to test.

Read More

How to "wow" employers in programming interviews

I found an excellent article on Programmers SE discussing ways to "wow" employers at interviews. The article can be seen here.

From the pages of discussion, I gathered these main points:

• Know your skillset. Be prepared to discuss what you know and use examples to back that knowledge up. Employers very much care about what you know.
• Be prepared to problem solve under pressure. Part of figuring out how much you know is by putting you to the test. Usually, employers will stick to simple problems that require a bit of thinking. There is not going to be anything like "print out every index of an array" but at the same time, you are not going to be expected to implement your own LinkedList.
• Treat your interview like a powerpoint presentation. Not one you are doing for a business class you don't care about. One you are doing for your future boss to show him your branch is above the expected output quota. An interview is very much a negotiation; you must sell yourself on your strong points. When someone buys a new car, they don't just ask what it does. They want to see how it does it through test drives and manual inspection. Expect the same behavior when interviewing.
• Rehearse your selling points. Be confident in them as well. Don't know what your selling points are? You better brainstorm them before your interview! Nothing is more distracting than a paragraph of um's, uh's, like's and incomplete sentences. 

Read More

You are shrunk to the height of a nickel and your mass is proportionally reduced so as to maintain your original density. You are then thrown into an empty glass blender. The blades will start moving in 60 seconds. What do you do?

Given that you are a size of a nickel, you won't be able to make much noise and you surely won't be able to escape on your own. If you are stuck inside a blender in the Google office, chances are you probably won't be able to jam the blades before they start turning as it is a very nice Black & Decker model blender.

That really narrows down your options. If you had a grappling hook, you could easily escape. But who carries grappling hooks around waiting to be shrunk and stuck inside a blender? No one.

Lets take a look at the facts:

Blenders do not operate on their own. Maybe the fanciest ones have timers, but that doesn't make much sense to have a blender auto-start. It isn't like coffee. So someone has to be pushing that button to start the blender in 60 seconds. Your best bet is to jump around frantically waving your arms to get their attention before they dump their blender food in on you. Since the blades are probably shiny, and just maybe, the sun is shining in on the room, you may have a chance to run around the blades and the reflection may catch their eye. (shiny to covered and back to shiny). At this point , you engage the individual in a discussion in which you may need to plead for your life if they are a generally apathetic or cynical person. Otherwise you are good to go as far as getting out of the blender. But the problem doesn't stop there. You are the size of a nickel. You must now go home and watch Honey, I Shrunk the Kids! and watch it till the end (Yeah, I know...) to see how the kids get returned to normal size. Follow the same steps in the movie and you will be back to normal. And then you can enact revenge on whoever attempted your murder by miniaturization and death by blender.

This is how I would answer this question.

Joseph

Read More

Amazon Software Engineer Intern Interview : What To Expect

Interview length: Two 45 minute back-to-back interviews

Preparation given: The evening before, the morning of

I had an on-campus interview with Amazon yesterday. The recruiters live up to their reputation. The interview felt more like a test rather than a standard "why do you want to work for us, what will you bring us" questionnaire. I spent the day before brushing up on terminology and reading other peoples' stories on how their interviews went. Every interviewee signs a non-disclosure form so I cannot share the questions that I was given, but I can say a few things about the process to help you.

First, you need to brush up on your knowledge of com sci courses- everything ranging from digital logic, discrete mathematics, to data structures. These are all areas that they want to test their future hires to make sure they understand. You  don't need to know every single data structure out there, but avoid the mistake that I made; for some reason, I went into the interview thinking "data structures" referred to the data structure defined in Java. Data structures refer to any models that handle data; i.e. Sets, Trees, Maps, Queues, etc.

Second, know algorithms and how they work. Runtimes and Big O notation are very important to know. You will more than likely be tested on your knowledge of these. I perceive Amazon to be a company seeking out the best time-constraint algorithms out there, so naturally, they want to know if you can solve problems with algorithms that run fast.

There are a few areas of error that I should have been more careful on , but I wasnt. Namely, the second interviewer gave me the same code question to solve as the first interviewer. Not thinking, I said, easy, you do it like this. Im sure that will come back to haunt me as I am not given an offer! I wasn't sure if it was some sort of test by asking it again or not- you'd think they would have coordinated who would ask what questions.

The 45 minute interviews go by pretty fast. Sooner than expected, the interviewer will say that time is up, and you will either move to your second interviewer, or finish for the day. 

The interviewers are not like normal interviewers, in the sense that they dont care so much who you are as to what you know. During the interviews, they want answers. You either answer correctly or you dont. They helped me to an extent in areas that I had forgotten some of the terminology with- but Im sure that reflected negatively in my review. When you give an answer- make sure you know it works. They will not hesitate to dissect your answer to make sure you fully understand what you are talking about.


For example, if you write an algorithm that checks if the parameter int is an even integer greater than 0, remember to ask yourself these questions:

What are different ways to test this method? Different values for the parameter? How does the algorithm handle them? 

Is this the simplest way to solve the problem? What alternative implementations could be done and how do they compare in efficiency?

Another thing to note is, you will be coding under pressure. You will be asked to give solutions to problems on the spot, whether you visualize and repeat orally, or write it down on paper. What really irked me was the fact that no time limit was specified or general amount of time to spend on it. I guess they assume everyone to have a solution within minutes of starting. Then again, the problems are not too challenging, so you shouldn't have to take any longer to figure them out.

My advice: Treat this interview like a midterm exam. Starting to prepare for it the night is a bad idea. Do as many simple algorithm questions as you can - writing code to solve problems. Write the code out or try and visualize it, as you are expected to do one or the other during the interviews. Personally, Ive never been a visualizer with code. They dont mind if you chose one item over the other. There are a ton of websites out there where you can do test problems (e.x. www.codingbat.com ) , and even more sites that offer problems with solutions.

After the interview: When "interview mode" was off on the interviewers, they were very friendly individuals. Not to say they werent during the interview, but there was a clear change in behavior from professional to relaxed and casual. In discussing their own experiences, they only had raving things to say about Amazon. They give you time to ask questions about the company. If you feel comfortable with the interview thus far, ask some general questions, like "What type of work do interns normally do over the summer?" or "what made you choose to work for Amazon?" and "Have you ever interned with Amazon?"

Read More