My Thoughts & Views

Archive for the ‘General Programming’ Category

Interfaces
–contain only abstract methods
–interface can’t be inherited from a class
–using interfaces we can achieve multiple inheritance
–doesn’t allow accessibility modifiers (Public/Private/Internal)
–can’t contain fields, constructors
–is must implementable & its scope is upto any level of its inheritence chain.

Abstract Class
–contain both abstract methods as well as concrete methods
–can extend another class and implement multiple interfaces
–we can’t achieve multiple inheritance
–allows accessibility modifiers
–can contain fields, constructors
–class Abstract class is must inheritable & its scope is upto derived class

Here is the list of tips & insights compiled from StackOverFlow.


1. Never be afraid to say I don’t know.Manage expectations, learn to say “no”.But always give it a try before you say that.
2. Never stop learning.Accept your mistakes and take that just as a new learning opportunity
3. Ask for help sooner rather than later,know that you can’t do everything by yourself.Don’t take all the responsibility for a problem. Sometimes you can be furiously trying to solve a problem alone and carrying the problem on your back. Get other people involved, escalate, get other folks involved.
4. Learn to take backup
5. Assumption is the mother of all screw-ups. So never assume something which you are not sure of.
6. Estimates are always off by at least 50% either way.
7. First make it work, then make it better.
8. Always negotiate deadlines/deliverables.
9. Don’t hesitate to do overtime IF the situation requires it
10.Underpromise and over deliver
11.Find the balance between being realistic and being positive.
12.Be confident in your skills
13.Listern patiently to others opinion. Especially when you talk to a client.
14.Share your skills – Help others and the community with the knowledge you’ve got.
15.Make sure you get proper recognition and appraisal for your good work.
16.Manage your time effectively
17.Don’t give people what they ask for, give them what they need.
18.No matter where you are on the pecking order of a team or project, you CAN make a difference.
19.It’s more important to manage people’s perception of the problem than it is to fix it.
20.Never trust the data. Validate your inputs.
21.”It works on my machine” doesn’t cut it. It HAS to work for them, too.
22.Show your code to other people – and listen to their comments.& Look at other peoples code and talk to them about it.
23.If you can’t figure out a problem then take a break and come back to it in 10 or 20 minutes – makes finding a solution so much easier.
24.Realize that specifications are going to change.
25.Never implement new features unless you have a written request ( mail is just fine )
26.Be prepared to reinvent yourself every five years.
27.Before you roll anything out TEST TEST TEST
28.Use Source Control
29.Communicate, communicate, communicate
30.You can never have enough clarification and detail with project requirements

Here is the list of tips & insights compiled from StackOverFlow.


1. Never be afraid to say I don’t know.Manage expectations, learn to say “no”.But always give it a try before you say that.
2. Never stop learning.Accept your mistakes and take that just as a new learning opportunity
3. Ask for help sooner rather than later,know that you can’t do everything by yourself.Don’t take all the responsibility for a problem. Sometimes you can be furiously trying to solve a problem alone and carrying the problem on your back. Get other people involved, escalate, get other folks involved.
4. Learn to take backup
5. Assumption is the mother of all screw-ups. So never assume something which you are not sure of.
6. Estimates are always off by at least 50% either way.
7. First make it work, then make it better.
8. Always negotiate deadlines/deliverables.
9. Don’t hesitate to do overtime IF the situation requires it
10.Underpromise and over deliver
11.Find the balance between being realistic and being positive.
12.Be confident in your skills
13.Listern patiently to others opinion. Especially when you talk to a client.
14.Share your skills – Help others and the community with the knowledge you’ve got.
15.Make sure you get proper recognition and appraisal for your good work.
16.Manage your time effectively
17.Don’t give people what they ask for, give them what they need.
18.No matter where you are on the pecking order of a team or project, you CAN make a difference.
19.It’s more important to manage people’s perception of the problem than it is to fix it.
20.Never trust the data. Validate your inputs.
21.”It works on my machine” doesn’t cut it. It HAS to work for them, too.
22.Show your code to other people – and listen to their comments.& Look at other peoples code and talk to them about it.
23.If you can’t figure out a problem then take a break and come back to it in 10 or 20 minutes – makes finding a solution so much easier.
24.Realize that specifications are going to change.
25.Never implement new features unless you have a written request ( mail is just fine )
26.Be prepared to reinvent yourself every five years.
27.Before you roll anything out TEST TEST TEST
28.Use Source Control
29.Communicate, communicate, communicate
30.You can never have enough clarification and detail with project requirements

Sometimes I just can’t get anything done.

Sure, I come into the office, roam around, check my email every ten seconds, read the web and even do a few brainless tasks. But getting back into the flow of writing code just doesn’t happen.

These periods of unproductiveness usually last for a day or two. But there have been times in my career as a developer when I went for weeks at a time without being able to get anything done. I was not in flow. I was not in the zone. I was not anywhere.

Everybody has mood swings, for some people they are mild, for others, they can be more dysfunctional.

It makes me think of those researchers who say that basically people can’t control what they eat, so any attempt to diet is bound to be short term and they will always return back to their natural weight. Maybe as a software developer I really can’t control when I’m productive, and I just have to take the slow times with the fast times and hope that they average out to enough lines of code to make me employable.

What drives me crazy is that ever since my first job I’ve realized that as a developer, I usually average about two or three hours a day of productive coding. One fellow worker mentioned me that he too can work productively for 2 to 3 hours a day.

Sometimes I feel guilty when I see how hard everybody else seems to be working, & I get about two or three quality hours in a day. But its not the days when I “only” get two hours of work done that worry me. It’s the days when I can’t do anything.

I have thought about this a lot, as per my understanding the productivity greatly depends on the work environment like Google or Microsoft Office.

Many of my days go like this:
(1)get into office
(2)check email, read the web
(3)decide that today I will work productively
(4)lunch time comes I go out for lunch, at hotel I think that once I go back I will do work
(5)Come back from lunch, read news paper
(6)Check email, facebook, read the web
(7)Finally decides to start working and realize that its already 8:00
(8)leave office

This reminds of Newton’s law, An object at rest tends to remain at rest……
And over the years I have figured out what we have to do in such unproductive periods, the rule is simple, get started & stick to it………… once you get into the flow, its not too hard to keep moving as other part of Newton’s law mentions it, an object in motion tends to move until and unless an external force is applied………

What do you do in such unproductive situations?

There is a huge interest in Cloud computing these days. Last month i attended Google Developer Day, Google has already providing Cloud called Google App Engine, where developers can host applications developed in python.

Now it’s Microsoft’s turn, with their Azure Platform they are providing cloud services.

Let me know what you think about the latest trend like Cloud Computing of these big companies.

Intelligent Cloud

 public static String Reverse(String strParam)
{
if(strParam.Length==1)
{
return strParam;
}
else
{
return Reverse(strParam.Substring(1)) + strParam.Substring(0,1);
}
}

If you ask software engineers about how the compiler works? Most of them give you an alien look.

Here is how the compiler works :

— It is slowest sorting algorithm in use
— It is considered as Most In efficient Sorting Algorithm.

How it works?

The basic idea is to compare two neighboring objects, and to swap them if they are in the wrong order. This process is repeated until it completly sorts the list. This causes larger values to “bubble” to the end of the list while smaller values “sink” towards the begining of the list.

C# Code :

// integers array to hold values
private int[] a = new int[100];

// number of elements in array
private int x;

// Bubble Sort Algorithm
public void sortArray()
{
int i ;
int j ;
int temp ;

for( i = (x 1); i >= 0; i)
{
for( j = 1; j <= i; j++ )
{
if
( a[j-1] > a[j] )
{
temp = a[j-1] ;
a[j-1] = a[j] ;
a[j] = temp ;
}
}
}
}

When you receive command not recognized as internal or external command, when you type a command in windows.

Just right click on My computer then select properties from the menu, then Adanced Tab and in that click on Environment Veriables, then specify the path to your command prompt.

Can you work for 1 day without a mouse? Try it and see the horror on the users’ faces. Practice it and see the increase in productivity.

The quality of a good programmer is the ability to know how to beg borrow and steal the right code – AND when not to try and solve a problem from scratch.

Interview of two candidates
Q Write a class to put these items in a linked list.

Candidate 1 Wrote a nice linked list class and used it – failed
Candidate 2 Derived class from a library linked list class, and used sample code – Got job and went down to pub to celebrate!

As a Software Engineer, problem solving skills are 80% of software engineering. The syntax of programming and programming well is the difference between a good programmer and a great programmer.

I was passed over for a job because I couldn’t “Write a function to compute the moving average of a stock price.” Heck, I didn’t even know what a “moving average” was. But when I got home I sat down and 20 minutes later I had a nifty little recursive function that answered the question. Why couldn’t I do that in the interview? Because in the interview I didn’t have the resources I would normally have while on the job. A good Software Engineer knows how to use those resources to solve programming problems.

I think what should be tested is not the knowledge per say, but the capacity to pick stuff up, I got my current Job becuase I took an API I had never used before and figured out how to use it. I’m by no means a pro, but I have the capacity to learn by myself, some people can’t pick up new things unless they are spoon fed.

University is not an exercise in cramming your head full of knowledge it’s an exercise in learning how to learn quickly and efficiently.

When you know the basics you can teach yourself a new language in a few hours, and depending on the complexity learn a new API in an hour to day. Many grads I find dont have that capacity.

I remember at my first .NET course the teacher asking how many people never programmed before. Many hands were raised, and I felt bad for them for choosing a future profession without knowing what it actually was about. Then he asked how many people never touched a keyboard before. How shock was I to see at least 10 persons raise their hand, mostly women.

I think there are too many people out there who don’t know how to write code in their head..

But..

That doesn’t make them a bad coder or designer to be apt. Coding has become so abstract that most modern coders tend to be designers due to working with heavily gui based apps from Windows form coding to Web apps. So we could blame MS for doing this, but its not really their fault.

The days of the lone coder are gone, most if not all coders have no need to learn or retain any of the stuff they get taught in their college/uni and certainly its not a requirement in a job.

However I think coding should be about architecting a solution and that means working from the ground up. A good coder is someone who has knowledge of each area they are interacting with, not necessarily deep knowledge of a technical component but enough of an understanding to appreciate how their solution will fit into the wider picture.

Coding should be about elegance. It should be like designing a really well made web page that employs lush CSS and is a visual treat to look at. Code should be the same, well commented and fluid in its layout making the code appealing to read.

I have come across too many coders who simply code out of need, usually to meet out of proportion expectations resulting in badly formed code or a solution that has far too many shortcuts in place.

Each to their own though, every problem has a particular solution however I think what this article was touching on was the fact that the core foundation skills of a coder are not present in most interview cases and this is worrying but I think a growing trend.

When you have hand-holding applications like Visual Studio.NET there is no real need to retain information as you can for the most part, cut and paste your way to a solution. 😛

Somewhere i read it. They wrote that almost 199 out of 200 can not write programs.

What i think is we cannot judge a person simply taking interview for 30 minutes or 45 minutes.We can always learn to pass interview tests of any kind – that doesn’t mean We can program or not. These days Technological growth is very rapid which makes us to remember only the concept not the syntaxes. So we cannot expect every one to remember each and every thing.

We studied many concepts during our Engineering Day’s in College but many of the concepts we never used at all.For example, I wrote programs like generating Fibonacci series etc which I never used at all in my programming so far.

If someone were to ask me how to swap two variables w/o a temp variable I’d ask them to give me a good reason why.

Not being able to answer that particular question certainly doesn’t preclude someone from being a good programmer. That’d be like asking a C# programmer how to do modulo 16 using only a logical and. Why the hell would they need to know that, and how does that help you determine that they understand the ASP.Net framework, etc.?

What matters most is whether we have logical and analytical ability to understand the problem well.

The most obvious way to decide – for me – is to run through these tests (assigning some tasks to perform), emply the person you like the best and then look at the code they’ve produced after a week. Then you’ll know if they can do what you need.

Programmers are implementor’s.

Architects are conceptualist’s.

How to Interview a Programmer
by Bill Venners

Summary
Recognizing good programmers among job applicants is not easy. This article contains interview techniques, garnered from a recent summit on writing better code, that can help you can find the most qualified programmers for your project.


Seven Golden Rules

  • Explore an Area of Expertise
  • Have Them Critique Something
  • Ask Them to Solve a Problem
  • Look at Their Code
  • Find Out What Books They Read
  • Ask About a People Problem
  • Get to Know Them

In January, I attended a Writing Better Code summit in Portland, Oregon, organized by Scott Meyers and Bruce Eckel. At the three-day summit, 15 people gathered to discuss code quality and how they could improve it. Throughout this discussion, one theme was clear: good code is written by good programmers. Therefore, one great way to improve the code quality within an organization is to hire better programmers. The trouble is, recognizing a good programmer among a pool of job applicants is not easy.

Finding good programmers is hard because good programming is dependent on much more than just knowledge of programming language syntax. You need someone who, despite wearing striped pants with a polka dot shirt, has a good sense of taste in OO design. You need someone who is creative enough to find innovative solutions to problems, yet anal retentive enough to always line up their curly braces. You need someone who is humble enough to be open to suggestions for improvement, but arrogant enough to stand firm and provide leadership when they are the best person to provide it. How can you tell all this about a stranger by spending 30 minutes with them in a conference room?

The final morning of the Writing Better Code summit, Bruce Eckel announced he was “hijacking” the meeting. Bruce wanted each person at the table to share his or her interview techniques. He wanted to know how we recognize a good programmer in an interview. In this article, I highlight some interview techniques discussed that morning. If you have more ideas or would like to discuss any techniques presented here, please post a comment to the News & Ideas Forum Topic, How to Interview a Programmer.

Explore an Area of Expertise


Although various interview methods were tossed about that morning, a few fundamental techniques emerged from the discussion. For example, rather than simply look for expertise and experience in the exact area in which the candidate will work, you should look for general programming talent and ability. One way to explore and judge a candidate’s talents is to explore an area of their expertise:

Dave Thomas: Hire for talent. One of the biggest mistakes companies make is to recruit from a shopping list: I need a programmer with six years Java, three years Oracle, and two years EJBs. The world changes, so you need to hire folks who change with it. Look for people who know computing, not necessarily particular narrow niches. Not only will they adapt better in the future, they’re also more likely to be innovative in the present.

Chris Sells: To identify how good the candidates are technically, I let them choose an area in which they feel they have expertise. I need them to know something well, and I ask them about that. I ask them why. I want them to know why something in their area of expertise works the way it does. I’m not necessarily after an expert in the area I need. If they learned why in the past, I have confidence they’ll learn why in the future.

Have Them Critique Something


Another technique involves the importance of creating a dialog with the candidate. To get to know the candidate’s talents and personality, you can’t merely ask questions that have short factual answers. You have to find a way to engage a conversation. To stimulate dialog, you can ask the candidate to critique some technology:

Josh Bloch: I ask candidates to critique a system or platform that we both have in common, preferably something they will use on the job. For example, I might ask, “What parts of Java don’t you like and why?”

Pete McBreen: I give candidates samples of our current code and ask them to explain and critique it. This gives me a sense of their skills, but also lets them know what they can expect.

Ask Them to Solve a Problem


Another way to foster an open-ended dialog is to ask the candidate to perform a task: to solve a problem or create a design. Although everyone at the meeting seemed to agree that this was important and useful technique, it also generated a lot of concern. People felt that asking the candidate to solve puzzles and problems needed to be done with care:

Josh Bloch: I like to ask a candidate to solve a small-scale design problem, finger exercises, to see how they think and what their process is: “How would you write a function that tells me if its argument is a power of 2?” I’m not looking for the optimal bit-twiddling solution ((n & -n) == n). I’m looking to see if they get the method signature right, if they think about boundary cases, if their algorithm is reasonable and they can explain its workings, and if they can improve on their first attempt.

Bruce Eckel: I ask candidates to create an object model of a chicken. This eliminates any problems with uncertainties about the problem domain, because everyone knows what a chicken is. I think it also jars people away from the technical details of a computer. It tests to see if they are capable of thinking about the big picture.

Scott Meyers: I hate anything that asks me to design on the spot. That’s asking to demonstrate a skill rarely required on the job in a high-stress environment, where it is difficult for a candidate to accurately prove their abilities. I think it’s fundamentally an unfair thing to request of a candidate.

Matt Gerrans: I don’t like when I’m asked to write a program that does X on a piece of paper. Don’t ask the candidate to write a program on paper. That is a waste of time and sweat. People don’t write software on paper, they do it with computers using auto-completion, macros, indexed API documentation, and context-sensitive help. They think about it, refactor it, and even rewrite it. If you want to see a person’s work, ask them to write some small module or implement some interface before the interview and bring the code on a notebook PC or on hard copy. Then you can review it and discuss the design, coding style, and decisions that went into it. This will give you a much more realistic and useful assessment of a person’s work and style.

Kevlin Henney: I like design dialog questions that don’t have a single fixed answer. That way they have to ask me questions, and this sparks a discussion. It’s good to have a whiteboard available in the room. A dialog lets the interviewer see how the interviewee works, whereas a question of fact is just that: it is great for TV quiz shows, but doesn’t tell you how someone will work and approach things over time. A puzzle question requires knowing a trick, which is in essence something that is either known or unknown. I dislike puzzle questions, because they don’t require dialog.

Josh Bloch: What constitutes a reasonable question depends a lot on the candidate’s experience and maturity.

Dave Thomas: I look for people with curiosity. Present problems, not puzzles.

Look at Their Code


Josh Bloch suggested one technique we all seemed to like: Have the candidate bring a code portfolio to the interview. Look at the candidate’s code and talk to them about it. Although we were concerned that some candidates may not have code they could legally bring to the interview, we figured most candidates could probably come up with something. It can’t hurt at least to ask a candidate to bring to the interview a sample of code they had written in the past.

Josh Bloch: I want to see their code. You get to see what they pick. You learn what they value. You learn how they communicate.

Find Out What Books They Read


Several people indicated that they ask candidates about the programming books they read to see if a programmer is self-motivated or concerned about improving their own programming skills:

Matt Gerrans: I ask candidates, “What books have you read about programming?” If the book is beyond syntax, that’s important.

Randy Stafford: I find out what books they read because it’s important to me that they educate themselves of their own volition.

Ask About a People Problem


As important as technical ability, or perhaps more important, is personality. How well would the candidate fit the team? How well would they fit the work environment? People used various techniques to judge personality:

Randy Stafford: Good citizenship is probably more important than technical prowess, because if you have people with the right kind of attitude and demeanor, you can help them gain the technical knowledge and software development habits. But if you have people who lack humility and maturity, it can be extremely difficult to get them to cooperate in reaching a goal, no matter how bright they are or what they’ve accomplished in the past.

Chris Sells: I ask candidates, “Tell me about a problem you had with a boss or teammate. Tell me how you’ve dealt with a problem with a boss.”

Jack Ganssle: I check references. Now, I know these people are the candidate’s five best friends, and will not say anything negative. But I ask those references for names of people who know the candidate, and go to these others for insight. This way I spread the net beyond anything the candidate ever imagined.

Kevlin Henney: I try to imagine if I would go to a pub and talk non-tech with them—not if I like them, but whether I could get along with them. Are they pubbable? Could I talk to them in a non-office situation?

Dawn McGee: The most likable person is often not the best person.

Dave Thomas: I think every team of a certain size needs a professional pain in the ass, because teams get complacent, fixed in their ways. They need nudging out of their comfort zone once in a while, so they can look at problems from a different perspective. There are two kinds of pains in the ass: the obnoxious boor—to be avoided on all teams—and the person who never learned that grownups shouldn’t ask “Why?” all the time. The latter is a treasure.

Get to Know Them


Perhaps the prominent theme of our discussion was that you need to try to get to know the candidate as best you can. Talk to the candidate in the interview. Try to get a feel for them. If possible, bring them in on a trial basis or for a probationary period. That would give you more time to get to know the candidate, and give the candidate more time to get to know you:

Chuck Allison: I talk to them. I get a feel for them. I always ask about what they’ve done. I have found that by discovering what a person is excited about technically, you can learn a lot of important things about them. In the past I’ve asked people to describe a project that was especially interesting to them, or that was challenging and successful. On occasion I’ve asked what they’ve done that they’re the most proud of. This usually reveals the depth of one’s understanding and mastery. It also gets them to turn on the fire hose verbally, and you can sit back and get most of the answers you need.

Randy Stafford: I look at past projects listed on their resume, and ask them to talk about those projects—how was the team organized, what the technologies and architectures were used, was the software successful in production, etc. In their answers I’m listening for what lessons they learned from those experiences, and whether those lessons match with lessons I’ve learned from my experiences and from professional literature. I get a glimpse into how they perceive themselves in relation to the world around them. Some come off as arrogant, some ignorant, some helpless. Others sound humble, intelligent, and motivated. I often ask them what software development literature they read. Continuous education is very important to me.

Angelika Langer: In Germany, hiring is like marrying someone. It’s “until death do us part”—a marriage without the backdoor of a divorce, because you can’t fire employees. The only chance for firing someone is during a three- to six-month probationary period, or when the company goes out of business.

The major filtering is done before the interview, based on the curriculum vitae (CV) and submitted papers, such as evaluations from former employers. (In Germany, employers must provide every employee with a written evaluation when they leave the company.) The interview itself is usually brief. The main tool in filtering is scrutinizing the CV and papers; 98 percent of all applicants are disqualified in this phase. The interview should confirm the impression you gain from the applicant’s papers and allows you to sense their personality. The lucky winner then goes on a probationary period.

Probation definitely does not replace the filtering; it just keeps a last exit open until you really must commit.

Andy Hunt: We’ve hired people who interviewed well, but they were terrible at the job. If possible, hire them in for a trial period.

Dawn McGee: You could also bring candidates in for half a day, and have them do what they would be doing on the job.

Conclusion


To sum up the overlying themes from our hour-long discussion in Portland: You should look for talent and fit more than specific skill sets. Ask open-ended questions to initiate revealing dialog. Ask candidates to critique something. Ask them to design something. Investigate their past experience. Review their code. And through conversation and, if possible, a trial period, you should try to become familiar with the candidate’s technical abilities, talents, and personality.

How Do You Interview a Programmer?

Do you have an opinion on the techniques mentioned in this article? Do you have a tool or technique you use to find good programmers? Please share your ideas in the News & Ideas Forum Topic: How to Interview a Programmer.

Source :http://interviewinfo.net/blogs/for_employers/archive/2006/11/14/224.aspx

My notes:
Hire the natural self-taught talent! Having a CompSci college degree only means that they wasted 4 years (or more) of their lives. Whereas the self-taught programmers were busy writing software during those 4 years. And, why not test the interviewees on something more pragmatic, like create a business object that handles the CRUDs for s simple 3 or 4 property entity (or test them on something else that would be common for your company to write).


Blog Stats

  • 71,043 hits
August 2020
M T W T F S S
 12
3456789
10111213141516
17181920212223
24252627282930
31  

Top Clicks

  • None