It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
I have a first job interview for a software engineer position but in the email they state that I will have to write out a program at the interview stage. Does everyone do this?
What kind of program might it be for a graduate?
The job is for a .NET developer, but I can use any language, so I will stick with C#. I'm actually S**Ting it; I have no clue what they are going to ask me to do.
Many companies will spend much of the interview time asking candidates to write actual code (usually on a whiteboard or piece of paper though sometimes on a real computer) as this is a great way to see if they will be successful in the job. Some things to keep in mind:
Talk out loud. Often interviewers care about your thought process and approach to the problem as much or more than they care about the actual code you write.
Ask questions. Interviewers will often intentionally make a problem ambiguous just to see if you'll notice and seek clarification. Ask things like: "Who is the audience?" "Should I include exception handling?" "Shall I optimize for performance or just make sure it works?"
Don't get flustered if you're struggling. Tell the interview what you're thinking and they'll often point you in the right direction. Partial credit counts.
Get a good night's sleep before your interview. Lots of whiteboard coding and related discussion can be surprisingly grueling.
Good interviewers will be able to extract what you've learned over the course of your lifetime, so don't worry too much about last minute study sessions. It's too late. That said, it's not a bad idea to brush up on basic language syntax and core data structures and algorithms.
Here are some sample problems you may want to practice writing out on paper:
Write a function to calculate the nth number in the Fibonacci sequence.
Write a function to sort 2 arrays of numbers (without using existing libraries).
Design a Deck class and a Card class and write a function to shuffle a deck of cards.
Design a Circle class and write a function to determine if 2 circles intersect.
Design a LinkedList class and write a function to reverse the elements in the list.
At least be able to do this FizzBuzz
By the time the interview is scheduled, there's probably not too much you can do in the order of preparation.
Just remember, they want to know about your problem solving process. Just try to think out loud as much as possible and if you truly don't know something just say so.
No matter what type of question they ask, just go with the flow and do your best on it. The last thing any interviewer wants to see is someone who gets flustered or upset due to a particular question. I'll be the first to admit that some of the questions asked in an interview may be lame and unnecessary, but you are trying to get a job from these people and you will just have to humor them.
When you have more time to study, you should probably start looking at Questions every good .NET developer should be able to answer.
We issue programming tests all the time. There are many reasons for doing this, over and above the obvious one of testing coding ability. We look for
a) Coding style
b) Ability to develop and implement algorithms
c) Ability to follow instructions
d) Ability to communicate what has been done
But by far and away the most valuable thing about a programming test is discussing with the candidate why they did what they did. In this discussion it becomes obvious rather quickly how much the candidate really understood the test and their own design and implementation. It also roots out plagiarism very quickly.
Usually software development jobs give simple tests. I've never once interviewed for a job that required any more than a simple implementation of a function.
Her'es a few simple tests I know of:
FizzBuzz: http://www.geekschool.org/programming/fizzbuzz/
For a job at MS, I was asked to write a function to reverse the words in a string.
At a different job, I was asked to write an implementation of the Join function in c++.
A friend of mine got this one for game development: Write a function to test simple rectangle collision
More than likely it's something simple like FizzBuzz, just meant to weed out the totally unqualified people.
If the company don't ask for you to write code in the interview, that's really, really bad. Go for another company.
The type of test depends. I've done test that i had to write small C code, with pointers or recursive functions.
But generally, they ask for a basic asp.net application (I'm also C# developer), like just one form, inserting and reading from the DB.
Related
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
I want to implement another debugger (language) for .NET (it's just for academic reason, so that it can implement just a part of a language). I myself like to implement NS2 (network Simlator 2) script for .NET in which anybody can write ns2 script and debug it with .NET
I read this article in stackoverflow and it is far from what I'm looking for.
Here is the requirement
have some predefined keywords (e.g: for, while, if ...)
check the correct form of the statements (e.g: for(start;end;counter){commands} ...)
diffferent colour for different types of statements
ability to add to any IDE (e.g: implementatin like add-in or as a dll or ...(I have no idea))
many other thing that is not necessary for now
How can I do this?
Update : I'm not sure that you got my point, take a look at this, it is very close to what I am looking for.
It will not be an easy task. However: The Dragon Book is probably a good place to start (assuming you've got sufficient computer science background for a compiler theory book to make much sense to you). Compiler Construction: Principles and Practice is also a good text.
You'll want to compile to CIL (common intermediary language). This handy wiki article outlines the CIL instruction set. Debugging your intermediate code against the CLR... well, that's where the StackOverflow article you've linked will come in handy =)
That'll cover your first two bullets (and consume a big chunk of your life).
The next two are different issues, but the easiest way to 'make it go' would probably be to define a syntax for an existing text editor, and set up a macro in the program to call your compiler. I'd recommend TextPad, though I'm sure opinions on a configurable general-purpose text editor will vary among the community ;)
Designing a full IDE with all of the features you've come to know and love in your environment could be quite a task ... or you could try to build an eclipse plugin. Personally (assuming you can design your language and learn something from it), I'd just stick with syntax highlighting in TextPad.
There is more and more interest in this area and in fact there is an active project by Microsoft Research that is looking at this on building a common infrastructure to build compiler (and debugger) for custom languages targetting .NET
http://cciast.codeplex.com/
I have used the infrastructure myself but not an expert in compiler technology. Hope this gives you a good starting point and you may find the discussion forum useful to share idea with like minded people.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 12 years ago.
I want to create an encryption software , I want to know can hacker find a password for a encrypted file ?
The short answer is : If there's a reward that's worth it then someone with enough resources can crack it.
Do not create your own algorithm. I repeat do not create your own.
Use an existing library. Many many millions have gone into getting this has difficult to break as possible and unless you have a educational interest in learning how to create them I would strongly urge you to reconsider and use an off the shelf package.
Chances are any algo you come up will be easily broken as crackers have many advanced tools to hand.
I repeat do not create your own.
Please see this question for more info. What techniques do you use when writing your own cryptography methods?
Since you are using C#, probably yes. Anybody can look at a .NET app's source code through Reflector. Using that, one can reverse engineer your encryption algorithm.
If ever you are going to use other languages, lets say some which are not easy to decompile. Decent crackers can debug your program and look into how the encryption is done, through debugging. So, the answer is still Yes.
If you're gonna use C#, or any .NET language, obfuscate your code using an obfuscator.
Yes. He can:
guess it
see it written down somewhere
ask the user for it
discover it by analysing the behaviour of the algorithm
convince the user to change the password to one he knows
You need to design your software and the way it's used to make these as hard as possible. Not all of the above can be solved in software.
Erm... Well... What do you want to know? HOW a hacker can find a password or IF a hacker can find a password. Considering this, make yourself clear and rephrase your question.
First, check out what encryption actually means. There are a lot of possibilities to encrpyt a {file, string, data, whatever}. An important question is: when does your data become invalid? If it is of no use anymore after one week then you do not need a strong encryption, maybe you can write something from scratch. If it still must be encrypted (undecrypted, unhacked) after like two years, you should use an encryption technique like RSA which has its foundation in mathematics and thus has been proven to be unhackable in a time that could give a hacker an advantage by having access to your data.
My answer is based on these two facts: unless the cracker has access to a network of thousands of hosts or a quantum computer, RSA should do the trick.
Peace
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 11 years ago.
I was tasked to conduct my first interview and would like to pose my question to this world for both their feedback on my question and also on their solutions.
Question:
I have a legacy system with users and
files, the info of all files
pertaining to a user are stored on a
flat file.
I want to upgrade this system by
storing all info on a db, design
tables, and create a C# system that
will populate the new db as well as
ftp the files to a new path.
Define the desgin consideration and
develop a prototype.
Note: We are looking more for what
design one would use and why rather
than code that compiles. If it does
then kudos to you and we will give it
more weight.
#Tim C,
I did show the interviewee the file:
User1234.txt
UserID=1234
ParentPath=\\somewhere\nowehere\everywhere\1234
FileCount=20
File0=something0.ext
..
File19=something19.ext
#Tim C, I have never conducted an interview and I followed a script given to me by my senior developer who was absent.
I think a strong candidate would spend the bulk of an interview asking more detailed questions to gather appropriate requirements before jumping into design.
A good candidate wouldn't start making assumptions about your requirements, at least not without identifying those assumptions.
There is another post here on SO that has some good info on C# questions...
I personally don't like the question as you've written it. You provide information that a good developer should be able to determine via requirements rather than the design being presented. I may word the question like this...
We have a legacy system that was built in classic ASP that uses flat files for storing user information. In addition to the storing of user information in flat files, the system also handles uploading new files via FTP processes and then adds the path to the user's flat file so they can see it. If you were to design a system to replace this today, what would be some key design considerations come to mind? How would you store the data?
Its not that its a bad question, I just think its too broad to reveal anything about a good candidate. What kind of information do you hope to get out of it? Whether the candidate comes up with a correct solution? A novel one? A practical one? Top-down? Bottom-up? A solution that uses a particular tool? A solution that works in this particular case? A solution that works for many general cases?
I think questions with concrete answers, or at least a narrower range of acceptable answers, makes for a better solution, so I would recommend a different set of questions for your interview.
Well, in my opinion such a question would leave out people with rather practical point of view on designs.
There are people who prefer top-down solutions, designing from the general things down to concrete ones. There are as well quite a lot of developers who design bottom-up, first making small subroutines and then combining them into a big project. Your test will favour the first type of developers to the second one. Therefore I would say it would be biased.
I'm guessing this is more a "What are your thought processes in solving problem X" type of question rather than "Do you know specific fact Y". We use a question about modelling a deck of playing cards and then go on to ask how this would help create a game to play snap/21/poker with them.
With this type of leading question you need to know where you want to lead the candidate. You should have a solid understanding of at least one complete design and make suggestions to help move the candidate along those lines should they get stuck. Good candidates will cover all the points you want to mention and will no doubt surprise you with approaches you hadn't considered before. These are definately the type of people you want to hire. Others may stumble at first but hit their stride with a few pointers. The trick is to get the right pointers without giving too much away. These candidates aren't a definate No but they would need to be a good fit in other aspects or going for more junior positions. You'll also find some candidates never 'get it' but your phone screen should keep these to a minimum. Of course you don't hire them unless some form of nepotism is going to help in your next review!
We spent several months interviewing candidates and evolving the interview process and still haven't arrived at a something we're 100% happy with. Joel's book Smart & Gets Things Done has been an excellent resource to help us.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 13 years ago.
Please can anyone one point me to a good tutorial that helps me to make my code fast and light.
I'm interested to know which Method is faster and when to use a method instead of other...
And how to evaluate if a code is good or bad?
My programming language is C#.
Hi all,
Thanks for your replies, they are very helpful.
I'm editing my question to be more specific specially that optimization is unlimited.
I want to know what is the best method in each condition.
For example using StringBuilder is better than string if i am appending lines to a string...
I only need this simple things.
Be aware of sub optimization.
Even though one specific function is faster than another replacing this isn't necessarily gonna make any difference in the runtime of your application. You need to understand which parts of your code that actually is a potential problem, and focus on optimizing these parts. Be aware of the O notation of your functions, and how often they are called. To identify parts that needs optimization a profiler can be of good help.
This question has some interesting points on why you shouldn't optimize until there is actually a need to do so.
Sure. Here's what we do:
Begin the journey by deciding when the journey is over. Set meaningful, customer-focussed, realistic performance goals. (For both speed and resource consumption.)
Carefully test your code frequently to see if you are meeting your performance targets.
If you are meeting your performance targets, don't worry about performance. Things are fine. Worry about bugs, or robustness, or features.
If you are not meeting your performance targets, run a profiler. Use it to identify what is the worst offending code. It only makes sense to fix the worst code; making something that is already incredibly fast and light slightly faster and lighter does not solve your performance problem.
Rewrite the slow code so that it's more performant. (This is the hard bit.) Make sure you test it to make sure it really is better.
If despite your best efforts you cannot make it good enough, either re-evaluate what your goals are, or cancel the project and spend your time on something that you can be successful at.
Keep iterating on that until you ship something.
Basically implement first, then test where to optimize.
If you are using Visual Studio Profissional you can use Analyze -> Launch Performance Wizard to analyze method performance. I am not sure about whether the other versions support this feature, however, there are also some commercial/free applications around ... look for profiler (see here for a list).
Type REALLY fast.
You should look at hidden features of c#, this post covers the most best practises in c# development
You can get a ton on advice of on this. But be aware of :
Premature optimization is root of all evil.
Aim first for correctness, next for clarity and only then performance.
As the old saying goes,
"No one cares how quickly you can calculate the wrong answer"
(on a practical level though, use a profiler)
If one method was always faster than another, they wouldn't bother including the slower one.
The only invariant when it comes to performance is that you need to profile. Everything follows from that.
If you get yourself a profiler, it will help you along, some will even give you great tips.
Example: ANTS Profiler
Usually you will find that reducing the number of times you create Strings to be the main performance boost you can get.
That and not messing with the Garbage Collector manually (unless you really really know what you're doing)
This link for Java design patterns is way too involved, don't get too put off by the word Java there, you can use what they teach for development in any language.
The thing is, if you want to know when to do what and what methods to use and so on, design patterns is what you are talking about.
I wish someone had pointed this to me earlier in my career.
In terms of general advice:
Try to use the fewest loops necessary
Move code out of loops where possible
Avoid copying things (like strings) in loops
Avoid creating objects in loops
Cache where warranted (generally small objects that take a lot of time to make), but make sure your cache has a good disposal policy or it turns into a memory leak
You can compile your program in native mode to improve the runtime performance.
One of the ways of figuring this out yourself is having a console app where you try running discrete pieces of code against each other and timing them. Like here.
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.