Bad Design

We are a little behind schedule on our latest software delivery at work. I told the management that we will not make the dates unless we get more help. It took a while for that to sink in. The managers kept coming back asking me how we could make the dates. I kept repeating that we needed more people or it was absolutely impossible. Finally we got another resource.

The extra guy is a proficient one. The team gave him some changes to an application he designed and built years ago. We figured he would be happy to work on his little baby. Today he called me up because he was confused about how to add some spreadsheet filtering. I reminded him that this was his creation. He remembered part of the crazy filter design. However he could not recall how the filter GUI worked.

Now if the designer cannot come in and figure out how the UI works, we have some big problems. He tried to check out the resources for the dialogs. They were missing. I guess he had implemented some kind on non-standard dialog generation on the fly. Well he has to eat his own dog food now. He is stressing due to the time lines. I told him I gave him plenty of time in the schedule to get the work done. Nobody figured that his own design would be tripping him up.

Out of Control

On Friday afternoon I had wrapped up my development tasks for the week. It was looking to be a good weekend. Then I got that dreaded call. Another developer was stuck on a customer problem. The customer said a new report implementation was not working. The customer had said the report did not match the application. Our developer needed help. I had no choice but to assist.

I told the developer it would take around 20 minutes to compare what the application and report were doing. She told me they needed to ship the software in an hour. I dove in, and found some discrepancies. So I called the developer back. She asked me to conference in a lot of people with that call. So I did. Then I explained what I found, and gave some recommendations.

The manager on the call said he thought the new report was not correct. Then he asked if the old and new reports were equivalent. The developer answered yes. He wanted a second opinion. All the other developers took a step back, leaving me holding the bag again. So I quickly printed out pages and pages of the old and new report queries. Wouldn't you know it? I found a subtle but important difference in the SQL.

We held another conference call. By the we were right at the point where we needed to ship the software. I provided my findings and helped everyone understand the implications. Our manager had more questions. I told him he should assign someone to go research the answers to those questions, and I told him it needed to be somebody other than me. He said he needed me to do it. Then I told him no. We later had a private conversation where I reiterated my position. He then got a VIP from our company to call us up. I told him no as well.

I don't mind working on customer problems. In fact, I enjoy them. However I don't like coming in at the last minute and cleaning up other peoples messes. If I keep doing that, I set a bad precedent. This just encourages sloppy work, bypassing processes, and making me stay late due to other people's incompetence. I figured it was time to take a stand. Perhaps some nice article I read about saying no helped me grow the courage to do so. Let us see how this turns out. So far I have not been fired. But it is still early in the weekend.

Order of Importance

I had a week to implement the latest new feature in our system. The coding got done in 4 days leaving one extra day. On that day I performed a number of tasks to make the code complete. It is interesting how I ranked the remaining tasks to be done. I made sure the most important things were done first.

The number one item on my agenda was to ensure the program was functionally correct. That is the main thing the customer cares about. Next I made sure my unit tests were documented. This is to meet CMMi standards.

I then went back to my code to ensure it was modular. This meant breaking up some bigger functions into smaller ones, and combining like functions together. In other words I refactored. Then I beefed up the user interface, making sure I put in controls that did not allow the user to make entry errors.

Next I went back and deleted any obsolete code that was still there but commented out or unused. Finally I did a round trip and updated the design documentation. I did not have time to do any performance tweaks. This task fell off the list due to time constraints. Get the most important things done first. You will not have time to come back later and fix things.

Interview Wrap Up

This time I wrap up the lessons learned by reading Programming Interviews Exposed. Although I have never personally be asked any drawing questions in an interview, I suppose you might get some if you are trying to get a game developer position. I can't go into a lot of details of computer drawing. But it is good to know that high performance drawing relies on using integer math.

I do know you will get asked about SQL in interviews. Most questions revolve around the INSERT or SELECT statements. Know them well. If you are faced with a brainteaser, try to solve a sub problems first. You may get the insight you require.

A general rule is to make sure you can talk deeply about every technology listed on your resume. This is basic. Finally don't paint yourself into a corner when answering to what your favorite programming language is. The chances are that the interviewer does not share your choice, and may count it against you. Provide a general answer to such a question.

Next time I am going to get back to some real life stories and intuition I have gained on the job as a software engineer.

About Graphs

A more complex data structure in computer science is the graph. Each node can point to many other nodes in the structure. If the edges of the graph only go in one direction, it is called a directed graph.

Next let me mention arrays. Specifically I want to tell you about dynamic arrays. These are arrays that can change size at run time. They are usually implemented with static arrays.

Recusion is an elegant solution for many problems. However the function call overhead means the recusive solution is often expensive. Iterative methods can use the stack to do recusive style solutions. In general you should try to find a correct solution to a problem first. Then you can come back and make it fast.

Next time I plan to wrap up my hints on interview techniques. I will cover drawing, SQL, brainteasers, and your resume. Then we can get back to discussing software maintenance in general.

All About Trees

Even though linked lists may be the most popular data structure for interview, trees are a close second. A tree is a structure where each element has some number of child nodes. A binary tree is a special kind where each element has at most two children. A further specialization is the binary search tree. Nodes on the left are less, while nodes on the right are greater.

A balanced tree has the same number of nodes on the left and right child subtrees. This makes for an optimal search if it is a binary search tree. If a tree gets too unbalanced, it starts to behave like a linked list (which has worse search performance).

If you get a question at an interview on trees, try to think about recursively solving the problem. Here are some more tree facts. Traversing the tree means to visit all the nodes in the tree. And a heap is a binary tree whereby each node has a value less its parent node.

Next time I will briefly mention graphs. Then I will cover arrays.

Linked Lists

When I applied to graduate school in Computer Science, I was told to learn data structures and give them a call back. Ouch. I did eventually pick up a whole class on data structures. It was actually quite fun. This knowledge can help you through a question during an interview which centers around common data structures.

The most basic and favorite data structures for interviewers is the linked list. Obviously there are different types of linked lists. But for all of them you should check for NULLS when traversing it. You also need to know that deleting a record in the list requires at least two pointers.

Oh snap. We are out of time. Next time I will talk about the types of tree data structures in computer science.

Big-O Notation

When you are in an interview, you might be asked how efficient an algorithm is. This is a case for Big-O analysis. An algorithm whose run time grows linearly with the number of records it processes is said to be on the order of O(n). That is good efficiency.

Other Big-O rates are O(1), O(nlogn), and O(n^2). In the Big-O system, you eliminate all but the highest order time factor. So if an algorithm has an efficiency of O(n^2) + O(n), we just call it O(n^2). The O(n) part of the equation is insignificant.

Some bonus tips for analyzing efficiency are to consider both the average and worst case times for an algorithm to complete. Next time I will briefly talk about data structures like linked lists. Say that fast 3 times.

Problem Solving

When you are in an interview trying to solve problems, it is you general problem solving skills that will come to your aid. It is fruitless to try to memorize answers to specific questions. The problems presented are selected to prevent any such rote memorization.

One trick is for you to work through a specific example with the the problem. That may give crucial insight to the general solution. You should focus on the algorithm you use for the specific example.

Don't be afraid to talk through your thought process. This is actually encouraged. The interviewer likes to hear this. Remember to check for special cases once you think you have arrived at the general solution to the problem.

Know this. The correct solution to a given interview problem is usually very short. Around 10 to 15 lines of code should be sufficient. Therefore if you run out of room on the whiteboard, you are probably headed in the wrong direction. Next time I will cover the basics of Big-O notation.

Interview Questions

This time I am going to delve into techniques to successfully answer questions during an interview. But first let's cover some background info. Companies make offers to less than 10% of the people they interview. So don't get discouraged if you do not get that job immediately.

You should code solutions during an interview in mainstream computer languages. Whether accurate or not, the mainstream opinion is that Visual Basic and JavaScript are considered lesser languages. I know my VB friend would disagree. However he is not the person making the hiring decision. Code your examples in C++ or Java during an interview. You could also safely resort to plain old C.

Let's get this out. Questions asked during interviews are hard. That is the point. You might even ask questions that you have no chance of answering correctly. This may just be a test to see how you handle such a stressful situation. Look for hidden assumptions in the questions. Ask your own questions to clarify the problem at hand.

I got a lot more to say about interview questions. Look for a follow-on post very soon.

More on Interviews

The national unemployment rate in the US is 9.8%. In a neighboring state, the local rate is over 11%. You are going to need every competitive advantage to get a job in this economy. Let's start with the in-person interview.

I have heard different opinions on what to wear to an interview. If you are a guy, I strongly recommend wearing a suit and tie. I don't care if you are going in to be the french fry guy at McDonald's. Put on that suit.

A recruiter is out to get as many people hired, and to get you to accept the lowest offer. You should focuses on getting job details from actual employees of the company who will hire you. Bypass the recruiter by getting business cards from the people you talk with during your interview.

When you complete an interview, you should never accept a job offer on the spot. Give it some time. Everything about the offer is usually negotiable. Why not get a couple more thousand in salary? As long as you are respectful and reasonable during negotiations, they will not bar you from getting the job once they offer it to you.

Programming Interviews

The other day I spoke with a developer on my team. I knew she was doing double duty each day, and working Saturdays/Sundays. So I asked how she was doing. She confided that she thinks about quitting every day. Ouch. I know the feeling.

Some time ago I read this book on programmings interviews. I think I actually bought the book. Just recently I checked a book out from the library with the same title. I think it was an earlier version of the book from the year 2000. It still had some good stuff in there.

I want to share some of the tricks here. With this economy, everyone needs to be prepared to ace in interview to get a job. The best preparation is to actually work through some coding examples on your own. It is hard to learn enough by just reading a book. You must learn by doing.

Programming in general is difficult. The best way to find a job is to network. If you get a recommendation from the inside, you move to the front of the line. You should avoid headhunters that want you to work with them exclusively. Know that headhunters look out for their own self interests.

The most important factor in getting a job is the on site interview. Succeeding there is what this book tries to teach you. I will be blogging about this topic for a little bit. Next time I will start on what you should wear to your tech interview.