Here’s another installment of my VB.NET interview questions. Here are the earlier installments:
VB.NET Interview Questions #1.
VB.NET Interview Questions #2.
Feel free to add a comment with your answers. Try to answer them before looking at the comments or searching MSDN or Google for an extra challenge.
True or False
For ‘extra credit’, explain your answer
1. Pop and Push are the primary operations of a Queue data structure.
2. Only certain types of controls have an associated Graphics object.
3. Integers are an example of a reference data type
4. If a class has a MustOverride method in it must also be declared MustInherit.
5. Boxing is the term used to describe the process of sending data to a remote system.
General VB.NET Questions
1. Explain what a SqlDataAdapter is used for.
2. Describe some methods you can use in VB.NET to store binary data.
3. When should you use Regular Expressions?
4. Write an XPath expression that locates all of the ProductDescription nodes in an XML document.
5. Explain the difference between Option Strict and Option Explicit and explain when you should or should not use them.
6. What is the XPathNavigator class and when should you use it?
7. What criteria would you use to determine which string concatenation method to use, i.e. the concatenation operator “&”, String.Concat, or StringBuilder object?
8. How would you convert a Byte array into a String
9. If your database table had date columns that could be null how would you deal with this in your program.
10. If you needed to copy an array of one data type to one of a different data type how would you do it?
Open Ended Questions
1. Your job will be to convert an old VB6 application to a new web based VB.NET/ASP.NET application. Please describe, in general terms, how you would begin this process and what potential risks and problems do you anticipate.
2. A hypothetical company needs a way to send updated pricing in a more timely manner to their resellers. Right now they’re emailing them an Excel file with the changes on a weekly basis. What would you suggest that they do to improve this process?
Have fun with these and let me know what you think about them by leaving a comment or answering the questions.
Share This Article:
These icons link to social bookmarking sites where readers can share and discover new web pages.
Loading ...
October 7th, 2007
Guest Blogging
Aaron of AjaxNinja has asked me to guest blog on his site and, if we work out the logistics, my article should appear over there sometime in the next week or so.
If you would like to guest blog here on VB Notebook for .NET about VB.NET or general software development practices, please send me an email with your proposed idea. I’m always open to doing this.
Most Popular Posts
Here are the 10 most popular posts of the week:
WidgetBucks and BlogRush
WidgetBucks is a brand new advertising program I’m trying out. We’ll see how it goes but it doesn’t look too promising so far. I’ll probably give it another week or two or until someone decides to buy my header banner space.
If you’re the type that scrolls way down the page you may have noticed that I’m giving BlogRush a second chance. A fellow blogger suggested that I try it again since they’ve weeded out a lot of the spam. It still doesn’t give very relevant results or bring much traffic but doesn’t seem spammy or hurting anything so I’ll leave it way down there for now.
Coming Up Next Week
It was suggested that I look more deeply into to coaching team members since last week’s article only scratched the surface so I’ve been researching this topic some this week. Maybe I’ll have an article on this prepared soon. I’m still working on narrowing down some ideas on ADO.NET, XML, and Web Services. I am open to requests, so if there is a topic that you would like for me to cover, let me know in a comment or email.
Share This Article:
These icons link to social bookmarking sites where readers can share and discover new web pages.
Loading ...
October 6th, 2007
You probably know that Generics, introduced to VB.NET in the .NET Framework 2.0, provide type safe Lists, Dictionaries, Stacks, Queues and other objects. But, did you know that you can use the same technique to build your own type safe functions? In this article, we’ll look at some of the basics of doing this.
Why Generics?
First, let’s look at why generics are important.
Prior to generics we had to base any general purpose routines either around a particular type or use System.Object. This meant that we couldn’t make a routine as general purpose as we might want or we had to use performance impacting boxing to place a value type, such as an integer, into a reference type. Plus we had to use type conversions in many places or, worse, not use Option Strict so that we could do implicit conversions.
With generics, we can work with any type but without incurring performance penalties associated with boxing/unboxing variables or doing any casting. More importantly, we’re insuring type safety and thus avoiding troublesome runtime errors. Using them also makes it easier to build single functions that can work with several different data types.
MyFunction(Of T)(…
To begin with, let’s look at how we can define generic type parameters in our own functions. Here’s a simple example that accepts a paramarray of values of a specified type and places then into a generic List of the specified type:
Private Function BuildList(Of T)(ByVal ParamArray values() As T) As List(Of T)
Dim NewList As New List(Of T)
NewList.AddRange(values)
Return NewList
End Function
Notice that when the function is defined we specify a generic type first, (Of T), and then our parameters, followed by our return value. Here are some examples of calling this function:
'
'
Dim StringList As List(Of String) = BuildList(Of String)("test1", "Hello!", "Bye!")
'
'
Dim IntList As List(Of Integer) = BuildList(Of Integer)(1, 87, 48, 28, 24)
'
'
As you can see we’re calling the same function but using different data types.
You can also specify multiple types and you’re not limited to just using ‘T’ as the name, as we see in this example that merges two lists of the same size into a dictionary object:
Private Function MergeLists(Of TKey, TValue)(ByVal Keys As List(Of TKey), ByVal Values As List(Of TValue)) As Dictionary(Of TKey, TValue)
Dim MergedDictionary As New Dictionary(Of TKey, TValue)
If Keys.Count = Values.Count Then
Dim Counter As Integer
For Each Item As TValue In Values
MergedDictionary.Add(Keys.Item(Counter), Item)
Counter += 1
Next
End If
Return MergedDictionary
End Function
Calling this function would look like these examples:
'
Dim MyItems As Dictionary(Of Integer, String) = MergeLists(Of Integer, String)(IntList, StringList)
'
'
Dim MyInventoryResults As Dictionary(Of Integer, InventoryItem) _
= MergeLists(Of Integer, InventoryItem)(KeyList, MyInventoryItems)
'
'
Also, we can have specific types in our paramaters while returning a generic type. For example, this function accepts a DataTable and Integer and returns a List object of the specified type with data from the specified column index.
Public Function ColumnToList(Of T)(ByVal MyTable As DataTable, ByVal columnIndex As Integer) As List(Of T)
Dim ReturnList As New List(Of T)
For Each RowValue As DataRow In MyTable.Rows
ReturnList.Add(DirectCast(RowValue(columnIndex), T))
Next
Return ReturnList
End Function
Any time when you’re coding and you think, “Well, I’ll have to have a separate routine for this data type, and this one, and this one, and this one too”, take the time to consider if using generics will work for you in that case. Often you’ll find that it will.
As always, if you have any questions or ideas on this topic, feel free to leave me a comment.
Share This Article:
These icons link to social bookmarking sites where readers can share and discover new web pages.
Loading ...
October 5th, 2007
I found several great links this week. Here they are:
.NET Stuff
Jonathan Aneja, a member of the VB Team at Microsoft, posted this article, Option Strict [On|Off|SortOf], that talks about how to bypass Option Strict under certain conditions, such as when doing late binding. Like Jonathan, I don’t recommend it but he shows how you can implement Option Strict ‘SortOf’.
Here’s a nice write-up on the ASP.NET page lifecycle over at the Code Project by ‘UsualDosage’. In it he coins the acronym “SILVER” to define the process.
At Chindo there is a follow-up on a previous article on StringBuilder performance called StringBuilder is not always faster - Part 2 that has some interesting benchmarks followed by some good performance tips.
Regular Expressions
I found two good articles on the basics of using Regular Expressions, Basic Regular Expressions by Adam Wolkov and Developer’s Notebook: Mastering (your fear of) regular expressions by Brian Dillard. The first is a good, basic, tutorial on how to use expressions while the second is a good directory to several RegEx online resources. (Oh, and Adam, if you read this, consider opening up your blog to comments. Use a captcha or other method to block comment spam.)
Project Management
This US Navy article, The Monkey Experiment, (or) “Why Do We Do That?” has been making the rounds. Have you ever been beaten up by your fellow code monkeys on a project for no good reason?
Peter Van Ooijen wrote this opinion piece, An architect should code. Period, over at Code Better. I’m not sure if I agree with him 100% but he does raise a good point. My main concern over his article is that this bias could easily morph into ageism which is already widespread in the IT industry.
Jobs
Speaking of ageism and sexism in the IT workplace, here’s a good InfoWorld article that takes this on: U.S. faces competitive disadvantage from lack of women in IT.
Over at Raganwald, there’s this good article on interviews: Take control of your interview. I liked his comment about politicians “staying on message.” It reminded me of an SNL skit that involved the term “Lockbox”.
That’s it for this week. As always, if you see a good .NET or general software development article I should read let me know by leaving me a comment or using the contact me button.
Share This Article:
These icons link to social bookmarking sites where readers can share and discover new web pages.
Loading ...
October 4th, 2007
One of the common problems we encounter in developing software is that it is difficult to completely know everything about a desired solution before we begin. Another is that sometimes we lose focus on what exactly we’re supposed to be building while another is having a too limited view of the project. Let’s take a look at these common blind spots that can plague a software project and how we can deal with them.
Losing Focus on the Solution
The saying goes, “When you have a hammer, everything looks like a nail.” When you have a programming language, methodology, third party library, or other tool that you enjoy using you can start to focus on the tool rather than the solution. Some developers do this when it comes to OOP, over designing and tweaking objects while the actual application development languishes. Others become consumed with a particular language, tool, or method and apply it blindly, assuming it’s a panacea for any and all situations.
The important thing is to never lose sight of the goal of producing a working application within a given timeframe. If your project is encountering schedule slips related to redesign or if problems or limitations with a particular language, tool, or method are becoming readily apparent, take a step back and evaluate what you’re doing. Do what it takes to get your focus back on developing the solution that is needed, even if it means scrapping a favorite thing.
Wearing Blinders
If you’ve ever seen racing horses, carriage horses or farm horses you’ve probably seen them wearing blinders. These pieces of leather or other opaque material prevent the animal from seeing behind them or, sometimes, to the side as well in order to keep the focused on the task at hand. Sometimes people who are too narrowly focused on a problem are said to have blinders on. In development projects, this can happen when programmers and architects ignore what interactions their application will have with other programs or the business processes of the organization.
This can be a very subtle blind spot to detect because often things will go very smoothly at first since the tight definition makes it hard to wander off the path. Problems begin to crop up when the new program is integrated into the whole software and business framework. For example, your application updates records in a particular table while another longstanding process deletes records out of this table. Or perhaps users find your program a roadblock to performing their jobs because they have to go out of their way to work with it.
To avoid this blind spot don’t allow haste, political pressure, or just pure laziness to limit your analysis and design to a narrowly defined set of criteria. Make sure you allow room for changes, even if it’s in a later release, to handle these unexpected situations. Some development methods make this kind of problem easier to avoid by involving users in the process but you still have to watch out for this blind spot due to its hidden nature that can sneak up on you.
Assuming We Know Everything
What is the scope of your ignorance? What is it that you don’t know and don’t know that you don’t know it? It is often said that in a given software development project of a reasonable size that only about 20-40% of the problem is known while the application is being developed and that known unknowns, the boundary between knowledge and ignorance, only accounts for another 10% or so. This leaves a whopping 50% or more of a blind spot that can come back to give us considerable trouble. So, what can we do about it?
The first thing, of course, is to make sure we, and people associated with the project, understand that we’re not going to know everything about the problem domain. Jim McCarthy of Microsoft refers to this as “lucid ignorance”:
It is essential not to profess to know, or seem to know, or accept that someone else knows, that which is unknown. Almost without exception, the things that end up coming back to haunt you are things you pretended to understand but didn’t early on. At virtually every stage of even the most successful software projects, there are large numbers of very important things that are unknown. It is acceptable, even mandatory, to clearly articulate your ignorance, so that no one misunderstands the corporate state of unknowingness. If you do not disseminate this “lucid ignorance,” disaster will surely befall you.
It is better to admit our ignorance and have a successful project, even if it isn’t a 100% success, rather than assuming we know it and have a project failure. Ultimately, our goal has to be to reduce the uncertainty gradually as we classify our ignorance and break it down into manageable pieces. But, we still have to be aware of the fact that we still won’t know everything.
Have you seen any of these three blind spots? Do you have any other examples of blind spots in the software development process? Let me know what you think by leaving a comment.
Share This Article:
These icons link to social bookmarking sites where readers can share and discover new web pages.
Loading ...
October 4th, 2007
Next Posts
Previous Posts
(6 votes, average: 4.5 out of 5)
