|
I'm going to go the other route and give you the TRUE REALITY on these types of interviews. DON'T SWEAT IT.
1) Interviewers are generally very cocky / arrogant during the interview. Why not? Your fate is in their hands. Now some interviewers take pride in being complete douche bags during the interview. I've run across MANY of these types in my 17+ yrs. Basically, they spent the last couple of weeks doing something really obscure that they are super proud of and they think they are "da bomb" because of that and think you are a looser if you don't have that same obscure knowledge.
2) Did you take a brow beating on "common knowledge" type stuff? Or were they peppering you with obscure questions you would run across 1% of the time? I.e. I could ask a guy I'm interviewing to go up on the white board and write out the code for a LINQ expression tree that returns the private property of a base class. Thats a douche bag question. Nobody would know that. If you get those types of questions, write the interview off as the guy not really wanting to hire anybody for his own personal reasons. If I asked a guy to describe the differences between a Grid, StackPanel, ViewBox, etc. and he didn't know that, thats kind of different.
3) Some guys ask you real world questions to get a guage of your real world knowledge while other guys will ask you mostly advanced / unpractical things just to try to get under your skin and see if you buckle under pressure. I had a friend whose interview style was exactly this. He would do his best to get you to curl up in a fetal position in the corner and start sucking your thumb and crying for mommy... he did that because a) he was arrogant b) he was a douche c) he wanted to see if you would come into work with an assault rifle if things got stressful d) he was a douche
I don't want it to sound like I'm bitter because I got turned down for a few jobs, this is just reality of how interviews go.
Heck, I have a co-worker at my current company that throws out anybody who can't recite RegEx off the top of their head in an interview.
I couldn't recite ANY RegEx off the top of my head. Who cares? I can go to www.regex.com and c&p a regular expression from there. If its a custom regex I need, well, I'm sure I can figure it out.
|
|
|
|
|
Thank you for the feedback, I have been pretty down this morning about the whole situation. The questions were not obscure, they were just outside the scope of my experience. I have been writing code ad hoc by myself for ten years, so the code works and that is the end of it. The questions were reasonably simple I think, just outside of my scope.
Typical stuff:
Access modifiers
Multi Threading
Value Types vs. Reference Types
Linq Questions
Inheritance
These are not terribly obscure things, I think they are fairly standard. The thing is that I have never had to use some of the things they wanted. Example: Access modifiers, I have never used internal, pretty much only public and private. Multi threading, I have always used the background worker as opposed to creating a thread by hand because that is the first example I found when I was looking. I have never had to use a ByVal vs a ByRef, and I have never used an abstract class, only interfaces.
So really it is an experience issue. I felt absolutely stupid as I sat answering questions from seven different people.
Now, let me say that this was possibly the nicest group of programmers I have ever sat down with, they were all extremely sympathetic about the whole situation. It just sucks to realize that what you know is a grain of sand and what you don't is an entire beach.
With that said, I want to make sure going foward that I can hit the interview questions since interviews never seem to figure out if you can code or not.
Cheers, --EA
|
|
|
|
|
Ok...
1) Yeah, access modifiers are considered "common knowledge". Public / private are the most common. Protected is pretty common too. Internal is useful in WPF (since you sometimes want to make stuff private and that won't work with data binding on occasions)... protected internal, well, IMHO, that’s *generally* used in code hacks.
2) Multi-threading - if you knew BackgroundWorker and thread synchronization techniques, I'd say that’s pretty good. Async CTP is another good thing to pick up. You might need to create threads by hand if you want to spin off say 10 background threads. You should probably know the differences between mutexes, semaphores and critical sections as that’s a basic interview question.
3) value vs. reference type, yeah, I guess you should know that.
4) LINQ... meh... that’s an obscure question IMHO... if you see code that uses LINQ everywhere, chances are they are constantly battling performance issues.
5) yeah, you should know inheritance so you are not c&p'ing code all the time.
|
|
|
|
|
Thanks for the insight, any other common things come to mind?
|
|
|
|
|
Depends what kind of job you are looking for. A front end / app developer doesn't need to know the same stuff as a back end guy who (sometimes) doesn't need to know the same as a networking guy. I'd kind of focus on your area of interest. If you like GUI, become a WPF stud, if you like web become an ASP.NET / Silverlight / HTML5 / Flash, etc. stud. Back-end is generally related to networking, so you'll need strong low level TCP skills.
One problem is, you'll get pigeon holed into either back-end or front end or web. I've never met anybody thats REALLY good at all three, so you really need to decide what you want to do. I think theres just too much breadth to be an expert in all three. You'd sort of be... whats that expression? "ok at everything / expert in nothing"?
Generally, if you have GUI on your resume, you'll get eliminated from non GUI work by most managers even if you can do it. They also generally won't hire non GUI people for GUI work.
Oh... you should also know design patterns... forgot about that one. Don't need to know all of them, but I'd know singleton, factory, lazy initialization, etc... just the basic ones as this is a popular interview question. If you are going for WPF, they probably want you to know MVVM, service locator, Dependency Inject / Inversion of Control. Some of the higher end WPF places will also want you to know MEF.
Like I said, depends on what are you want to focus on.
If you come across as a "general C# guy", you probably won't get too many offers in this job market because they'll assume you've just glossed over everything.
|
|
|
|
|
Hi, me again. What you listed there is exactly why I recommend a real book. Without studying a book, people tend to "get things done, create working code, possibly fiddle a bit, but get it in the end". And that is what interviewers typically don't want; you do need to understand the basics by getting them explained, one by one. There is a big difference between "I can write a C# program", and "I know C#". As a programmer, you would need both; you need the ability to get things done; you also need the ability to explain things to co-workers, to recognizing potential problems without compiling and running the code, etc. And that takes both studying and experience. You don't become a tennis pro by just playing tennis, you need training, coaching, etc.
Luc Pattyn [My Articles] Nil Volentibus Arduum
The quality and detail of your question reflects on the effectiveness of the help you are likely to get. Please use <PRE> tags for code snippets, they improve readability. CP Vanity has been updated to V2.3
|
|
|
|
|
Couldn't have put it better myself. They can be very harrowing experiences. A good technical interview should focus on your previous experience and drill down in those area's to determine your depth on knowledge.
"You get that on the big jobs."
|
|
|
|
|
The fact that someone is a good developer doesn't mean that they are any good at giving interviews. Nor does it mean they are capable in evaluating apptitude and/or knowledge in a candidate.
It doesn't even mean they are capable of judging what is needed to be successful in the post for which they are interviewing (even if they could ask the correct questions.)
Matter of fact it is often rather comical given that, by definition, they will likely hire an average programmer and are likely themselves to be an average programmer and yet I have never encountered anyone willing to state that they are looking for average candidates.
|
|
|
|
|
e-Course's don't help.
Back when I was starting out I thought I was just being ambushed in interviews but then as I got years under my belt I started to realize that doing things until they are second nature is about the only way to go. Previously, to this year I have designed and written maybe 20 Windows Services. This year, alone, I will likely double that. Sure it is straight forward but each one adds a little bit. It is so annoying to watch your service memory usage creep up because you declare a variable in a loop!
Write some code. Do some pet projects. Learn new languages. Do one task in four languages. Take small contracts that are appealing.
|
|
|
|
|
This is good advice. Write a small project, but use all the "proper stuff". If you expect to be an expert from reading a book, you'll be disappointed as a book tends to gloss over a lot of stuff without going into practical applications.
|
|
|
|
|
If you want to learn about multi threading, read Sacha Barber's articles here on CP. As for the other stuff, you probably won't get asked it again.
I am on the other side. I give interviews and what I like to do is give a typical, moderately tricky programming task. You have access to the internet and the question contains hints to what I expect to see. I want to see reasonably small and easily testable routines. They should have some basic input validation. If you want to use Linq, that's fine but if you aren't comfortable with it and write a routine that does the same, that's fine as well. No points are deducted because somebody isn't a Linq guru.
If you go as far as writing some unit tests, you'll get points as well. Finally, I expect you to be able to walk me through the code and explain what it does. More importantly, I want you to explain what you rejected. The purpose of this is that I only want someone who can think for themselves.
I will ask some technical questions, but the practical test is more important to me.
|
|
|
|
|
I like that, it is a good pragmtic approach. If the analytical mind and problem solving skills are the sword and shield of programming, then the internet is the codpiece.
Cheers, --EA
|
|
|
|
|
A good developer should be able to use all the tools available to them. If you don't know an answer, I would hope that you would know where to go to find out.
|
|
|
|
|
CP ! ! ! ! gimme codez. urgentz and life or deathz
Programming is a race between programmers trying to build bigger and better idiot proof programs, and the universe trying to build bigger and better idiots, so far... the universe is winning.
|
|
|
|
|
Perhaps an example of what kind of "moderately tricky programming task" you would assign would be helpful?  .
|
|
|
|
|
Towers of Hanoi... with only 2 towers.
EDIT: Whoops, changed from a rant icon to a joke icon.
|
|
|
|
|
Well, since you have your joke icon, I'll assume its a joke (especially with 2 towers)... but IMHO a "towers of hanoi" question sucks on an interview. The guy would waste too much time figuring out the "puzzle" aspect of it and not the programming aspect of it. Granted, you might like that the guy could solve puzzles, but...
I was once asked to write a shortest path algorithm during an interview... I knew that there was a well known & proven algorithm and I said to the interviewer "I would use the well known and proven one since not only is it mathematically proven to work, but its also the fastest" or something like that. He didn't like that I didn't have it memorized. You can't really memorize every common algorithm out there...
|
|
|
|
|
Sorry, tried to post last night but CP kept timing out on me. Anyway, I won't be posting my sample task otherwise I'd have to come up with a new one - there's no point giving potential candidates too much of a head start.
|
|
|
|
|
How old are you? I'm 50 and been contracting a bit lately. Never once got a job when interviewed by someone in there 30's. Never once Not got the job when interviewed by someone over 40.
Age is definitely an issue, you won’t get around that.
As far as the sharpening goes, just get up to speed with the new technologies. Working for in-house development teams can leave your skillset stale due to the fact they tend to be conservative places and not early adopters of technology.
At a .NET level I’d say focus on Xaml(WPF/Silverlight/WP7/MVVM) WCF, Entity Framework and Unit testing if you don’t already have these skills. If you are a web developer MVC is a no brainer.
"You get that on the big jobs."
modified on Wednesday, June 1, 2011 8:23 PM
|
|
|
|
|
private void Action(int ust_id)
{
MySqlCommand cmd = new MySqlCommand("Select * From kategoriler_tablo Where UstKategoriId=" + ust_id.ToString(), c);
c.Open();
MySqlDataReader r = cmd.ExecuteReader();
while (r.Read()) {
if (ust_id != 0) {
treeView1.Nodes.Find(ust_id.ToString(), true)(0).Nodes.Add(r("id").ToString(), r("KategoriAdi").ToString());
} else {
treeView1.Nodes.Add(r("id").ToString(), r("KategoriAdi").ToString());
}
Action(Convert.ToInt32(r("id")));
}
r.Close();
c.Close()
}
private void Button1_Click(System.Object sender, System.EventArgs e)
{
if (c.State != ConnectionState.Open) {
}
TreeView1.Nodes.Clear();
TreeView1.Update();
c.close();
Action(0);
}
This code does not work. I could not understand where the fault is
http://www.imageupload.org/?d=2E926FEF1[^]
|
|
|
|
|
I guess an earlier operation didn't close the connection. Find out where, and also check the state before opening and closing.
You may want to put the close in a finally.
|
|
|
|
|
It'd be easier to create a new connection in the Action method and wrapping it in a using directive; that way it'll always use it's own connection and it'll always close it when done.
Bastard Programmer from Hell 
|
|
|
|
|
Well as the error indicates the connection is still opened from a previous attempt or some other method.
Since you are not using any try/catch blocks the code could have failed at any point between the Open and Close calls thus leaving the connection open.
Make use of the using statement
using(SqlConnection conn = new SqlConnection("..."))
{
using(SqlCommand cmd = new SqlCommand("...", conn))
{
}
}
With this the connection and command will be disposed of regardless of whether a failure has occurred.
You should learn to program defensively also.
if(conn.State != ConnectionState.Open)
conn.Open();
And lastly, use parameterized queries rather than concatenate a string for the command.
I know the language. I've read a book. - _Madmatt
modified on Wednesday, June 1, 2011 9:34 AM
|
|
|
|
|
which should help me get the line?
|
|
|
|
|
What?????
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
