Interview question - c# [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 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 develop开发者_如何学JAVAer 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.