Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Ok here is my situation. I've studied Java in my college for 2 semesters. But you know they teach you jack in there, just the basics. We skipped half of our textbook and even then our professors don't teach from section to section of each chapter. I don't blame them. It's hard as it is for new students to understand even the basic concepts of programming. Now this is a community college we are talking about and not Stanford, MIT or Berkeley.
So like I said I've done 2 semester of Java. I really like our textbook because it has some challenging projects to do at the end of each chapter. This textbook is pretty clear and i have no problem understanding it (although 2-D and 3-D Arrays have given me some trouble). I have tried reading a few C# books such as Pro C# 2008 and .NET 3.5 and C# 4.0 in a Nutshell. I found these books to be dry and overloaded with information that put me to sleep (No offense to the authors of those 2 wonderful, according to amazon ratings, books).
Would you suggest I finish my Java textbook, brush up my knowledge of Arrays, Polymorphism, and etc that are universal to most programming languages. And then switch to C#, plus the syntax is very similar so it should be easy to switch. Or should I just start learning C# right now from the very beginning? If it's the latter then could you recommend some free online resources that will keep me engaged and at the same time teach me everything I need to know about C#.
Someone has recommended me to learn .NET first, but I found it to be not the brightest idea. .NET is just a big monster full of libraries. How am I going to apply it if I don't even know the C# or VB!? Anyway back to my question: Master Java and switch to C# or just go with C#?
DISCLAIMER: I don't want to start .NET vs J2EE or C# vs Java flame war. I am going with C#. I've decided that I want to work in a Microsoft shop in the future. .NET is what I want to learn.
Thanks! Will be waiting for the answers.
I found myself in pretty much the same situation as yourself whilst studying Java at community college - I am smiling right now :). That was 10 years ago and D flat, as some wags were calling it, was starting to make some noises.
What I did, was do all of my assignments in both C# and Java, so that I could get to grips with both. I then begged to do my final year project in C#, which they eventually relented on. Getting practice in a couple of languages and doing a major project will stand you in good stead.
I have never looked back. Good luck! :)
Both Java and C# concepts and syntax are very similar.
I would concentrate on the one you expect to use after completing your studies. Look at which is asked for more often in the area you are intending to work.
As a side note, C# 4.0 in a Nutshell is an excellent book both for learning and reference. Suggest you give it another go.
I think I found the answer to your question...in your question.
For now, go ahead and finish your Java book as a way of continuing to learn the fundamentals of OOP.
Next (or while finishing the Java book), shift your focus to C# and the .NET framework (in most business situations, you'll be hard-pressed to find one without the other).
If you want to focus more on language elements of C# rather than a specific framework (such as ASP.NET, Silverlight, Windows Forms, or WPF, to name a few things), you might consider a book on LINQ, such as LINQ in Action from Manning Press. Combine your knowledge of LINQ with trying to solve some problems at http://projecteuler.net and you should start picking up the language pretty quickly.
Personally, I read Illustrated C# 2008 by Daniel Solis. Granted, it's not a textbook filled with lots of fun and challenging examples, but it is a good exposition of the language.
Don't worry so much about any particular language, and "Teach yourself programming in 10 years": http://norvig.com/21-days.html
Since it sounds to me like you don't really know a lot about programming, and this is largely your first major exposure to it, I think it's absolutely in your best interest to stick with something until you have learned enough of it that you are satisfied with your skill level. Jumping now may hurt you later, because you will be covering a lot of concepts you probably already know.. but hidden inside will be something you don't, and thus you will skim right over it.
Keeping yourself "engaged" is only something you can do, not the text. Certainly some texts are more interesting than others, but you have to be committed to reading the material whether or not you find it boring. That's how you learn.
Both Java and C# are syntactically similar at the basic level, but they both diverge from there in different directions and do similar things in different ways. Further, the languages are largely useless without the base class library, and those are often very different between languages.
What you didn't mention was how you are doing in school. Does your school require you to do more java work? If so, then you will have to stick with it. If not, and you are "done" with it, then perhaps starting over with C# from the beginning would not be a bad idea. Just think of C# as a new language you have to learn from the ground up, even if much of it seems familiar.
I found the Wrox book series to be particularly good to learn from, along with the Head First book series. As for which one to continue I would say it depends on what you are tested on. If you have to do written exams and write out sample code. You don't particularly want to start banging out C# by accident.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I've been programming for a few years in C# and XML. I used only the basics of those languages and have survived on the web for info like arrays and text manipulations. But when I am get interview, the interviewers ask only advanced questions - I found the answers later in the Advanced sections in the books on the subject.
Why do the interviewers ask such advanced questions? The job looks almost the same as what I was previously doing, so there's need for advanced knowledge, like what class delegate is or XPath commands.
Questions are:
What version of XSL does .NET 3.5 uses?
What XPath command to use to get value in element X?
What are class delegates in C#
Does C# allows multiple interface inheritance?
How do you access GAC in C#?
There are two reasons that I ask them.
To see a person actually say "I do not know the answer to that", as opposed to trying to BS through the question.
To see what kind of logical problem solving skills a person has.
Usually a question will be of one or the other, but not both. Both are extremely valuable in screening a perspective employee, however.
Also, the question might not actually be "advanced" for the position. It is reasonable to assume that Senior-level and/or Architects can answer questions that a Junior to Mid-level might not.
Perhaps because they are trying to find programmers who know more than the basic stuff. If they are trying to distinguish between a field of candidates, it isn't helpful to ask questions that everyone knows the answer to - how do you select among those candidates? If you're going to hire only 1 or 2 out of a pool of candidates, you need to find some harder questions that only 1 or 2 out the pool can answer.
Getting the answer wrong is what I want from an applicant in some cases.
One of the reasons I like to ask a question that I think the applicant will get wrong is to see how they adjust to the situation. How they handle getting something wrong and handle someone telling them how they should have answered etc. If they are very defensive or rude when you tell them they are incorrect then it is a good indication of how they will work on a team when many times your ideas will be challenged.
If they take the solution or recommendation and realize they can learn from it or even add to it that is usually a sign of someone what is easy to work with and willing to work 'outside of their box'. If they just make excuses and dance around trying to say why they could be right or should be right (in cases where they are clearly not) then this tell me when the same issue arises in the future this applicant is going to cause headaches.
Not so worried about the answer, more interested in how they react to the question / solution.
Another reason would be to gauge their level when hiring as well. You might be hiring for a bunch of positions but not sure where this applicant fits. Hard questions that show problem solving and attention to detail can sometimes make it easier to categorize their skill set.
I ask advanced questions for a few reasons:
Some of my questions are advanced usage of things everyone should know (not a trivia question) -- I want to see you reason through the answer using knowledge you have, but in a way that isn't common.
I want to see what happens when you don't know something -- do you give up?
I want to hire people that are serious about what they do. People that really care about the technologies they use tend to want to know the advanced stuff.
I want to see if there are gaps where you just don't know that an entire area of knowledge even exists. For example, in your XPath example -- I might be ok with: "I believe that XPath could be used to help solve this, but I don't know it well enough to write it out here" -- then I would show them a little XPath and see if they could apply it. If you don't even know that XPath exists, google isn't going to help you.
Likely they're just getting a gauge of where you are. They probably got stuck on this problem themselves and perhaps wanted to see if you could think of an answer on your feet.
I've experienced the same types of questions, and considering when I program I use excessive resources, this type of thing usually throws me off. Their loss.
Because competency as a programmer involves both depth and breadth of knowledge.
The interviewer is trying to devine your level of knowledge, and he is copping out by "borrowing" a question from the last chapter of that book.
Really, this is sloppy work on his part, relying on one question to guage your expertise level. You may have low programming skills, but recently come across the buzz-word, and are able to ace the interview.
I did get burned once in interviewing a candidate who professed high levels of C expertise. It turned out that he was reading "C for Dummies" and managed to BS through the interview process. I admit that I wasn't concentrating on his programming skills, but was looking for other aspects, which he also managed to BS through. Turns out his whole resume was a pack of lies.
Nowadays, I make sure the candidate has working knowlege of variable scope, persistance, pointer arithmetic, basic algorithms, structured programming, object-oriented programming, polymorphism, multitasking and inter-process communication. I will quiz him on his debugging skills, and zero in on details such as race-conditions, heisenbugs and security vulnerabilities.
Depending on the job, I will ask about experience in the target language - such as key=>value maps (arrays) in PHP, Swing programming in Java, event handling in C#, tables vs CSS in html -- you get the picture.
If the candidate passes the first part of the interview (I usually know within about 5 minutes), I will then give him a binder and send him into the coffee room (nice couch and table there) to prepare for 20 minutes for a code review on a selected module.
That's when I send in the troops - employees are instructed to use the coffee room normally, introduce themselves and make conversation for about a minute.
What I'm looking for is the ability to concentrate on a task (blatant ADHD), the ability to work under pressure, and interpersonal dynamics.
When the candidate returns, I have him act as main presenter and start our normal code review process. The first thing I look for is if he read the page titled "Code Review Process". I'm not looking for him to complete the review - about 10 minutes is enough. As a matter of fact, the fewer main lines processed, the better - within reason.
I haven't been burned by a new hire for a long time now.
Your username suggests you like coding (duh), but your question suggests you don't. If you really liked coding, then you should love to learn about it. Those questions that you listed are not that advanced.
Even if those questions were advanced, the interviewer is trying to gauge how much knowledge you have in the area that you say you have knowledge in. They are also trying to gauge how well you would fit into their group.
P.S. Not to be mean, but if you program using XML and don't know what XPath is, then you are a little far behind.
They probably want to see if you really know what you're talking about or if you're a novice programmer who gets along on the web using only what he has picked up through trial and error...
1.What version of XSL does .NET 3.5 uses?
Because they can't tell important things from non-important ones. Bad sign.
2.What XPath command to use to get value in element X?
Because they want to see if you know XPath. This can be either because they use it extensively and you need it to get they job done or because they think XPath knowledge == skill.
3.What are class delegates in C#
(I've never heard the term "class delegate" and a google search shows no definition, so I assume you mean just "delegate").
Delegates can hardly be considered an advanced topic.
4.Does C# allows multiple interface inheritance?
If they really asked about "interface implementation", it's part of the most basic concept so it's a valid question (although too simple to really mean anything). If they really asked about "interface inheritance", it's more of trivia, but I would still say acceptable. Bonus point for them if they asked what "interface inheritance" really means.
5.How do you access GAC in C#?
This is the kind of thing every team MUST have one person who knows. I'd say it's also a indication of seniority (which BTW, I don't care much about) since nobody reads about these things, the only way to find out is to be forced to solve a real-world problem.
I ask advanced questions to try see how people work through the problem. I like to ask questions that I don't know off the top of my head for that reason.
I want someone who is a critical thinker rather than just an academic who can recite text books to me.
They want to find someone with practical experience that extends beyond what is taught in beginner courses. When my company interviews candidates, we often find that most of the applicants cannot solve what we would consider to be very basic programming problems simply because they don't know the API or don't understand when to use various basic data structures.
If you want to impress an interviewer, work on your own programming projects outside of class. Learn a good chunk of the language API, and start learning about third-party libraries that can greatly simplify your work.
Another reason is to gauge your response to a question they really don't expect you to know the answer to. Problem solving skills are essential, so asking you questions you already know the answer to is not going to address that, is it?
There are even instances of companies asking odd, non-programming related questions just to see how you think your way through a problem. There is the classic "Why are manhole covers round" question, reportedly asked at Microsoft interviews.
More Microsoft interview questions
I'm not meaning to offend you but maybe your understanding of the job is not deep enough and it in fact requires knowledge of advanced techniques.
Also, you can do a lot of things with basic methods but advanced methods might the better way to implement regarding complexity, time to implement or maintainability.
There are many possible reasons. They may:
actually use those techniques (delegates and XPath aren't particularly rare or obscure)
have a large pool of candidates and want to try to find the more knowlegable ones
want to see where the limits of your knowlege are, so they ask question up to the point where you start to be unable to answer well
want to see how you might approach areas that are unfamiliar to you - to see how you might adapt to new stuff
want to show off their own knowlege (probably not a legitimate reason, but it certainly happens)
I've heard these really aren't in use anymore, or at least not nearly as much as they used to be, but you might be interested in this. I picked up a pretty cool short book a few days ago that has to deal with the "Microsoft style" logic interview questions that are sometimes asked. I'm a few chapters in and it gives a neat little history of the tech field's interview style and has a ton of logic problems, complete with answers in the back.
It's called "How Would You Move Mount Fuji" and it's on amazon for pretty cheap.
http://www.amazon.com/gp/offer-listing/0316919160/ref=dp_olp_used?ie=UTF8&condition=used
I've just completed a round of interviews, where I use a three or four stock 'simple' C# code fragments that the interviewee will look through and attempt to explain what the expected result will be. In each case the code sample is no more than ten lines of clearly-formatted code that utilises basic C# skills (inheritance, generics, anonymous delegates); also in each case there will be a 'gotcha' - but like others have stated, I don't put these in to be spiteful, they're there because I want to see how the candidate reacts when confronted with something that doesn't work as expected.
We had a candidate recently that had sailed through the first part of his interview; impressive CV, was apparently the Lead Developer of a team of 10 and had been developing code in C# since 1.0; yet apparently had no idea what "Console.WriteLine()" did (nor could he even hazard a guess), nor could he even begin to cope with the tiny anonymous delegate example.
Another candidate was self-effacing, and didn't know how to grade herself as a developer - she'd had less experience than the former candidate yet she sailed through the code samples, fell for a couple of the 'gotchas' but asked the right questions to get the correct conclusions and genuinely learnt from the experience. Needless to say, she was hired.
If you're claiming domain-specific knowledge (like XML) you should expect to be asked specific (and sometimes hard) questions about that domain; if I'm interviewing a senior ASP.NET developer and they've got no idea about HttpModules or HttpHandlers (like some recent interviewees) then alarm bells start to ring.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I use LINQ in my code all the time. I've gotten to the point where it just seems so natural to Group, Order, an organize a bunch of objects using the LINQ syntax that I struggle to think how I would do the same things without it.
I had never delved into the SQL-esque world before this, but I imagine many people who learned even the normal SQL syntax suddenly felt constricted by most normal programming languages abilities to wrangle complex object hierarchies?
Am I painting myself into a corner becoming reliant on LINQ to do my more complex tasks? It just feels so much more expressive than if I wrote plain C# code.
Is becoming dependent on the LINQ syntax in my day-to-day programming going to hurt me in the long run if I end up switching languages or frameworks where something like it isn't available?
Fortunately, no. The "LINQ" way of thinking is more properly understood as a "functional" way of thinking, and this is a highly transferable mindset.
Obviously when you move from language to language and framework to framework the syntax and framework methods will be different but the mindset is the same. The important skill that you have aquired is the ability to think in terms of sequences and functional pipelines that process those sequences.
Instead of looking at your prospective future outside of C#, I would concentrate on what helps you get your work done today.
If that means using and becoming fluent with LINQ, so be it. As long as you're willing to learn and adapt in the future (just like today) it won't be that big of an issue.
Yes, your concern is valid.
That is, when you get good at using any tool, you start to forget how to function well without the tool. You also get frustrated when that tool is not available.
For millions of years humans were able to feed themselves without the use of metal tools. They weren't miserable. Today very few know how to do that, and most are scared of what that would be like.
For tens of years humans wrote software without real-time interaction with a computer, e.g. punch cards. They weren't miserable. Today very few know how to do that. The idea of doing that sounds miserable to me.
If you become adept with Linq, you will miss it when it's not around. It's a great tool. As your skill with Linq grows, your skill of programming without Linq (which you aren't practicing) will become rusty.
In all the above cases, we have replaced a human skill with a tool + a new human skill. Each time, the idea of giving up the tool sounds scary. I believe there's always some value in exploring the older, lower-tech way of doing things, as it helps me become more well-rounded, but usually I'll pick the higher-tech way.
So, don't shy away from Linq, but do explore other ways of doing things, as part of your self-education as a programmer.
Does it matter? Every language has its unique nice features. It's like saying "Will using braces in C# make it hard to transfer it to another non curly brace language?"
Its not going to hurt you. I truly believe all modern languages are going to move to this syntax very shortly. Java is already moving in that direction, and other languages will follow with something similar. MS, for all of the bashing they take, were way ahead of the curve on this one. The wiped out a whole class of bugs related to temporary variables/arrays in terms of querying array objects. The benefits to this are enormous.
LINQ is a great thing. It will spread. In fact, the spread has already begun.
If it could be equated to learning OO, I know people who have gone from C to an OO language and back to C and although they didn't have objects available, they tended to be able to use many techniques in a language without objects.
Could the same thing happen with LINQ?
Yes, it will hurt you if LINQ to SQL is the only sql you know.
I find that understanding the logic behind it helps me feel better about using LINQ extension methods. If you can write your own Where or Group ..etc extension methods then there is no shame in using them.
I think it's important to understand what's going on behind the scenes of high-level abstractions like LINQ - otherwise you can have problems such as performance. Funnily enough our host's latest blog post is on this subject.
So if "thinking in LINQ" means forgetting this, which I suspect it does for some developers (present company excepted), it could be considered "bad".
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
How can I increase my proficiency in programming? I have a grasp of the basics of C#, but don't feel too confident about my ability.
Code something in C#
Read C# Code and try to understand it.
Read a C# Book (and please none of the C# in 21 Days books)
The confidence comes with the experience.
Read Stack Overflow every day :)
Seriously. Try to solve interesting problems. Even if you don't post your solution, come back later and see if other people came up with something similar, why their solution might be different, etc.
Project Euler.
http://www.asp.net/LEARN/videos/
Voile, you are programing ASP.net.
Keep in mind that you may need a little more grasp on C# as your codes evolve. For that use a good book, most Microsoft's learn C# are pretty neat(The learn ASP.net is quite lame).
Of course, thats what I did back then(about 2 years ago), nowadays you should be able to find some awesome tutorials online.
Good luck ;)
Think of a fun project of some complexity (more that "Hello, world") and code it.
Practice, practice, practice!
Also read forums, blogs, participate in discussions. You will learn many things that aren't even mentioned in books.
read lots of code, write lots of code and keep a copy of C# 3.0 in a nutshell handy.
Learn new programming languages. Learn data structures and algorithms and design patterns. Learn regular expressions. Learn databases. Learn HTML/XHTML/DOM. Learn learn learn learn learn.
In programming, knowledge === power.
Work on something, even if it's reinventing the wheel. You can read books, watch videos and listen to podcasts all day, but the real experience comes from actually building an application. Don't build an application that you know you can build - instead, create an application that is slightly out of your reach, then rinse and repeat.
The experience when you realize that you created a mess of spaghetti code that is unmaintainable cannot really be substituted, as this then really allows you to look into techniques to improve your code. Sure, feel free to read on MSDN about Events, Delegates and Lambdas, but reading about them in the moment you need them means that the knowledge really burns into your memory.
I try to have a rough knowledge about as many topics as possible, but that's usually rather shallow: I know that a technique exists and roughly what problem it solves, so that when I need it I can learn about it.
In my opinion, the only alternative to first-hand real world experience is even more first-hand real world experience.
http://www.appdev.com/csharp.asp
:)
You say you are learning ASP.NET and C#. Have you ever done any programming or web development? Because, if you have not, then you need to take a step back and learn the basics of HTML, CSS and get a grasp of how data is passed via HTTP between client and server. I would also strongly advise getting a grounding in basic SQL, because most serious web development will utilise databases at some point.
After that, some basic OOP (Object-orientated programming) theory would do you good. That way you have a good grounding in the subject-matter before diving into the coding.
For learning C# the I'd suggest a couple of good tutorials:
The C# Station Tutorial and Softsteel Solutions C# tutorial.
I also found the ASP.NET Quickstarts useful when I was learning ASP.NET - I prefer to learn by example than by theory.
As for confidence, I'm afraid that only comes via experience. Perhaps try answering a few questions here? Getting a few up-votes might just give you that boost. Good luck.
This fits in to catagory of answers you've received thus far, but review open source projects.
Understand how they work and maybe even why they were put together in a given way. Not only will it improve your ability to write C# but it will also improve your understanding of Software Engineering which is ultimately how you put a programming language -- C# or otherwise -- to good use.
Creating a Project that makes use of a lot of different technologies is a good way to grasp a 'big picture' view.
As an example, think of an n-tier application where you input a value into a very simple web page, this value being sent into a web service, and behind that WS a simple business layer that switches between readings into a table of a data base, then you return the value finishing the output in a postback of the initial web page. In my Personal opinion, every element of the layer is a simple one, but, making the whole system work without errors is good beginner's challenge, that way you could build a confidence in your skills, enabling you to undertake any other idea.
Well, that were my two cents. Good Luck!
There may be so many projects that u can make.choose the project that makes u.it's true take a project that you consider difficult for your level.
1) analyse your project
2) define the objective
find things that are necessary to achieve the objective
3)then derive an algorithm which clearly explains the workflow
4)then start woking
In my experience "Learn By Working" is a good idea.first grab the basics then start the work soon you'll learn step by step.never give up ,be a ceaseless crusader.
practise practise it's a only way of surviving as a programmer.
Being a best programmer requires a lot of patience,thinking skills,Attention,a thrist for knowledge.
Wise people always replace the fear of unkonwn with curiosity
Actively participate in programming (and non-programming) forums.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I have been a VB.net developer for a few years now but I am currently applying to a few companies that use C#. I have even been told that at least one of the companies doesn't want VB.net developers.
I have been looking online trying to find real differences between the two and have asked on crackoverflow. The only major differences are a few syntax difference which are trivial to me because I am also a Java developer.
What would be a good response to an interviewer when they tell me they are looking for a C# developer - or similar questions?
I've had to interview people for a few C# positions and this is my general advice for VB.Net developers interviewing for a C# position:
Make sure you are clear that you have been working VB.Net. This seems obvious but is something that apparently isn't (in my experience).
Try to give a code sample, if possible. I've seen some horrible VB.Net (and C#) written by VB programmers who didn't seem to learn much in the transition to .Net.
Be able to write in C# during the interview, if asked. I know there aren't many real differences between the two, but I don't want to pay you to learn the new syntax.
For your specific question: I've asked that type of question before and what I wanted to hear about was how the underlying system and framework were the same. If possible, talk about garbage collection, IDisposable, finalizers, the dangers of unsafe code blocks, stack vs heap, etc. All the kind of stuff to show that you really understand the intricacies of the .Net framework. Right or wrong, the heritage of VB brings with it an expectation of a lack of understand of lower level programming and windows in general (which, ironically enough, a c++ developer would have of a c# developer... and so on).
Lastly, how you frame your experience can make a world of difference. If you position yourself as a .Net developer, rather than VB.Net or C#, the stupid, pseudo-religious, banter may not enter the conversation. This of course requires that you actually know both VB.Net and C# at the time of the interview, but that's a good policy regardless.
The truth of the matter is that if you find that the person interviewing you writes you off simply because you've previously been developing in VB.Net, it's likely not going to be a place you want to work at anyway.
Some differences (that are more substantial than syntactical) that suitably catch me out sometimes:
VB.NET does not have anonymous delegates
Unsafe code blocks aren't in VB.NET
I love C# to death, but I envy VB.NET's optional parameters. Office automation in C# is so very, very painful.
I think the truth will-out on this:
I'm a software developer, the syntax of the language is the final part of the puzzle. By employing me, you're getting someone with demonstrable experience of problem solving and logic. I'm experienced with the .NET environment, the CLR and the associated Windows stack, including SQL and Windows server. I don't know the C# syntax, but, I am used to object-oriented approach, I will have no problem getting totally up to speed on the finer points of the syntax within a couple of weeks. You can see from these examples of my code that I'm an experienced developer, I assure you the transition will be seamless. I have already made a start learning the language, I haven't had any problems so far.
#DAC - VB now (in .net3.5) has support for lambdas:
Function(x) x.ToString()
In an interview I'd say that understanding the CLR and what the code's really doing is what's important, and that you're happy to code in either (assuming that you are).
I'm also a C# feller to the death but the differences are not just syntax. There are places where VB wins HANDS down
Optional parameters
Late binding
Working with COM from C# can be a very frustrating affair. (Which is not to say impossible!)
Truthfully? If you're a Java developer too, I'd lead with that. A Java developer with some experience in .NET will generally make a better impression than a VB developer with experience with Java. If you can answer questions on the difference between .NET and Java you should be in good shape.
I'd also recommend you learn the C# syntax ASAP. If you're experienced with VB and Java it won't take long.
A lot of developers have issues with VB and the people that use it. Valid or not you'll have to deal with that reality.
VB or C# both are syntax only diffrent but if you are applying way of logic is same.