Developer Career Tips #0008
How to get that elusive first programming job with no experience
I'm forever being asked by my Visual Basic students how to obtain a Visual Basic programming position in today's job market, when you have no 'paid' Visual Basic experience.
I still insist that there are three sure-fire ways to obtain a Visual Basic programming position (at least a junior level position).
The first is to write a fantastic application based on something you know, and showcase that program at your interview. I had a student in a class a few semesters ago who showed me a Visual Basic program he wrote to keep track of the golf handicaps in his weekend golf league. The program was fabulous, and not only did he land a job with it, he's made quite a bit of money marketing it to other golf leagues in our area.
A second way is to volunteer your programming services---choose a charitable or non-profit organization who may be interested in your free services in exchange for the experience it can bring. Several of my students have written programs for their churches---another wrote a program for a local soup kitchen. You'd be amazed at how demanding a 'real' client can be, even one who ultimately isn't paying cash for the product. But the experience is unbeatable--and it's perfectly legitimate to include a non-paid job like this on your resume---even better if the customer is well pleased and will provide a great reference to a prospective employer.
The final way is to take and pass one of the Microsoft Visual Basic Certification exams---start with the VB6 Desktop Exam. Those of you who have been following my tips know that I'm a big believer in using the exams as a way to get your foot in the door. Hiring managers continue to tell me that passing the exam is a great way to get noticed and interviewed---even if you have no experience.
Monday, July 31, 2000
Monday, July 24, 2000
Programming Tips & Tricks #0007---Global Keyboard Handler in Visual Basic
Tips & Tricks #0007
Global Keyboard Handler in Visual Basic
One of the questions that I am frequently asked is how to implement Keystroke validation in a Visual Basic Textbox. The answer is that you can insert code into the KeyPress Event Procedure of a Textbox--and implement Keystroke validation that way. For instance, this code will ensure that only numbers are entered into a Textbox---it also permits the user to press enter a BackSpace key in case they make a mistake.
Private Sub Text1_KeyPress(KeyAscii As Integer)
If KeyAscii = 8 Then Exit Sub '8 is Backspace
If KeyAscii <> 57 Then 'Range of numeric values
KeyAscii = 0
End If
End Sub
Entering code into the KeyPress Event Procedure of a Textbox is fine for one or two Textboxes---but If you have a large number of Textboxes on your form, this is not an enviable task. In that case, you have two alternatives:
First, you can make each Textbox a member of a Textbox Control Array, in which case each Textbox 'shares' the same KeyPress Event Procedure. Sharing code like that is the chief benefit of a Control Array.
The second alternative is to set up a Form Level or Global Keyboard Handler by telling Visual Basic that you want the Form's KeyPress Event Procedure to be triggered BEFORE the individual Textbox KeyPress Event Procedures.
You do this by setting the KeyPreview Property of the Form to True. This will cause the KeyPress Event Procedure of the Form to be triggered whenever a keystroke is made for any of the Textboxes on the form. What that means is that you can take the code you write for each Textbox KeyPress Event on your form--and place it in just one place---the KeyPress Event Procedure of the Form.
Global Keyboard Handler in Visual Basic
One of the questions that I am frequently asked is how to implement Keystroke validation in a Visual Basic Textbox. The answer is that you can insert code into the KeyPress Event Procedure of a Textbox--and implement Keystroke validation that way. For instance, this code will ensure that only numbers are entered into a Textbox---it also permits the user to press enter a BackSpace key in case they make a mistake.
Private Sub Text1_KeyPress(KeyAscii As Integer)
If KeyAscii = 8 Then Exit Sub '8 is Backspace
If KeyAscii <> 57 Then 'Range of numeric values
KeyAscii = 0
End If
End Sub
Entering code into the KeyPress Event Procedure of a Textbox is fine for one or two Textboxes---but If you have a large number of Textboxes on your form, this is not an enviable task. In that case, you have two alternatives:
First, you can make each Textbox a member of a Textbox Control Array, in which case each Textbox 'shares' the same KeyPress Event Procedure. Sharing code like that is the chief benefit of a Control Array.
The second alternative is to set up a Form Level or Global Keyboard Handler by telling Visual Basic that you want the Form's KeyPress Event Procedure to be triggered BEFORE the individual Textbox KeyPress Event Procedures.
You do this by setting the KeyPreview Property of the Form to True. This will cause the KeyPress Event Procedure of the Form to be triggered whenever a keystroke is made for any of the Textboxes on the form. What that means is that you can take the code you write for each Textbox KeyPress Event on your form--and place it in just one place---the KeyPress Event Procedure of the Form.
Monday, July 17, 2000
Developer Career Tip #0007---Interview the Interviewer
Developer Career Tips #0007
Interview the Interviewer
In my last article, I talked about the importance of asking a question (or more) during a job interview to let the interviewer know that you are capable of more than just answering questions and that you have a genuine interest in the company.
Don't allow the interview to become a one-way piece of communication where the interviewer learns everything necessary to make a decision as to whether or not you are what the company needs and wants, but you learn nothing about the company to make the same decision. Too many job candidates find themselves interviewing for a programming position, receiving an offer and then finding themselves in a position they don't like.
How can you avoid this?
Be prepared to get the answers to the questions you'll have the first day or first week of your new job---you don't want to wait until then to find out.
I'm not talking about fundamental questions such as salary, work hours, vacation time and other benefits---these are likely to be part of a standard package provided to you prior to the interview.
I'm talking about questions such as:
What type of work will I be doing?
Will I be programming?
If so, will it be new development, or maintenance of existing code?
If code maintenance, is the original author still with the company?
What language or languages will I be writing?
Will I be working as part of a team?
If so, what are the skill levels of my team members?
How many years with the company do my team members have?
Who will be my supervisor?
How many years with the company does he or she have?
While these are questions to which you can easily obtain answers on your first day on the job, by then it may be too late--particularly if you've left a previous position to obtain that long awaited developer's job, only to find out you'll be manning a Help Desk for the next 6 months until the company signs a big contract.
Of course, you may not be in a position to be picky---if you are a candidate just trying to get your foot in the door, any job offer may be a good one.
Next time: An innovative approach to getting your foot in the door
Interview the Interviewer
In my last article, I talked about the importance of asking a question (or more) during a job interview to let the interviewer know that you are capable of more than just answering questions and that you have a genuine interest in the company.
Don't allow the interview to become a one-way piece of communication where the interviewer learns everything necessary to make a decision as to whether or not you are what the company needs and wants, but you learn nothing about the company to make the same decision. Too many job candidates find themselves interviewing for a programming position, receiving an offer and then finding themselves in a position they don't like.
How can you avoid this?
Be prepared to get the answers to the questions you'll have the first day or first week of your new job---you don't want to wait until then to find out.
I'm not talking about fundamental questions such as salary, work hours, vacation time and other benefits---these are likely to be part of a standard package provided to you prior to the interview.
I'm talking about questions such as:
What type of work will I be doing?
Will I be programming?
If so, will it be new development, or maintenance of existing code?
If code maintenance, is the original author still with the company?
What language or languages will I be writing?
Will I be working as part of a team?
If so, what are the skill levels of my team members?
How many years with the company do my team members have?
Who will be my supervisor?
How many years with the company does he or she have?
While these are questions to which you can easily obtain answers on your first day on the job, by then it may be too late--particularly if you've left a previous position to obtain that long awaited developer's job, only to find out you'll be manning a Help Desk for the next 6 months until the company signs a big contract.
Of course, you may not be in a position to be picky---if you are a candidate just trying to get your foot in the door, any job offer may be a good one.
Next time: An innovative approach to getting your foot in the door
Monday, July 10, 2000
Programming Tips & Tricks #0006---Named Visual Basic Arguments
Tips & Tricks #0006
Named Visual Basic Arguments
One of the themes I emphasize in my computer classes over and over again is the importance of writing code that is readable---that is, code that other programmers and developers will be able to understand, and if necessary, easily modify in the future. Some obvious ways to write readable code include the use of program comments in your code---no matter what the language you are using to develop your program, all major languages provide for comments. Something else that can make your Visual Basic more readable is the user of Named Arguments.
Let me illustrate by executing the Visual Basic MsgBox Function to display a Windows Message Box. The Visual Basic MsgBox function has one required argument (Prompt), and four optional arguments (Buttons, Title, HelpFile and Context).
MsgBox “I love Visual Basic”
By default, this code will display a Message Box with a single command button captioned OK, with the text “I love Visual Basic”, and the Visual Basic Project name displayed in the Title Bar of the Message Box.
Suppose I’m not happy with the default Title in the Message Box, and I decide I want to customize it. Doing this is easy—all I need to do is supply the Title argument to the MsgBox function. However, since Title is the third argument, I either need to supply the second argument---Buttons, which is by default presumed to be the value vbOKOnly---or provide a ‘comma placeholder’, like this.
MsgBox “I love Visual Basic”,, “SearchVB.Com”
Notice the two commas back-to-back, with no value in-between. This is the ‘comma placeholder’ and is how we tell VB that although we have a value for the third argument, we have no explicit value for the second argument.
When we execute this code, we’ll see a Message Box that reads “I love Visual Basic”, and that has “SearchVB.Com” for its Title Bar.
Named Arguments can make passing optional arguments easier—and make your code infinitely easier to read and modify. For instance, the code we wrote above can be re-written to this using Named Arguments.
MsgBox Prompt:="I love Visual Basic", Title:="SearchVB.Com"
With Named Arguments, we specify the name of the argument, followed by a colon and equals sign (:=), then the value for the argument. By using Named Arguments, we don’t need to provide a ‘comma placeholder’ for the second argument Buttons. Since we are naming the argument, VB knows that ‘SearchVB.Com’ is the value for the Optional Argument ‘Title’. And since we name the arguments, being able to read and understand the code in the future is much easier.
Named Visual Basic Arguments
One of the themes I emphasize in my computer classes over and over again is the importance of writing code that is readable---that is, code that other programmers and developers will be able to understand, and if necessary, easily modify in the future. Some obvious ways to write readable code include the use of program comments in your code---no matter what the language you are using to develop your program, all major languages provide for comments. Something else that can make your Visual Basic more readable is the user of Named Arguments.
Let me illustrate by executing the Visual Basic MsgBox Function to display a Windows Message Box. The Visual Basic MsgBox function has one required argument (Prompt), and four optional arguments (Buttons, Title, HelpFile and Context).
MsgBox “I love Visual Basic”
By default, this code will display a Message Box with a single command button captioned OK, with the text “I love Visual Basic”, and the Visual Basic Project name displayed in the Title Bar of the Message Box.
Suppose I’m not happy with the default Title in the Message Box, and I decide I want to customize it. Doing this is easy—all I need to do is supply the Title argument to the MsgBox function. However, since Title is the third argument, I either need to supply the second argument---Buttons, which is by default presumed to be the value vbOKOnly---or provide a ‘comma placeholder’, like this.
MsgBox “I love Visual Basic”,, “SearchVB.Com”
Notice the two commas back-to-back, with no value in-between. This is the ‘comma placeholder’ and is how we tell VB that although we have a value for the third argument, we have no explicit value for the second argument.
When we execute this code, we’ll see a Message Box that reads “I love Visual Basic”, and that has “SearchVB.Com” for its Title Bar.
Named Arguments can make passing optional arguments easier—and make your code infinitely easier to read and modify. For instance, the code we wrote above can be re-written to this using Named Arguments.
MsgBox Prompt:="I love Visual Basic", Title:="SearchVB.Com"
With Named Arguments, we specify the name of the argument, followed by a colon and equals sign (:=), then the value for the argument. By using Named Arguments, we don’t need to provide a ‘comma placeholder’ for the second argument Buttons. Since we are naming the argument, VB knows that ‘SearchVB.Com’ is the value for the Optional Argument ‘Title’. And since we name the arguments, being able to read and understand the code in the future is much easier.
Monday, July 3, 2000
Developer Career Tip #0006---Interview Tip #1---Be sure to ask a question!
Developer Career Tips #0006
Interview Tip #1---Be sure to ask a question!
I'm frequently asked, by my readers and students strategies for answering questions during a job interview. There's no doubt that your ability to 'show your stuff' during a job interview is crucial to landing a programming job.
I'll be covering strategies for answering questions in future articles, but today I want to discuss what I think plagues more job candidates than any other single issue--failing to ask a question during the interview.
Not only do I teach and write books, I also own my own consulting firm, and although I do most of my own work, on occasion I do hire someone to help out during busy periods---usually from a pool of candidate students provided to me by my University's Co-Operative Education program.
These students are highly recommended by the Chairman of the Computer Science Department, extremely motivated, and choosing among two or three candidates can be very difficult.
So how do I make my choice?
That's easy---I pick the candidate who asks me the best questions!
Asks questions? Isn't it the interviewer who should be asking the questions, not the job candidate?
Many job seekers are of the mistaken impression that the role of the candidate is to answer questions during the interview. From the interviewer's perspective, however, you can't imagine the poor image that is conveyed of a job candidate who sits through the interview, and politely (and quite skillfully) answers each and every question, and then when asked if they have any questions, simply say 'no' as if they are anxious to leave!
Taking the time to ask a question or two during the interview shows the interviewer that you are enthusiastic and genuinely interested in the position and the company, and that you can not only answer questions posed of you but that you can initiate and carry on a conversation (a skill that is crucial when talking with end users). In short, taking the time to ask a question or two can land you the job!
Another benefit is that it gives you the chance to seek clarification on the job itself, the types of duties that will be required of you, and to learn more about the company and the people with whom you will work. These are questions to which you want answers before you show up for work the first day.
Next time: Questions to ask before saying "Yes, I'll take the job"
Interview Tip #1---Be sure to ask a question!
I'm frequently asked, by my readers and students strategies for answering questions during a job interview. There's no doubt that your ability to 'show your stuff' during a job interview is crucial to landing a programming job.
I'll be covering strategies for answering questions in future articles, but today I want to discuss what I think plagues more job candidates than any other single issue--failing to ask a question during the interview.
Not only do I teach and write books, I also own my own consulting firm, and although I do most of my own work, on occasion I do hire someone to help out during busy periods---usually from a pool of candidate students provided to me by my University's Co-Operative Education program.
These students are highly recommended by the Chairman of the Computer Science Department, extremely motivated, and choosing among two or three candidates can be very difficult.
So how do I make my choice?
That's easy---I pick the candidate who asks me the best questions!
Asks questions? Isn't it the interviewer who should be asking the questions, not the job candidate?
Many job seekers are of the mistaken impression that the role of the candidate is to answer questions during the interview. From the interviewer's perspective, however, you can't imagine the poor image that is conveyed of a job candidate who sits through the interview, and politely (and quite skillfully) answers each and every question, and then when asked if they have any questions, simply say 'no' as if they are anxious to leave!
Taking the time to ask a question or two during the interview shows the interviewer that you are enthusiastic and genuinely interested in the position and the company, and that you can not only answer questions posed of you but that you can initiate and carry on a conversation (a skill that is crucial when talking with end users). In short, taking the time to ask a question or two can land you the job!
Another benefit is that it gives you the chance to seek clarification on the job itself, the types of duties that will be required of you, and to learn more about the company and the people with whom you will work. These are questions to which you want answers before you show up for work the first day.
Next time: Questions to ask before saying "Yes, I'll take the job"
Monday, June 26, 2000
Programming Tips & Tricks #0005---With...EndWith in VB
Tips & Tricks #0005
In my consulting practice, I frequently see examples of Visual Basic code that could be improved upon, either from a readability point of view or from an efficiency point of view. Today I'd like to discuss a relatively new Visual Basic construct that can improve both the readability and efficiency of your code---and save you quite a few keystrokes in the process. That construct is the With…End With statement.
The With…End With statement allows you to 'bundle' Property and Method calls to a single object within the With…End With block. For instance, here's some code that sets the properties of a Command Button, and then executes its Move Method.
Private Sub Form_Load()
Command1.Caption = "OK"
Command1.Visible = True
Command1.Top = 200
Command1.Left = 5000
Command1.Enabled = True
Command1.Move 1000,1000
End Sub
By using the With…End With statement, we can eliminate quite a few programmer keystrokes, and make the code a bit more readable in the process---like this…
Private Sub Form_Load()
With Command1
.Caption = "OK"
.Visible = True
.Top = 200
.Left = 5000
.Enabled = True
.Move 1000,1000
End With
End Sub
Not only have we reduced the number of keystrokes in the procedure, but using the With…End With construct produces more efficient code.
Each reference to an object's property or method requires a Registry 'look up' to execute the code statement---by using the With…End With statement, VB is able to 'pool' this lookup into a single Input Output operation---thereby making your program run faster.
The bottom line---whenever you find yourself coding multiple operations against an Object, use the With…End With statement.
In my consulting practice, I frequently see examples of Visual Basic code that could be improved upon, either from a readability point of view or from an efficiency point of view. Today I'd like to discuss a relatively new Visual Basic construct that can improve both the readability and efficiency of your code---and save you quite a few keystrokes in the process. That construct is the With…End With statement.
The With…End With statement allows you to 'bundle' Property and Method calls to a single object within the With…End With block. For instance, here's some code that sets the properties of a Command Button, and then executes its Move Method.
Private Sub Form_Load()
Command1.Caption = "OK"
Command1.Visible = True
Command1.Top = 200
Command1.Left = 5000
Command1.Enabled = True
Command1.Move 1000,1000
End Sub
By using the With…End With statement, we can eliminate quite a few programmer keystrokes, and make the code a bit more readable in the process---like this…
Private Sub Form_Load()
With Command1
.Caption = "OK"
.Visible = True
.Top = 200
.Left = 5000
.Enabled = True
.Move 1000,1000
End With
End Sub
Not only have we reduced the number of keystrokes in the procedure, but using the With…End With construct produces more efficient code.
Each reference to an object's property or method requires a Registry 'look up' to execute the code statement---by using the With…End With statement, VB is able to 'pool' this lookup into a single Input Output operation---thereby making your program run faster.
The bottom line---whenever you find yourself coding multiple operations against an Object, use the With…End With statement.
Monday, June 19, 2000
Developer Career Tip #0005---Learning Visual Basic---Part 3
Developer Career Tip #0005
Learning Visual Basic---Part 3
In my last two articles, I dealt with ways to learn a new programming language, including taking official Microsoft Curriculum courses at a Microsoft Certified Technical Education Center (CTEC), long term training at a computer programming school or institute, or enrolling in a course at a local colleges or university. All of these options have one thing in common: you need to be present at a predetermined time and place for a specific duration in a classroom led by an instructor. In today's article, I want to discuss an interesting alternative to classroom based training---web based learning.
I've taught programming for 20 years, and up until three years ago, all of it had been via the traditional route of instructor led classroom training. When I was initially approached to teach a web based programming course in Visual Basic (I teach for SmartPlanet and ElementK), I must confess I had my doubts, but within two weeks of beginning the course, I was amazed that not only could web based learning be just as good as traditional classroom based training, but in many ways it was far superior.
From a student's perspective, web based training can solve a myriad of logistical problems. Most web based training is message board based---which means that there's no formal meeting time. Students log in, obtain the week's assignment (usually a reading assignment), and then use the message board to ask questions, and check back later for answers.
For students whose work or personal commitments prevent them from traveling to formal classroom training, web based training permits them to sign into the 'classroom' whenever their schedules permit. Also, many web based programs are self paced, which means you can speed up or slow down the pace of your learning as your schedule demands. And for some students, perhaps the greatest benefit of web based training is that it's typically a fraction of the cost of formal classroom training.
From an instructor's point of view, I was amazed how web based training solved some of the problems I see in my traditional classes. For instance, since there is no formal lecture mode via the Internet, a higher percentage of students actually read the assigned material, since they can't rely on picking up the material in a lecture period. Secondly, since questions and answers are posted publicly on the message board, just about everybody in the class obtains the benefit of the questions that are posed and the answers that I give. Unfortunately, in a traditional classroom setting, students do not always pay attention to the questions others pose, nor listen to the answers.
Learning Visual Basic---Part 3
In my last two articles, I dealt with ways to learn a new programming language, including taking official Microsoft Curriculum courses at a Microsoft Certified Technical Education Center (CTEC), long term training at a computer programming school or institute, or enrolling in a course at a local colleges or university. All of these options have one thing in common: you need to be present at a predetermined time and place for a specific duration in a classroom led by an instructor. In today's article, I want to discuss an interesting alternative to classroom based training---web based learning.
I've taught programming for 20 years, and up until three years ago, all of it had been via the traditional route of instructor led classroom training. When I was initially approached to teach a web based programming course in Visual Basic (I teach for SmartPlanet and ElementK), I must confess I had my doubts, but within two weeks of beginning the course, I was amazed that not only could web based learning be just as good as traditional classroom based training, but in many ways it was far superior.
From a student's perspective, web based training can solve a myriad of logistical problems. Most web based training is message board based---which means that there's no formal meeting time. Students log in, obtain the week's assignment (usually a reading assignment), and then use the message board to ask questions, and check back later for answers.
For students whose work or personal commitments prevent them from traveling to formal classroom training, web based training permits them to sign into the 'classroom' whenever their schedules permit. Also, many web based programs are self paced, which means you can speed up or slow down the pace of your learning as your schedule demands. And for some students, perhaps the greatest benefit of web based training is that it's typically a fraction of the cost of formal classroom training.
From an instructor's point of view, I was amazed how web based training solved some of the problems I see in my traditional classes. For instance, since there is no formal lecture mode via the Internet, a higher percentage of students actually read the assigned material, since they can't rely on picking up the material in a lecture period. Secondly, since questions and answers are posted publicly on the message board, just about everybody in the class obtains the benefit of the questions that are posed and the answers that I give. Unfortunately, in a traditional classroom setting, students do not always pay attention to the questions others pose, nor listen to the answers.
Subscribe to:
Posts (Atom)
