Well hello people I am going for my first interview to be a VB programmer tomorrow and I would like to get some professional opinion on my sample project that I will be presenting to the interviewer, it is basically something that I have put together to show my skills in VB/ Access programming, so if you will have a look and tell me if you would hire based on my work, and if not please give me some feedback on what I can do better. Any input is much appreciated. This sample Uses DAO and was written in VB5.
As far as presentation of code and keeping of standards you did very well. My one question if Iwas employing you , would be do you know ADO or would you be willing to learn it? Skills in ADO would look better to a knowledgable interviewer. And remember, it isnt always WHAT you know, its what you have the ability to know!
Definitely willing to learn ADO, I'm just stuck with VB5 at the moment. Are the differences that much where it will take an extreme amount of studying to learn or is the switch relatively painless?
just 2 points:
Use strSQL rather than sSQL, as it will just show a bit more knowledge, and give the impression you've been doing this for a longer time - str is the 3 letter abreviation for string, which is the proper way of coding.
There's a couple of other parts like the plist where you coul have written in the 3 letter abreviation too (like lst short for listbox).
Secondly, keep code relatively close together, we all have spaces in our coding, but if the code is of the same tyoe (i.e. all in a with statement, then keep all this together, a bit like sentences & paragraphs -
Code:
With pList
.Clear
.AddItem "Breads"
.AddItem "Dairy"
.AddItem "Dry Goods"
.AddItem "Fruits"
.AddItem "Meats"
.AddItem "Non-Food"
.AddItem "Vegetables"
End With
could be better as:
Code:
With pList
.Clear
.AddItem "Breads"
.AddItem "Dairy"
.AddItem "Dry Goods"
.AddItem "Fruits"
.AddItem "Meats"
.AddItem "Non-Food"
.AddItem "Vegetables"
End With
Andytdb
Wassup/Ze Germans/Do You know what nemisis means
Its not really any harder than DAO. I mean it is a bit diferent, but if you can do DAO, you can do ADO. i think the only major difference is the settting up of a connection string that tells teh engine what type of database it is, the location of the database file, and any login stuff. This isnt reallt accurate but it wold look something like this
dim rs as ADODB.REcordset
Conn = "Driver=Access;Database="c:\mydb.mdb";userid='me';pass='sa'"
SQL = "Select * from mytable"
Set RS = New ADODB.Recordset
rs.open sql,conn
And thats sort of how you would do it. Off the top of my head so this isnt quite correct, but it is enough to give you an idea.
After that it is the same
rs!fieldname = "something"
rs.addnew
rs.udate
etc.
Sorry I should have added my naming conventions in the file here it is....
Code:
'~~~~~Variable Naming Conventions~~~~~
'~Global Variables = VariableName; i.e. Public PlayerName as String
'~Global Constants = CONSTANT_NAME; i.e. Public Const PLAYER_NAME as String = "Teddy"
'~Module Level Variables = LCase(Left(VariableType, 3)) + VariableName; i.e. Private strPlayerName as String
'~Module Level Constants = CONSTANTNAME; i.e. Private Const PLAYERNAME as String = "Teddy"
'~Function Level Variables = LCase(Left(VariableType, 1)) + VariableName; i.e. Dim sPlayerName as String
'~Function Parameters = "p" + VariableName; i.e. Private Function SomeFunc(pPlayerName as String)
One major tip especially important for IT jobs. If they ask you a question on how to do something, think about for a few seconds before you answer, and if you just flat out dont know, DO NOT try to bullshit your way through it with some bs answer. They will probably be able to catch it and it will just make you look the fool to them. Just honestly say you have no experince with that. But let them know that you do have the ability to learn it. Remember that the computer industry is always changing and its look better if they think you can learn new stuff to keep up rather than having a bunch of old outdated knowledge.
And if you dont get it, just keep learning new stuff and looking else where.
I've always kind of held that attitude in the 3 years I've been learning to program is that you can't know everything but with a couple of line's of code and some patience you can definitely learn it and to be honest I really don't expect to get the job because it is my first interview of this caliber but I do think it will definitely help me prepare for the next one.
Good Job YoungBuck, after I went throught and looked at your code, I could tell you had a good amount of knowledge with SQL. The only thing I would suggest would be to sharpen up the GUI for the employer. A professional looking user interface is always a plus. Good Luck Bud
Well... I can't give you much advice, 'co I, myself am only 13 years old, but I can tell you this:
Make the code understandable, use spces how much you want, but don't make it annoy you.
Another thing is to use the ' thingy whenever possible, it just makes the code understandable and better.
Also try to optimize your code with the With statement, the For loop etc.
A very important thing is if you have 2 or more events that do the same, store the code in a Function and Call it whenever needed. Then, when you have to change something, just go to the smae function and that would really make a difference in your app.
I have not looked at your code, but if you have been able to complete a program and have some basic standards (as Jop said, whether you abreviate strings with s or str is not that important....what is important is that you are consistent, don't name one string sSQL and the other strName).
I see you are in N.C., so you are definitely in a very hot part of the US for IT jobs. When I was looking for a new job last year, I had a lot of inquiries from N.C., S.C and VA (I live in Ohio).
It should not be too difficult to get hired if you demonstrate a basic technical knowledge, an ability and willingness to learn, and have basic people skills.
I have a good friend who is in the recruiting field and she told me the biggest obstacle most engineers have to getting hired is that they act like typical engineers (hate to admit they don't know something so they try to BS their way through the interview, or they are just not friendly enough or excited about teamwork)
If you know what kind of programs you will be working on, try to find some sample code on the web(vbaccelerator.com is excellent) to try to anticipate what you will be asked about. Most inteviews are rudimentary questions just to see if you have basic knowledge (can you declare public variables at the module level, why would you declare a variable as private in the declarations field rather than public, why would you use Do...Loop Until Condition rather than Do Until Condition...Loop, etc), but also be prepared for in-depth testing. I was flown into Richmond VA last year for a day and had 3 hours of testing (technical and psych) followed by the personal interview, it was quite exhausting.
Also, using some of the interview practice scenarios available on Monster.com and Dice.com is a good idea.
Just use a good mix of confidence, honesty, friendliness and controlled excitement. Use phrases like "I enjoy learning, I learn quickly, I thrive in a challenging atmosphere, and if you want the job, make sure you tell the interviewer that you want the job. I usually close my interviews when I do want the job by saying something like "I really want this job, do you see any obstacles that concern you about hiring me?" If they state any concerns, try to address them calmly and focus on positives rather than negatives...The most common one you may get is "You don't have any professional programming experience." You can answer that with something like "What I do have is technical knowledge, a willingness to learn and the ability to take intiative to achieve my goals."
Okay, I'm rambling. I just know of too many people who blow interviews because they weren't prepared and I think that is a tragedy.
Excellent advice bubba and keeping myself calm and collected is something I definitely will have to put some effort into (I'm a bit of a nervous and excitable guy) so I will definitely take your advice. Unfortunately as far as location goes I am just outside the area where I need to be I live in Eastern NC around the Greenville area (home of the East Carolina Pirates) and there are as far as I can tell very few software development companies within a 40 mile radius, I just moved here from Raleigh which is near Research Triangle Park (I didn't have a choice, it was either move here or to a cardboard box) so if this doesn't pan out I am planning on getting some dependable transportation and will be making a 100 mile commute everyday to work as a computer programmer.
I wouldn't worry so much about the code - that's fine. A bit unusual naming convention, but that doesn't matter - only that you have one at all matters. A few too many superfluous comments, but that's not so bad.
The database, however. Yikes! Redo that to use more normal data...how about a small inventory / shipping thing, or maybe a mailing list. An address book would be ideal. Get rid of that whole lb. versus ea. idea. Egad. It wouldn't be so bad except that your data concept lends itself naturally to some hardcore normalization, of which you do virtually none. (Category should be a lookup related to Item, you should be using a numeric unique identifier...ideally an AutoNumber, to link in the Items to the list instead of the name itself, and the same in Prices, and the AmtType should be a lookup, etcetera... Also, set some referential integrity.)
I'd hire you on as-is for a position in a team of front-end developers, but after looking at the database you created, I wouldn't let you near the back-end. You're talented, though. Spend a week redoing it up to your level of ability, and I'd have a vastly different opinion, I'd wager.
'they won't hire you based on a program you bring to them but they will hire you on the fact that you are a likeable soul and that you do hold the fundamental knowledge of the field you are trying to become active in.
Keep smiling and be courteous and mannerly and above all show a definate interest in becoming an employee of the company more so than just getting a job in programming.
PS>
your pgm is well documented, and it works. I would like a better screen but then again, I am an artist and space and color are a big item in my vocab. As for str verses s...bla bla...it's personal preference.
Wishing you the best of luck in your endevours.
Wayne
"A myth is not the succession of individual images,
but an integerated meaningful entity,
reflecting a distinct aspect of the real world."
___ Adolf Jensen
Would you explain what you mean by more normal data, as far as the functionality of the program is concerned I really don't see a way around the current make-up of the database and this program is something that I actually use to make my shopping list's so me and my girlfriend know what we spend before we go shopping which is the reason I chose this app as my example because I know that it works and that it does what it is meant to do. Any suggestions are welcome.
Also as far as naming conventions are concerned do the majority of software development companies use the microsoft standard naming convention or do you implement your own.
Finally what suggestions do you have for the GUI (I am far from an artist).
The interface needs to be tightened up - there is nothing intriniscally wrong with it, but M$ spend big money on usability consultants, so it's not a bad idea to rip off the MS design approach - their UI's are very well thought out. The flow isn't too bad, although the buttons should probably be moved (either to the far left or bottom of the screen.)
Learn a bit about ADO - you don't have to be a guru, as long as you can demonstrate that you realise that there are alternative methods to DAO.
The varible naming is a personal preference, and the company will probably have it own internal conventions (well, you would hope so, any way).
What you may need to do is to justify why you chose your particular style of coding (in this case procedural) over using a class/OO approach. Neither is necessarily any better than the other, but people will question you on the design approach, and the reasoning behind it.
Good use of parameters - it's quite nicely broken up, although the modDBStuff subs would require renamiong if the project was to expand (they names are too generic)
Oh, and there's no error handling. Might be worth doing that, particulalrly testing for vali database connections, and catching recordset update problems (locking etc)
done well written the code to standards, but you have not trapped runtime errors.
For eg if I enter a new item in the list that has apostrophe the code is taking it and adding to the list but when i want to select that item from the list it is generating runtime error 3075 you have to trap this error and write code in it.
Also another thing you have used listview I dont think it is clever to use listview when u have MSFlexGrid control which takes less amount of memory and u can also bind it to the database. You can also make the Remove Button disabled unless and until the user selects the item from the listview then u enable the Remove button.
Thats it few minor changes.. Regarding ADO there is absolutely no props for U. if u have SQL knowledge u can cope both ADO and DAO. In realistic sense ADO is simpler than DAO.
U have written good code. U will definately get a good job.
Best of luck..
By "normal" I mean two things. First and foremost, I mean "normalized". Take a look at this file...it's your database but normalized. Go to the Tools menu and pick Relationships, then drag the tables around to make it look like the bitmap I included in the archive. (I have Access 2000, which won't retain Relationship diagrams when converting to 97.) The only thing that isn't normalized is the pricing based on amount type. Which brings me to my second meaning of "normal".
The price based on quantity type is not normally found in your average business application. While it certainly could be, and would provide an interesting exercise in database design and normalization, it is more difficult to do properly than is worth the effort for a sample application.
The database I've included is normalized except for the quantity-based pricing issue. If you understand how and why I set up the tables this way, and can connect your apps into the new structures, that would be a big step forward for both your database abilities and your sample app.
Actually LAURENS it is a personal preference (I don't necessarily mean each individual user's preference, but the preference of the company or team that set the standards).
M$ does state using str, int, sng, etc. etc. but some companies and teams use differenct standards. My last company used s for string, i for int, n for single (can't remember them all) but they were a documented standard that all who worked in the company followed.
These were standards that were put in place eons ago when mainframes were the only computers in the company and DASD was expensive hence the shortened abbreviations to save as much space as possible.
So to maintain consistency, they just kept the old standards.
I would personally be hesitant about working for a person who would mention the prefixes of variables during the interview (unless he just mentions that they have standards in place and asks YoungBuck if he would have a problem following a different set of standards).
As I stated, the most important thing is to remain consistent.
(Stuffy humorless interviewer):
QUICK! What is the prefix for a String variable?
(Our intrepid YoungBuck):
str...no, wait...s.
S? S?!! Good God man, how could we possibly know if it's a String, or a Single, or was declared as Static? I cannot believe your ignorance! I have friends in this town, my young, foolish friend. You will be blackballed within the hour. Now get out of my sight!
(As the downtrodden YoungBuck shuffles out, the interviewer can be heard muttering under his breath):
"S? That's the most ridiculous thing I ever heard. These kids today..."
golly gee...
strCompare...hmnnn was that a string variable or a string function...hmnnn...damn, that's outright silly, guess I'll just use sCompare in this situtation...then again, someone might laugh at me for using sCompare so I better change my variable name and call it strComparative...and on and on....
get a life....if your variables are declared as they should be and your code is well documented you can use anything your little heart desires.
Dim myString as String ' used to reference Cust Name
myString = "Willie Jones"
Documentation!
Last edited by HeSaidJoe; Jan 30th, 2001 at 12:20 PM.
"A myth is not the succession of individual images,
but an integerated meaningful entity,
reflecting a distinct aspect of the real world."
___ Adolf Jensen
Well I went to the interview this morning and everything seem to go pretty well, not to many technical question's and the interviewer didn't even look at my sample app while I was there, but I got the 'will call you by the end of the week' statement which (in every other interview I've had for any job) means keep looking buster, but it was a good first experience anyway.
As far as the variable naming thing goes I do use the str, int, etc. for my private module level variables, I just use the single letter prefix for my function level variables to make it easier for me to spot the scope of a particular variable on the fly.
Now for the data normalization I see what you have done jmc and I would imagine that all the ___ID fields you have added are all using AutoIndex to make data retrieval faster, but I don't understand how, for one thing the database has now increased in size and how would I implement this into my project it seems to me as though I would need to run through some extra querys to retrieve the correct information.
Yep, it requires more involved lookups. It's bigger now because there is an extra table, and there are now relationships. If you added thousands of records to each table, your original version would be bigger due to having a bunch of big strings (69 bytes each, if I recall...hehheh) repeated in the various tables, whereas in the normalized version they are only 4 byte long integers.
Regarding the naming thing, if you want to tow the MS party line, scope is noted with an additional 1 character prefix applied before the type prefix. The table is:
Code:
g Global
m Module
Local (no scope prefix)
p Passed Parameter
s Static
Granted, static is a lifespan, not a scope, but it seems silly to give it its own table, so I include it in scope.
Therefore, glngUserID would be a global long holding the user id, pblnEnabled would be a boolean flag passed to a parameter, and mstrMessage would be a module (form) level string variable.
Again, that's the MS party line. I use it, but I didn't make it up. (Although I use "var" instead of "vnt" for Variants, cause I'm such a stinkin rebel.)
Glad your interview went well. The "we'll call you by the end of the week" isn't necessarily a kiss of death comment. I always found the "Where do you see yourself in 5 years?" question to be the kiss of death question.
I have NEVER made my students use the prefix to a Variable.
Only to Controls. I Do however suggest giving the Variable a good Name.
SO WHen you see it you know what it is. But if not..then to AT LEAST Document what its for.
So Give me a Break
Dim FirstName As String
is just fine and should not have to be
Dim strFirstName as String
---Geeez!!!
-Geoff
YoungBuck....My fingers Ar Crossed!
JPnyc rocks!! (Just ask him!)
If u have your answer please go to the thread tools and click "Mark Thread Resolved"
I have NEVER made my students use the prefix to a Variable.
Only to Controls. I Do however suggest giving the Variable a good Name.
SO WHen you see it you know what it is. But if not..then to AT LEAST Document what its for.
So Give me a Break
Dim FirstName As String
is just fine and should not have to be
Dim strFirstName as String
if you dont want it to be!
---Geeez!!!
-Geoff
YoungBuck....My fingers Ar Crossed!
JPnyc rocks!! (Just ask him!)
If u have your answer please go to the thread tools and click "Mark Thread Resolved"
I had an interview for a VB job this morning. With any luck, I'll make it through to the 2nd-round interview stage!
The 2 guys let me demonstrate my software samples to them, using a PC with a projector attached! I've never seen my projects blasted onto a wall 8 feet across each form! Sadly, the computer they gave me didnt have VB installed properly and my database app refused to work properly, but my translucent form went down well!
This in reply to jestes you definitely wanna error trap thread. Well I understand error trapping and I used it in the only place I felt my app needed it (although thanks to n_indureddy I see that I missed a couple of things). My question is do you mean I should use error trapping in every procedure, becuase that just doesn't seem necessary to me, I've always thought of error trapping as a way to use the error in your favor in your program.
It is generally a standard to add error handling in every procedure.....most error handling is very basic:
Code:
Public Sub DoStuff()
on error goto errhandler
'code...........
Exit Sub
errorhandler:
close whatever objects
Set whateverobjects = nothing
Call Error_File("Mmain", "DoStuff Sub", Err.Description)
End Sub
Public Sub Error_File(sModule As String, sRoutine As String, sError As String)
Open "AllErrors.txt" For Output As #99
Print #99, "An error occurred in YoungBucks's program while in the " & vbCrLf _
& sRoutine & " " & sModule & " module."
Print #99, "The error was: " & sError
Print #99, "The error occurred at " & Format(Time, "h:mm ampm") & " on "; Format(Date, "mmmm, d, yyyy")
Close #99
End
End Sub
You don't have to have a separate sub to record errors, but it makes it easier.
In addition to just writing to a text file, you can record all the errors in your database, or send an e-mail message.
When it is something only you will use, you can determine errors fairly easily, but if it is a distributed app, then you want to add the error handling so the users will be able to give you some useful information instead of "this dang thing don't work"
I have actually created a Class to handle all my error's before and I did put error handling in every procedure but after (I thought) I learned a little bit more I thought it was only necessary if an error was expected to happen, oh well good to know.
Reply With Quote
good but not enough
LOL
Toes crossed 