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.
First of all, sorry, but my English is not very good.
I'm at the third semester at a programming course and I can't "get it".
I passed previous exams because I've studied three times the amount my colleagues did. And, now in my Data Structures class when the professor asks us to make list algorithms ( for example ), my colleagues just start to write the code while me ( or would be "I"? ), even after seeing it done, can't understand.
I find it so hard it's painful. It takes me 1 hour to understand simple algorithms.
So the question is: can anyone recommend me books or something, that will help me think more like a programmer? I mean, "normal" people, after a given problem, seem to immediately make the picture in their head and star to write the code.
you might want to take a philosophy class on intro to logic. it's exactly the same thing as you're doing with computers, but in a different context.
I think there are two ways to learn to write algorithms:
1. Try it yourself (and then review it with the "right" answer). Of course you should start with the simple ones.
2. Implement other's algorithms (to code). Going from algorithms to code and the other way around gives you a great "feeling" of how algorithms are created.
But the best advice I can give you (which you can use the two ways above to acquire) - try being very good at some algorithms.
If you could remember, write and really understand even just a few basic algorithms - you're on the right way.
Anyways, I think learning algorithms is mainly practice and less "abstract knowledge", so get ready to get your hands dirty..
Best of luck!!
I found that the most important skill for mastering data structures is to "visualize" them. If you have no clear picture of your data structure, everything stays fuzzy and vague. E.g. take a stack (single linked list). It may help to visualize it as a stack of plates or people in a polonaise (everyone has the hands on the shoulders of the person in front of him).
Or a double linked list: Imagine a row of people grabbing the belt of the left and right neighbor. Now you can imagine what you must do to remove one person: Its left neighbor needs to grab the belt of the right neighbor and the right neighbor the one of the left neighbor. Then you can "delete" that person (or the garbage collector does this for you in Java etc)
The second important skill is to understand recursion. You need always a base case, usually involving an empty list or empty node. When you follow the algorithm in the recursive method, check that it is correct, but don't follow recursive calls inside that method. That will drive you mad and lead to nothing. Just assume that recursive calls always "do the right thing". If your current method is correct and the base case as well, you are done. Once you understood this, you understand recursion.
If it helps, you might want to try books in your native language. If there is any gap in your understanding that comes from your English comprehension, that would add additional difficulty for you.
Second, an algorithm, is just a list of steps for achieving something. Try to focus on something simple like sorting algorithms, they are fun and easy to learn. Hope that helps.
I do not know how far this problem is concerned, but it might help.
Algorithms and data structures are way cleaner for me if I think of them just as informal ideas/boxes/shapes/forms/connections/... instead of abstract things.
That is, everytime I come across a new data structure I try to visualize it somehow in order to actually beeing able to "see" what the single operations do with the structure.
I had also sometimes the problem that I didn't actually know instantly how to solve something algorithmically, so I just went ahead and started drawing.
Let's take - as an example - the problem of converting a binary tree into a list. So, I draw a tree (of arbitrary size and holding arbitrary elements, but beeing a "good" example). Then I think how I would convert the tree into a list manually:
1
2 3
4 5 6 7
So I think: I want to have the result [4,2,5,1,6,3,7]. How can I do this step-by-step?
Ok, first of all, I find the leftmost element (4); how can I do this? Ok, I start just by the root and go left until there's nothing more. Then I remove this element and go on with the remaining tree:
1
2 3
. 5 6 7
Ok, now I would pick the 2. How can I reach the 2? Ok, I can either start again at the root and go left until there's nothing more or i just go back from the deleted node.
Then I go on and look for recurring patterns, how one can generalize steps etc.
The outcome is, it might often be helpful to have a visual representation of what the algorithm is doing and then you can implement it.
I think it is a good practice to use diagrams before implementing anything. You can make diagrams or write a pseudo code, they are helpful before you start to design or implement the actual code.
I had a similar problem when I was first introduced to programming languages. I missed a lot of lectures because it was my first year of college! For me there was no books or lecturers that I found that knew how to help you think like a programmer. I always found the people teaching didn't know how 'not' to think like a programmer anymore and as a result they assume you know the simple concepts. So finally by the end of my first year I had to cram majorly to catch up and and had to fill in the gaps myself...! This is how I think about programming problems now:
OBJECTS: For Object-Oriented programming objects are the key to the whole thing. If you think about what it is your program needs to be able to do then you can break up the program into smaller chunks. For example, if you imagine making a cup of tea, the objects you need to make the cup of tea are:
1 -> A cup
2 -> A tea bag
3 -> Water
4 -> A kettle
5 -> A spoon
6 -> Milk
7 -> Sugar
So now your program has 7 objects which will interact in some way to make a cup of tea. Objects are always declared as their own class and will have constructor methods which when called will create a copy (instantiation) of your object that can then be used in your program. All of the method that are inside your class will define what functionality your object can provide.
Kettle kettle = new Kettle();
kettle.boilWater();
So now that you have your objects you should think about your algorithm.
ALGORITHMS: In all programming languages an algorithm is basically just a list of steps that you take that will help you achieve your end goal. In our case our end goal is to make a cup of tea.
The steps you will take in your algorithm have to come one after the other in a logical fashion i.e. You cannot pour the milk into the kettle, or pour cold water into the cup and boil the sugar etc.
So our algorithm can be as follows:
Step 1: Pour water into Kettle
Step 2: Turn kettle on - to boil the water
Step 3: Put tea-bag into cup
Step 4: "IF" water is boiled -> pour into cup
"ELSE" wait until water has boiled
Step 5: Stir teabag with spoon
Step 6: Pour milk into cup
Step 7: Put sugar into cup
Step 8: Stir
There are always a few different ways you can arrange the steps in an algorithms that will still work but always remember to have a logical order or else you will make a mess!!
The same principle can be applied to even the most complex problems. The most important thing to do is try to break the problem down into the simplest steps and arrange the steps in a common sense way.
When it comes to more complex tasks it is obviously very important to know what tools you have available to you i.e. know what functionality APIs provide you with and be familiar with the syntax. But as people have mentioned to you already before practice makes perfect. It is the only way that you will begin to understand it and believe me you will get it eventually... One day it WILL all make sense to you it is just about thinking a certain way. Break everything down to small simple steps and then order the steps in a logical way. Do this and it will start to make sense to you. I PROMISE!!
If you want to jump in the deep end and are willing to work hard, there is "Structure and Interpretation of Computer Programs". It is out of print but available on the net.
It goes deep into conceptual thinking processes behind programming and converting them to code. It uses scheme, but the principles are applicable everywhere and it is great training for flexing the abstraction muscles.
Don't do it in one go... take your time with it, come back regularly to it, and have fun!
Try to think about how you approach everyday cognitive problems, and formalize the steps you take to solve them, on paper.
For example, if you've ever had to reorder a deck of 52 jumbled cards, you probably know Insertion sort or some variant of Merge Sort already. If you're asked to sort five 2-digit numbers in your head, you're probably using Selection Sort. If you've had to find a specific card from a jumbled deck, you probably used Linear Search. If you've ever seen the 'High Low Game' on 'The Price is Right', you probably know Binary Search. If you're asked to solve the 8-Queens problem as a 'puzzle', you will almost certainly use the classic backtracking technique.
Don't let jargon like 'loop invariant' or 'asymptotic time complexity' intimidate you straight away. Think about how an algorithm is dealing with the problem, and you will find yourself 'rediscovering' these terms yourself when you want to reason about its correctness or efficiency.
I'd suggest you could try out some of the websites which contain a number of algorithmic problems to solve. Usually you could find a number of very easy problems to start with, and forums to discuss them. Then it's up to you and how much time you spend on them. Just try to go into as much detail as possible and question yourself what exactly is it that you don't understand, then how could you figure that out (maybe someone already had figured that out and you just need to find the answer). For the easiest problems Google is more than enough to find the answers you're looking for.
And here is the list of websites you could try:
uva.onlinejudge.org - Huge list of problems related to different algorithms.
www.topcoder.com/tc - Live competitions and lots of tutorials to get started.
www.algorithmist.com - Constains a list of links collected over time by problem-solvers.
Related
I am currently a freshmen in college doing some self-studying about the different sorting algorithms.
My studying source does provide the codes and I did some practice on it (coding the sorting base on the concept it). At the moment, I can provide selection sort with just a little bit of trouble (coding that is).
Am I required to memorize the codes? I know the difference between the sorts and the concept behind it. Do I need to memorize the Pseudocodes behind it as well? Will interviewers ever ask you to produce the codes on the spot?
There is no need to memorize the exact code syntax , but it would be important to understand the logic behind the sorting algorithms (ie. be able to explain using pseduocode).
I've been asked in interview how to do some basic sorting algorithms like a bubble sort, but nothing very complex. I was not required to write the exact "code" in any particular language, but just prove that i know the logic and can explain how it works.
Hello and welcome on Stack Overflow. I'm answering your post below, even though it will be closed as too broad or primarly opinion-based, because this QA site is oriented towards coding questions. You might want to ask this on another QA site, like programmers stackexchange.
Do I need to memorize the Pseudocodes behind it as well?
not really, as in every decent language you'll have a standard library that offers you state of the art implementations, and what you really need to remember is the complexity and mechanism of each sort algorithm, to choose the best fit for your dataset, when you need it.
And otherwise, when you really need to dig again in the pseudocodes, there are books (like the Art of Computer Programming by Donald Knuth), and wikipedia, and many other resources online.
Will interviewers ever ask you to produce the codes on the spot?
Yes they will. It happened to me at least five times. But most of the time, they'll understand that you might not remember the full pseudocode on the spot, but they expect you to know the mechanism and complexity, and be able to reinvent the algorithm on the spot.
Though, when you do interviews, you're usually compared to other people passing the same interview, and between two candidates that passes, they'll choose the one that did the best on the tests… And then you might loose a job opportunity because someone else remembered better those algorithms.
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 5 years ago.
Improve this question
When giving a time estimate for a project that includes work in areas you don't have experience with how do you estimate?
In most cases it is hard enough to get the estimate right when the project's areas are familiar.
What methods have you used in these cases? How well did they work?
Not Serious...
Reach your hand up in the air.
Grab an estimate.
Write down what you find.
Ok, ok...
It's hard. Actually, it is not possible to give an accurate estimate of something that is not known. But that doesn't stop people from needing to know.
Write down a list of all functional components or aspects that you are aware of.
Be as vague as necessary to cover everything.
Now, you have a list of components. For each component, do your best to get the business and/or functional requirements of that part. Why is it there? What is it supposed to do? Why? How? Drill down to more detail, add as many items to your list as possible (nested, components, sub-components).
The more items you have the easier it is to estimate each one.
Then double it!
I think it is very reasonable to walk the stakeholders through some level of design in order to provide an estimate. Otherwise, it's like walking up to a construction company and saying "I want a house, how much will it cost?"
And keep in mind -- it is an estimate :)
Oh, one last thing... Be clear about what it is that you are estimating. If it is "a, b, c" and they later ask for "d", it will be easy to point out that your estimate did not cover "d"... your new estimate is ...
Know what you Know AND Know what you don't Know and you'll be successful.
Use a work breakdown structure (WBS) to get the sub parts of the project/application/whatever. You can provide an est. (to a degree) of the effort to get the knowns complete, as with any project there are the unknowns - identifying them is the first big step. The best next step is to add to the WBS steps to better know those unknowns, for example, if the task is to go BBQ a cheese burger with strips of bacon and you've never BBQ'd bacon before - then you break the job down to getting the ingredients, getting the BBQ, starting the BBQ, etc. and the one thing you don't know - getting/cooking bacon you add some sub-components like:
call butcher
research bacon cooking
hire bacon BBQ'er expert
etc. - each of those you can assign some est. to and put a ? near the actual cooking. Call it a proof of concept (can you bbq bacon?), research and development, whatever - but there are somethings when you start a project you don't know, but you can devise a plan to better know those areas AND once you do revisit the plan and add the findings. By doing this you're communicating out to the team, sponsors, etc. what you know, those areas you don't know but have a plan to get to know, and a rough est. with the unknowns identified.
MinMaxLikely is the method I use. The minimum for the case where everything goes well, the maximum for everything going pear-shaped, and the likely somewhere in between.
Of course, management only ever looks at the minimum figure but, by the time they start complaining about cost over-runs and missed deliverables, you've already got them locked in and you have been (hopefully) keeping the fully appraised of any problems you've encountered and the effect those problems are having (pushing the actuals away from Min and closer to Max).
Have you tried planning poker?
These SO questions might be relevant:
How to estimate the length of a programming task
Dealing with awful estimates
The most significant project management mistakes
Do you practice the planning game?
You cannot estimate these, you can only guess. The difference, to me, is that an estimate is based on knowledge & experience, and you have neither for the unknown.
You have to constantly reevaluate where you started, where you stand, and your guess on what's left. You could probably break down your problem into steps but your biggest issue will be in the "footnotes" of what you're learning.
The example that comes to mind was my first C# interop with Word. It was entirely unknown and I didn't have the foggiest clue what it would take to generate a 1000 page formatted document based on database information. It, in itself, is pretty straight-forward: open Word, format page, and insert data. There are all kinds of issues that cropped up that you couldn't fathom and that easily doubles your guess.
Ask people who are familar with the concepts how long it would have taken them back when they first learnt the technique (including how long to learn). Average the results and adjust based on your capability to learn.
Then guess anyway and triple the quote. Doubling is for chumps.
Wherever possible, go one meta-level up: give an estimate of when you can give reasonably accurate estimate.
"I don't know enough about Foo to give an accurate estimate, but I will know enough about Foo by Thursday week."
I acknowledge it often isn't possible, but I try to make it an option when I am project managing.
You can even go up another meta-level, in large projects.
"I don't know how long it will take for us to get a expert in to give us an estimate. I will talk with my colleagues, and give you an estimate on Friday of how long it will take to get an expert estimate."
This can be combined with large error margins, diminishing rapidly. "It will take 1 year, +/- 9 months. I'll give you another estimate with an error range +/- 3 months by June 30."
When faced with a problem in software I usually see a solution right away. Of course, what I see is usually somewhat off, and I always need to sit down and design (admittedly, I usually don't design enough), but I get a certain intuition right away.
My problem is I don't get that same intuition when it comes to advanced algorithms. I feel much more up to the task of building another Facebook then building another Google search, or a Music Genom project. It's probably because I've been building software for quite some time, but I have little experience with composing algorithms.
I would like the community's advice on what to read and what projects to undertake to be better at composing algorithms.
(This question has nothing to do with Algorithmic composition. Well, almost nothing)
+1 To whoever said experience is the best teacher.
There are several online portals which have a lot of programming problems, that you can submit your own solutions to, and get an automated pass/fail indication.
http://www.spoj.pl/
http://uva.onlinejudge.org/
http://www.topcoder.com/tc
http://code.google.com/codejam/contests.html
http://projecteuler.net/
https://codeforces.com
https://leetcode.com
The USACO training site is the training program that all USA computing olympiad participants go through. It goes step by step, introducing more and more complex algorithms as you go.
You might find it helpful to perform algorithms physically. For example, when you're studying sorting algorithms, practice doing each one with a deck of cards. That will activate different parts of your brain than reading or programming alone will.
Steve Yegge referred to "The Algorithm Design Manual" in one of his rants. I haven't seen it myself, but it sounds like it's just the ticket from his description.
My absolute favorite for this kind of interview preparation is Steven Skiena's The Algorithm Design Manual. More than any other book it helped me understand just how astonishingly commonplace (and important) graph problems are – they should be part of every working programmer's toolkit. The book also covers basic data structures and sorting algorithms, which is a nice bonus. But the gold mine is the second half of the book, which is a sort of encyclopedia of 1-pagers on zillions of useful problems and various ways to solve them, without too much detail. Almost every 1-pager has a simple picture, making it easy to remember. This is a great way to learn how to identify hundreds of problem types.
problem domain
First you must understand the problem domain. An elegant solution to the wrong problem is no good, nor is an inefficient solution to the right problem in most cases. Solution quality, in other words, is often relative. A simple scheduling problem that has a deterministic solution that takes ten minutes to run may be fine if schedules are realculated once per week, but if schedules change several times a day then a genetic algorithm solution that converges in a few seconds may be required.
decomposition and mapping
Second, decompose the problem into sub-problems and known/unknown elements that correspond to elements of the solution. Sometimes this is obvious, e.g. to count widgets you need a way of identifying widgets, an incrementable counter, and a way of storing the count. Sometimes it is not so obvious. Sometimes you have to decompose the problem, the domain, and possible solutions at the same time and try several different mappings between them to find one that leads to the correct results [this is the general method].
model
Model the solution, in your head at least, and walk through it to see if it works correctly. Adjust as necessary (See decomposition and mapping, above).
composition/interfaces
Many times you can find elements of the problem and elements of the solution that map to each other and produce partial results that are useful. This composition and interface construction provides the kernal of the solution, and also serves to reduce the scope of the problem remaining. So then you just loop back to the top with a smaller initial problem, and go through it again.
experience
Experience is the best teacher, of course, but reading about different kinds of problems and solutions will also be helpful. Studying some of the well-known algorithms and their applications is likewise very helpful, e.g. Dijkstra, Bresenham, Unification, and of course, graph theory.
I am not sure intuition can be cultivated, but I think I know what you are asking. The more problems you solve, the more information and experience you have at your disposal for future problems. So, I say just practice. Practice programming real world applications and you run into plenty of problems. Sometimes, solving puzzles can be very educational as well.
I try to find physical analogues when I'm looking at a complex problem.
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 10 years ago.
I'm about to start (with fellow programmers) a programming & algorithms club in my high school. The language of choice is C++ - sorry about that, I can't change this. We can assume students have little to no experience in the aforementioned topics.
What do you think are the most basic concepts I should focus on?
I know that teaching something that's already obvious to me isn't an easy task. I realize that the very first meeting should be given an extreme attention - to not scare students away - hence I ask you.
Edit: I noticed that probably the main difference between programmers and beginners is "programmer's way of thinking" - I mean, conceptualizing problems as, you know, algorithms. I know it's just a matter of practice, but do you know any kind of exercises/concepts/things that could stimulate development in this area?
Make programming fun!
Possible things to talk about would be Programming Competitions that either your club could hold itself or it could enter in locally. I compete in programming competitions at the University (ACM) level and I know for a fact that they have them at lower levels as well.
Those kind of events can really draw out some competitive spirit and bring the club members closer.
Things don't always have to be about programming either. Perhaps suggest having a LAN party where you play games, discuss programming, etc could be a good idea as well.
In terms of actual topics to go over that are programming/algorithm related, I would suggest as a group attempting some of these programming problems in this programming competition primer "Programming Challenges": Amazon Link
They start out with fairly basic programming problems and slowly progress into problems that require various Data Structures like:
Stacks
Queues
Dictionaries
Trees
Etc
Most of the problems are given in C++.
Eventually they progress into more advanced problems involving Graph Traversal and popular Graph algorithms (Dijkstra's, etc) , Combinatrics problems, etc. Each problem is fun and given in small "story" like format. Be warned though, some of these are very hard!
Edit:
Pizza and Soda never hurts either when it comes to getting people to show up for your club meetings. Our ACM club has pizza every meeting (once a month). Even though most of us would still show up it is a nice ice breaker. Especially for new clubs or members.
Breaking it Down
To me, what's unique about programming is the need to break down tasks into small enough steps for the computer. This varies by language, but the fact that you may have to write a "for loop" just to count to 100 takes getting used to.
The "top-down" approach may help with this concept. You start by creating a master function for your program, like filterItemsByCriteria();
You have no idea how that will work, so you break it down into further steps:
(Note: I don't know C++, so this is just a generic example)
filterItemsByCritera() {
makeCriteriaList();
lookAtItems();
removeNonMatchingItems();
}
Then you break each of those down further. Pretty soon you can define all the small steps it takes to make your criteria list, etc. When all of the little functions work, the big one will work.
It's kind of like the game kids play where they keep asking "why?" after everything you say, except you have to keep asking "how?"
Linked lists - a classic interview question, and for good reason.
I would try to work with a C subset, and not try to start with the OO stuff. That can be introduced after they understand some of the basics.
Greetings!
I think you are getting WAY ahead of yourself in forcing a specific language and working on specific topics and a curriculum.. It sounds like you (and some of the responders) are confusing "advising a programming club" with "leading a programming class". They are very different things.
I would get the group together, and the group should decide what exactly they want to get out of the club. In essence, make a "charter" for the club. Then (and only then) can you make determinations such as preferred language/platform, how often to meet, what will happen at the meetings, etc.
It may turn out that the best approach is a "survey", where different languages/platforms are explored. Or it may turn out that the best approach is a "topical"one, where there topic changes (like a book club) on a regular basis (this month is pointers, next month is sorting, the following is recursion, etc.) and then examples and discussions occur in various languages.
As an aside, I would consider a "language-agnostic" orientation for the club. Encourage the kids to explore different languages and platforms.
Good luck, and great work!
Well, it's a programming club, so it should be FUN! So I would say dive into some hand on experience right away. Start with explaining what a main() method is,then have students write a hello world program. Gradually improve the hello world program so it has functions and prints out user inputs.
I would say don't go into algorithm too fast for beginners, let them play with C++ first.
Someone mentioned above, "make programming fun". It is interesting today that people don't learn for the sake of learning. Most people want instant gratification.
Teach a bit of logic using Programming. This helps with(and is) problem solving. The classing one I have in my head are guessing games.
Have them make a program that guesses at a number between 0 and 100.
Have them make a black jack clone ... I have done this in basic :-(
Make paper instructions.
Explain the "Fried eggs" story. Ask the auditory what they would do to make themselves fried eggs. Make them note the step they think about. Probably you will receive less than 5 steps algorithm. Then explain them how many steps should be written down if we want to teach a computer to fry eggs. Something like:
1) Go to the Fridge
2) Open the fridge door
3) Search for eggs
4) If there are no eggs - go to the shop to buy eggs ( this is another function ;) )
5) If there are eggs - calculate how many do you need to fry
6) Close the fridge door
7) e.t.c. :)
Start with basics of C - syntax semantics e.t.c, and in parallel with that explain the very basic algorithms like bubble sort.
After the auditory is familiar with structured programming (this could take several weeks or months, depending how often you make the lessons), you can advance to C++ and OOP.
The content in Deitel&Deitel's C++ programming is a decent introduction, and the exercises proposed at the end of each chapter are nice toy problems.
Basically, you're talking about:
- control structures
- functions
- arrays
- pointers and strings
You might want to follow up with an introduction to the STL ("ok, now that we've done it the hard way... here's a simpler option")
Start out by making them understand a problem like for instance sorting. This is very basic and they should be able to relate quite fast. Once they see the problem then present them with the tools/solution to solve it.
I remember how it felt when I first was show an example of merge-sort. I could follow all the steps but what the hell was I for? Make then crave a solution to a problem and they will understand the tool and solution much better.
start out with a simple "hello world" program. This introduces fundamentals such as variables, writing to a stream and program flow.
Then add complexity from there (linked lists, file io, getting user input, etc).
The reason I say start with hello world is because the kid will get to see a running program really quick. It's nearly immediate feedback-as they will have written a running program right from the start.
IMO, Big-O is one of the more important concepts for beginning programmers to learn.
Have a debugging contest. Provide code samples that include a bug. Have a contest to see who can find the most or fastest.
There is an excellent book, How Not to Program in C++, that you could use to start with.
You always learn best from mistakes and I prefer to learn from some else's.
It will also let those with little experience learn by see code, even if the code only almost works.
In addition to the answers to this question, there are certain important topics to cover. Here's an example of how you could structure the lessons.
First Lesson: Terminology and Syntax
Terminology to cover: variable, operator, loop (iteration), method, reserved word, data type, class
Syntax to cover: assignment, operation, if/then/else, for loop, while loop, select, input/output
Second Lesson: Basic Algorithm Construction
Cover a few simple algorithms, involving some input, maybe a for or a while loop.
Third Lesson: More Advanced Algorithm Topics
This is for things like recursion, matrix manipulation, and higher-level mathematics. You don't have to get into too complex of topics, but introduce enough complexity to be useful in a real project.
Final Lesson: Group Project
Make a project that groups can get involved in doing.
These don't have to be single day lessons. You can spread the topics across multiple days.
Pseudocode should be a very first.
Edit: If they are total programming beginners then I would make the first half just about programming. Once you get to a level where talking about algorithms would make sense then pseudocode is really important to get under the nails.
Thanks for your replies!
And how would you teach them actual problem solving?
I know a bunch of students that know C++ syntax and a few basic algorithms, but they can't apply the knowledge they know when they solve real problems - they don't know the approach, the way to transcribe their thoughts into a set of strict steps. I do not talk about 'high-level' approaches like dynamic programming, greedy etc., but about basic algorithmic mindset.
I assume it's just because of the poor learning process they were going through. In other sciences - math, for example - they are really brilliant.
Just because you are familiar with algorithms does not mean you can implement them and just because you can program does not mean you can implement an algorithm.
Start simple with each topic (keep programming separate from designing algorithms). Once they have a handle on each, slowly start to bring the two concepts together.
Wow. C++ is one of the worst possible languages to start with, in terms of the amount of unrelated crap you need to get anything working (Java would be slightly worse, I guess).
When teaching beginners in a boilerplate-heavy environment, it's usual to start with "here's a simple C program. We'll discuss what all this crap at the top of the file is for later, but for now, concentrate on the lines between 'int main(void)' and the 'return' statement, which is where all the useful work is accomplished".
Once you're past that point, basic concepts to cover include the basic data structures (arrays, linked lists, trees, and dictionaries), and the basic algorithms (sorting, searching, etc).
Have your club learn how to actually program in any language by teaching the concepts of building software. Instead of running out an buying a dozen licenses for Visual Studio, have students use compilers, make systems, source files, objects and librarys in order to turn their C code into programs. I feel this is truly the beginning and actually empowers these kids to understand how to make software on any platform, without crutches that many educational institutions like to rely on.
As for the language of choice - congratulations - you'll find C++ is very rich in making you think of mathematical shortcuts and millions of ways to make your code perform even better (or to implement fancy patterns).
To the question: When I was beggining to program I would always try to break down one real life problem into several steps and then as I see similarity between tasks or data they transform I would always try to find a lazier, easier, meanier way to implement it.
Elegance came after when learning patterns and real algorithms.
Hank: Big O??? you mean tell beginning programmers that their code is of O(n^2) and yours is of n log n ??
I could see a few different ways to take this:
1) Basic programming building blocks. What are conditional statements, e.g. switch and if/else? What are repetition statements, e.g. for and while loops? How do we combine these to get a program to be the sequence of steps we want? You could take something as easy as adding up a grocery bill or converting temperatures or distances from metric to imperial or vice versa. What are basic variable types like a string, integer, or double? Also in here you could have Boolean Algebra for an advanced idea or possibly teach how to do arithmetic in base 2 or 16 which some people may find easy and others find hard.
2) Algorithmically what are similar building blocks. Sorting is a pretty simple topic that can be widely discussed and analysed to try to figure out how to make this faster than just swapping elements that seem out of order if you learn the Bubblesort which is the most brain dead way to do.
3) Compiling and run-time elements. What is a call stack? What is a heap? How is memory handled to run a program,e.g. the code pieces and data pieces? How do we open and manipulate files? What is compiling and linking? What are make files? Some of this is simple, but it can also be eye-opening just to see how things work which may be what the club covers most of the time.
These next 2 are somewhat more challenging but could be fun:
4) Discuss various ideas behind algorithms such as: 1) Divide and conquer, 2) Dynamic programming, 3) Brute force, 4) Creation of a data structure, 5) Reducing a problem to a similar one already solved for example Fibonacci numbers is a classic recursive problem to give beginning programmers, and 6) The idea of being, "greedy," like in a making change example if you were in a country where coin denominations where a,b, and c. You could also get into some graph theory examples like a minimum weight spanning tree if you want something somewhat exotic, or the travelling salesmen for something that can be easy to describe but a pain to solve.
5) Mathematical functions. How would you program a factorial, which is the product of all numbers from 1 to n? How would you compute the sums of various Arithmetic or Geometric Series? Or compute the number of Combinations or Permutations of r elements from a set of n? Given a set of points, approximate the polynomial that meets this requirement, e.g. in a 2-dimensional plane called x and y you could give 2 points and have people figure out what are the slope and y intercept if you have solved pairs of linear equations already.
6) Lists which can be implemented using linked lists and arrays. Which is better for various cases? How do you implement basic functions such as insert, delete, find, and sort?
7) Abstract Data Structures. What are stacks and queues? How do you build and test classes?
8) Pointers. This just leads to huge amounts of topics like how to allocate/de-allocate memory, what is a memory leak?
Those are my suggestions for various starting points. I think starting a discussion may lead to some interesting places if you can get a few people together that don't mind talking on the same subject week after week in some cases as sorting may be a huge topic to cover well if you want to get into the finer points of things.
You guys could build the TinyPIM project from "C++ Standard Library from Scratch" and then, when it's working, start designing your own extensions.
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.
What are some simple algorithm or data structure related "white boarding" problems that you find effective during the candidate screening process?
I have some simple ones that I use to validate problem solving skills and that can be simply expressed but have some opportunity for the application of some heuristics.
One of the basics that I use for junior developers is:
Write a C# method that takes a string which contains a set of words (a sentence) and rotates those words X number of places to the right. When a word in the last position of the sentence is rotated it should show up at the front of the resulting string.
When a candidate answers this question I look to see that they available .NET data structures and methods (string.Join, string.Split, List, etc...) to solve the problem. I also look for them to identify special cases for optimization. Like the number of times that the words need to be rotated isn't really X it's X % number of words.
What are some of the white board problems that you use to interview a candidate and what are some of the things you look for in an answer (do not need to post the actual answer).
I enjoy the classic "what's the difference between a LinkedList and an ArrayList (or between a linked list and an array/vector) and why would you choose one or the other?"
The kind of answer I hope for is one that includes discussion of:
insertion performance
iteration performance
memory allocation/reallocation impact
impact of removing elements from the beginning/middle/end
how knowing (or not knowing) the maximum size of the list can affect the decision
Once when I was interviewing for Microsoft in college, the guy asked me how to detect a cycle in a linked list.
Having discussed in class the prior week the optimal solution to the problem, I started to tell him.
He told me, "No, no, everybody gives me that solution. Give me a different one."
I argued that my solution was optimal. He said, "I know it's optimal. Give me a sub-optimal one."
At the same time, it's a pretty good problem.
When interviewing recently, I was often asked to implement a data structure, usually LinkedList or HashMap. Both of these are easy enough to be doable in a short time, and difficult enough to eliminate the clueless.
This doesn't necessarily touch on OOP capabilities but in our last set of interviews we used a selection of buggy code from the Bug of the Month list. Watching the candidates find the bugs shows their analytical capabilities, shows the know how to interpret somebody elses code
Write a method that takes a string, and returns true if that string is a number.(anything with regex as the most effective answer for an interview)
Please write an abstract factory method, that doesn't contain a switch and returns types with the base type of "X". (Looking for patterns, looking for reflection, looking for them to not side step and use an if else if)
Please split the string "every;thing|;|else|;|in|;|he;re" by the token "|;|".(multi character tokens are not allowed at least in .net, so looking for creativity, the best solution is a total hack)
Graphs are tough, because most non-trivial graph problems tend to require a decent amount of actual code to implement, if more than a sketch of an algorithm is required. A lot of it tends to come down to whether or not the candidate knows the shortest path and graph traversal algorithms, is familiar with cycle types and detection, and whether they know the complexity bounds. I think a lot of questions about this stuff comes down to trivia more than on the spot creative thinking ability.
I think problems related to trees tend to cover most of the difficulties of graph questions, but without as much code complexity.
I like the Project Euler problem that asks to find the most expensive path down a tree (16/67); common ancestor is a good warm up, but a lot of people have seen it. Asking somebody to design a tree class, perform traversals, and then figure out from which traversals they could rebuild a tree also gives some insight into data structure and algorithm implementation. The Stern-Brocot programming challenge is also interesting and quick to develop on a board (http://online-judge.uva.es/p/v100/10077.html).
Follow up any question like this with: "How could you improve this code so the developer who maintains it can figure out how it works easily?"
Implement a function that, given a linked list that may be circular, swaps the first two elements, the third with the fourth, etc...
I like to go over a code the person actually wrote and have them explain it to me.
Asking them to write a recursive algorithm for a well known iterative solution (i.e. Fibonacci etc. -- we give them an iterative function, if needed) and then have them compute the run time for it.
Many times the recursive function involves a tree data structure. The number of times the person has failed to recognize that baffles me. It becomes slightly difficult to calculate the run time until you can see that it's a tree structure...
I find that this problem covers many areas. Namely, their code-reading ability (if they are given an iterative function), code-writing ability (since they write a recursive function), algorithm, data-structure (for run-time)...
A trivial one is to ask them to code up a breadth-first search of a tree from scratch. Yeah, if you know what you're doing it is trivial. But a lot of programmers don't know how to tackle it.
One that I find more useful still is as follows. I've given this in a number of languages, here is a Perl version. First I give them the following code sample:
# #a and #b are two arrays which are already populated.
my #int;
OUTER: for my $x (#a) {
for my $y (#b) {
if ($x eq $y) {
push #int, $x;
next OUTER;
}
}
}
Then I ask them the following questions. I ask them slowly, give people time to think, and am willing to give them nudges:
What is in #int when this code is done?
This code is put into production and there is a performance problem that is tracked back to this code. Explain the potential performance problem. (If they are struggling I'll ask how many comparisons it takes if #a and #b each have 100,000 elements. I am not looking for specific terminology, just a back of the envelope estimate.)
Without code, suggest to make this faster. (If they propose a direction that is easy to code, I'll ask them to code it. If they think of a solution that will result in #int being changed in any way (eg commonly order), I'll push to see whether they realize that they shouldn't code the fix before checking whether that matters.)
If they come up with a slightly (or very) wrong solution, the following silly data set will find most mistakes you run across:
#a = qw(
hello
world
hello
goodbye
earthlings
);
#b = qw(
earthlings
say
hello
earthlings
);
I'd guess that about 2/3 of candidates fail this question. I have yet to encounter a competent programmer who had trouble with it. I've found that people with good common sense and very little programming background do better on this than average programmers with a few years of experience.
I would suggest using these questions as filters. Don't hire someone because they can answer these. But if they can't answer these, then don't hire them.