We Keep Coding

when choosing a project methodology such as xp, scrum, crystal which questions should be taken into consideration [closed]

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.
Basically I have to choose a project methodology.
The components are not big (we develop components mainly for SAP connecting), however the team is rather big , dislocated and and very unorganized.
Besides how big is the team
which other questions should be taken into consideration?
Thank you

I've made very good experiences with answering these questions first:
How does the team prioritize work?
(I would recommend putting todos into a sequence building a backlog)
How does the team track what needs to be done?
(I would recommend breaking things down step-by-step into User Stories and track them using a tool like PivotalTracker)
How can you make sure the team is self-organizing?
(Let the team pull work from the backlog, run daily status meetings and a retrospective every couple of weeks)
How can you optimize how fast features get delivered in optimal quality? (This way of thinking should replace the idea of maximizing capacity utilization)
How can you make the work visible? (Visibility builds trust and momentum - you can start collecting metrics and putting up a screen showing all kinds of graphs)

One very useful question to assist in choosing any sort of method is "What projects can this not help me with?" It can be very difficult to obtain an answer; the usual way that supporters of a particular method respond is "of course method X can help you with any project." Thus they are saying either that all projects are the same, which is obviously not the case; or that they don't know what are the limitations of their method, and so will not be able to recognise when their method is not appropriate.
You say your teams are fairly unorganised. One of the best ways of introducing any new method is to provide tools - even very basic tools - that make it easier to follow the standards than not. An example of this was trying to improve the quality of development reports in a very large organisation - we provided a number of word processing templates, that made it easier to write a report using the templates (and hence the standards) than to write the report from scratch.
Personal note on my choice of language: I have worked with software development methods for many years, and to me "methodology" is the study and comparison of different methods. A particular way of, for example, managing a project, is a method, not a methodology.

I guess this really depends on a number of factors, for instance some contracts require you to use PRINCE project management which is rather complex.
If you dont have any external factors regarding the methodology you choose I would just do a bit of research and see which you think fits your team best.
I havent had chance to use Agile yet although I took a course on it and I liked what I heard, it seemed fairly straightforward which is a bonus.
One thing to remember though is you dont have to stick to one methodology if you find something isnt working for you then make changes.
Questions I would consider though would be the length of the project, Size of the team, Are the team each working on individual parts of the project or are there multiple people working on the same area, Time it will take to implement a methodology, Any costs involved?, Any training involved?

Expert in one language or know more languages [closed]

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 12 years ago.
In the corporate world, Is it better to be knowledgeable(by knowledgeable I mean not a expert or novice but with some coding experience) about multiple languages.
or
is it better to be an expert in one language(say c++ or java) but having just basic knowledge on others.
I ask this question because what I feel is languages can be differentiated based on the features they provide like Garbage collection etc..but this can be implemented in other languages...and why do people prefer one language over the other?
What is the general point of view on this board?

I'd say learn a couple of languages really well, but keep expanding your knowledge by studying other languages. Not for the languages themselves necessarily, but for the concepts and paradigms they implement and encourage. This'll make you a better programmer overall and better suited for finding the right tool for a larger set of problems.

I think it is more important to be able to learn new technologies, languages, paradigms, etc. etc. on the fly than to be an all out expert in just one of them. You can dedicate all your time, effort, blood, sweat, and tears to learning Java, but what are you going to do in the eventuality that it is no longer in wide spread use. This can happen to any language to be perfectly honest. Your base knowledge in the general principles of programming and programming practices and your WILLINGNESS to learn a new language are what will help you to advance in a corporate environment. If your boss comes to you and says "I need this done in C" and you reply either "I don't know C nor do I like it. How about Java or Python?" or "Sure, but C is not really suited for that task and will take additional effort. How about Java or Python?", that will be remembered next time layoffs or promotions come along.

be an expert in one language like C++ then if you want to be very good in PHP it would take you ~3-5 weeks instead of 3-5 years (C++), next - if you want to be very good in C# that will take you another 3-5 weeks, and after that you can learn everything else, like .NET/ASP/J#/VB/ very fast. i find it that only ASM is harder to learn, might take more time - 2-3 months, if you have the right books.
everything depends on passion / how much hours a day you read/write/test code...
but if you want to be an expert in any of these languages, experience is what you need, learning is not enough.
IMO - You must be Master of one, in order to have the capacity to learn multiple languages faster. so "Jack of all trades" but also Master of ONE.

Learn what you need
why learn ten languages if your only every going to use two? though you should still know what else is available, and what its good points are (and its bad points too), so if in the future you run into a problem you can't solve with what you know, you know where to look for something that can help.
If your looking for a job, it might help to know more languages, as it 'inflates' your CV, but being a jack of all trades probably won't get you hired.

Read this: http://www.paulgraham.com/avg.html It is not exactly what you wanted, but can give you another point of view.

One famous man said: "Person becomes real software development specialist only when he or she becomes an expert in more than one programming language".
So if you want to be a good programmer in Java or C learn Java or C deeply and completely.
If you want to become high qualified software developer not dependent on language and ready for changes in programming world - learn both of them and better not only them! :)

First expert in one one language. Then know more languages. (Pick a language per paradigm)

I believe it depends on your career aspirations. If you're looking long-term at being a consultant or maybe evening being an indepedent analyst, becoming and expert in your technology area is critical. You'll need to focus a lot of time mastering technology in your given area, and you don't have the spare time to become e generalist unless you choose not to sleep. I don't recommend that for the long-run.
Then again I cannot recall how many times I've seen an organization dump a perfectly good code base just to upgrade to the "next-thing" due to the career aspirations of project managers. So maybe it is out of our control?
In the end, I honestly feel that domain-critical knowledge is more important than technology skills. But that is maybe because I'm not only the front lines these days. I'm all for a general lemma that says you should know more than one programming language, but I seriously question those who claim to proficient in ten languages and ten frameworks and ten different operating systems.

Simple VB or C# questions for an interview? [closed]

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.
I'm conducting an interview in 45 min (my second ever!) for a candidate who's pretty junior and states she knows VB and C#. I do not have any experience in either of those languages.
Does anyone have any good simple interview questions for these languages that I can ask that will be informative without being too intimidating?
Note: I'm looking for language-specific ones, and not of the FizzBuzz variety (which I'm already planning on asking).
Related Question
https://stackoverflow.com/questions/70763/good-c-interview-questions-for-a-senior-dev-position
UPDATE: It's over - and thanks everyone! As Jon Skeet says - it's hard to ask questions to which you don't know the answers but I did find that her reaction to the question being asked, even without the answer, was pretty telling and showed me immediately whether or not she was familiar with the concepts being presented.

The problem with asking language-specific questions for a language you don't know yourself is that if any of the answers deviate from the specific ones you've been given here, you won't know if they're right or not. (I humbly suggest that most of the answers given so far suffer from that problem.)
Do you have a laptop available, so you can get them to code and see whether the result is the desired output? If so, FizzBuzz-style questions are a good start, and while you won't be able to judge the idiomatic style of the code you can at least see if it works :)
I find that a useful question to ask is what the candidate likes and dislikes about the language. What would they change if they could?

There are numerous lists on the web.
The C# ones one Mark Wagner's blog are quite good and range from the fairly simple to quite hard so you can go as deep as you like. However, as the commentators have pointed out some of them are in danger of becoming out date (if they're not already) - so use them as a guide.

Look here, maybe you can pick up something not too senior:
Questions every good .NET developer should be able to answer?
Good C# Interview Questions for a Senior Dev Position

I'm no expert on interviewing, so please take this as an opinion rather than gospel.
I'd ask the interviewee to bring in a hundred lines or so of code they've written in each language that accomplishes something interesting. In the interview, let them know what languages you do know, and ask them to review their code with you. Even without knowing the language you should be able to ask questions about various design decisions and determine whether the interviewee is actually comfortable with the language.

I think it is far more important to find out how the candidate thinks than to test their specific knowledge on a topic. For example, they may know C# but do they have the aptitude to learn VB.NET, or F#, or some other language. What makes them tick? Do they get excited by new framework features? What do they do for hobbies? How do they tackle problems? These things are far more important than knowing a language inside and out, especially when even the best developers still rely on the compiler to tell them they screwed up.

Its very dificult to answer your question, because we can list thousands of questions. However here is my abstract idea:
Test whether he knows all OOPs concepts and how it can be acheived in C#/VB.Net
Avoid critical questions as they are juniors.
Test them whether they can differntiate .Net languages from other HLL
Explain some .Net features and ask how they will achive them using C#/VB.Net
(ex: Reflection, Genrics, property)
Make sure that they can very-well pick-up if they given chance to work.

How about asking which strengths and weaknesses do she sees in each language? What would make one more appropriate than the other?
Note that while one could say that she isn't so familiar as to know an answer, that in itself can be a fine answer. Part of what you are wanting to see is their ability to communicate either technical arguments for or against something or an ability to say, "Well, I don't have enough experience to give a thorough answer on this."

I usually interview people for c# developer role. I have found questions at the following URL very helpful for Junior, Mid and Senior developers. You can find a variety of c# interview questions segregated by topic. Here is the URL C# Interview Questions

Why do interviewers ask advanced questions? [closed]

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.

Improve proficiency in programming [closed]

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.