I need to have the bigger picture in my head. I took a look at books of programming interviews and they focus a lot on algorithms and data structures. These concepts are one of the most important for a CS student? Is that knowledge used in the real world? Or they just ask that in programming interviews because they feel its good way to evaluate someone?
*moved to General Discussions*
The concept of abstraction and the ability to traverse different levels of abstraction is among the most crucial concepts and skills.Originally Posted by telmo_d
It depends on what exactly you end up doing. You may find that you do not need to go into the nitty gritty of these simply because you will be using libraries or built-in constructs from higher level languages that abstract away these for you. However, abstractions leak.
One school of thought is that it is good to test simple algorithm and data structure knowledge and skills to separate those who might be able to program from those who cannot program to save their life, after which other approaches can more clearly determine if the candidate is skilled (e.g., able to solve problems beyond his/her current expertise by looking things up, etc) and a good fit for the team.
Look up a C++ Reference and learn How To Ask Questions The Smart Way
Indeed they are. They'll make a great deal of your education.
Data structures represent different arrangements of data storage and manipulation. And data is the chemical element of programming. A good grasp of different data structures will allow you to choose the ones that will better fit your data for any given problem.
Where data structures represent the constituents of programming, algorithms represent its methodology. They are your window into the different patterns of reasoning through problems. Your program by studying a problem and arranging a solution by delineating adequate data structures and working on them through algorithms.
But the algorithms you learn, are actually just known patterns to common problems that are worth studying. They are like well know mathematical formulas that you must study, but alone they can't solve mathematical problems. Anything you do in a computer program is part of an algorithm. So your programs are in fact composed almost entirely of algorithms designed by you, and only a tiny fraction is actually taken from the well-known algorithms. However, their general applicability and the fact they are ubiquitous in all of computer programming, make them valuable in the sense you don't have to reinvent the wheel.
By understanding the value of data structures and the mechanics of algorithms, you are better equipped to reason through problems and implement all sorts of solutions. And that's where the concept of abstraction laserlight mentioned comes in. By dominating these two important tools, the powerful notion of abstraction will come to you normally (almost without needing anyone to teach you about it). Computing problems are usually complex problems. You will have a need to break them down into more manageable smaller problems and build a solution out of its parts. Abstraction, as a generic definition, will allow you to define a cohesive tree of smaller problems that you can work through effortlessly in order to reach the solution.
Once you get a degree in CS with honors, you'll find much of the interview material pathetic and often even without a reason. Something only someone with barely a grasp of computer programming would think of writing down. Industry interviews are not a good indicator of the actual needs and requirements of the industry. But there are some companies that do it right. Not just that many though.
And yet, algorithms and data structures must indeed be a part of any good interview. They shouldn't be used exclusively and they shouldn't be used as a means to immediately discard a candidate. But they should be used as part of a larger whole of questions that will help realize the level of exposure a candidate has had to programming. A good interview will very probably not ask you to write a bubble sort algorithm (no one should care about it), but they will want you to talk a little about the differences between a bubble sort and a quick sort.
More important than your ability to shred over these things without effort, however, will be your ability to reason and talk them through. What you will experience in almost any company that takes software development seriously is that they are more interested in testing your communication skills and how well you reason through difficult problems. Your practical test score may have scored low. But the company may still want to hire you and go through filling the gaps in your knowledge if you demonstrate capacities in the two most difficult arts of computer programming: your ability to communicate in with your colleagues is essential if functioning as a team. And your ability to reason through problems will be your second most valuable asset. These things you will not be taught in college. However, they will be made easier to acquire if you have a good grasp of CS.
Last edited by Mario F.; 09-11-2015 at 12:22 PM.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
When I interviewed graduate programmers I used to ask them to write a Fizz Buzz app, in any language or pseudo-code they liked.
[Fizz Buzz : print the numbers 1 to 100. If the number is divisible by 3 print 'Fizz' instead, divisible by 5 print 'Buzz' instead and divisible by both print 'FizzBuzz' instead]
No graduate got it 100% right. One who claimed he had a Masters could not even start...
I hired the one who got very close, was very disappointed he got it wrong and was genuinely interested to know how to fix it.
"Man alone suffers so excruciatingly in the world that he was compelled to invent laughter."
Friedrich Nietzsche
"I spent a lot of my money on booze, birds and fast cars......the rest I squandered."
George Best
"If you are going through hell....keep going."
Winston Churchill
We don't include FizzBuzz-like questions in our interviews. We usually screen a small amount of candidates when we hire, since we run job ads for a very limited time, so that's one reason why I never felt the need. We just go straight to problem solving code. Usually one simple, one very hard and one without an actual solution.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
I love these. I'm bored. Have any examples?
Unless, of course, you mean problems that cannot be solved within the constraints given. Those are uninteresting, like asking to measure the circumference of the world using a nail file, a shovel with a broken handle, a used napkin, and a dried out red sharpie. Uninspiring, demotivational, just tricky. There's no point, nothing to gain by solving those.
I also detest 'Google' questions. Ones that could be answered with a simple Google search. Is that really who you want to hire? Does it really matter if the person knows X right off the top of their head? Is it truly possible to remember every key concept in programming when there are so many areas and variations and languages? I would say no. Stop asking Google questions and ask questions that mean something.
After the technical stuff is done I usually resort to some of these:
How do you go about learning a new code line?
How long does it take for you to ask a question if you don't understand something or are stuck?
Are you an 'ask for forgiveness' person or an 'ask for permission' person?
Name one trait about yourself that you do not like or would like to work on?
What are your strong points?
What are your weaknesses?
What does your ideal team look like? How does it function?
In your opinion what is the single most important aspect to getting a project done on time while maintaining quality.
How do you deal with difficult team members?
What do you do if you cannot get along with a specific team member?
In your opinion, are you a difficult person to work with?
Do you require a lot of structure in your work or do you function better in a more fluid environment?
Even if the tech is there if I don't like the answers to the above or they don't fit with our environment I usually pass. Some people are great but they might not be great for your team.
Last edited by VirtualAce; 09-12-2015 at 11:18 AM.
They are more or less of that kind.
The idea is to grasp the candidate problem analysis abilities, not just his problem solving. My software development team is small. We don't benefit from a large number of developers that can more easily cover the disadvantages of each other. So I tend to need candidates that can perform a above the average and have a wider spectrum of abilities. If in my team no one is good at software analysis, I'm in trouble.
So, other than the usual Solve questions, I also like to introduce trick questions mean to test the candidate ability to detect problems in the actual problem formulation. I tend to cycle these and don't usually talk about them. But here's one from last year:
Michael always runs at least as fast as Michel, while Mikel runs at least as fast as Michael and Michel can never run faster than Michael. If in one day Michel runs at 13.9 m/s and and Mikel runs at 49.68 km/h, at what speed did Michael run that day? Code a generic algorithm that can answer this question and round your answer to the nearest tenth of a meter per second.
Last edited by Mario F.; 09-12-2015 at 01:16 PM.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
This is so weird, I just got done interviewing with a company who honest to God asked me to do that too O_o
Only it was in JavaScript so it was awesome and very easy to modularize and do things like, "we can improve this by instead passing a generic predicate function and blah blah blah."
I don't know if I did it wrong or not but my check was basically,
Granted, I don't think they asked me to do the whole divisible by both thing but they did ask me to make it more generic which was cool because a lot of my C++ experience really helped. They were also excited that I was excited about meshing. We'll see if I get the job lol. 3 interviews, man; that's a lot!Code:for ( var i = 0; i < n; ++i ) { if ( i % 3 === 0 && i % 5 === 0 ) .... else if ( i % 5 === 0 ) .... else if ( i % 3 === 0 ) ... else ... }
Yeah, you did it wrong.
Not technically wrong, but even the guy printing out "1\n2\n\Fizz\n..." manually would be technically correct.
Really? What did I do wrong?Yeah, you did it wrong.
Not technically wrong, but even the guy printing out "1\n2\n\Fizz\n..." manually would be technically correct.
The most important thing is to be able to take a list of requirements and know how to implement them. Knowing algorithms and data structures is good - you should at least be familiar with what they are - but there's a fairly shocking number of people who get CS degrees and can't actually write a real program, not even a trivial one like FizzBuzz, which is a handful of lines of code.
A lot of people come out of programming courses knowing a programming language, but not how to program. Don't make the mistake that many do of thinking they are the same thing. Knowing at least one programming language is necessary to be a good programmer, but it's not sufficient, any more than knowing English is sufficient to make one a good novelist.
You ever try a pink golf ball, Wally? Why, the wind shear on a pink ball alone can take the head clean off a 90 pound midget at 300 yards.
Most important aspect IMO: how to work on a team. No one cares what you know if you are a jerk to work with. Nothing kills a team more than one bad member with a poor attitude. After that it comes down to what has been mentioned in this thread.
But it is very hard to hire someone with personality issues even if they are a genius. 9 times out of 10 that comes back to bite you. They don't have to be super cuddly teddy bears because no engineer is. But if they exhibit signs of being hard to work with, cannot handle criticisms of their code within the interview, etc. that person would receive an immediate no from me.
Very few jobs allow you to work alone all the time so a team mindset is crucial to getting most projects done.
You know, Mario, if Nominal gets this, you're going to, like, have to give him a job offer.
Fat chance of that ever happening. Neither I would be interested in paying him his true worth.
My team is made of four developers. Every single one of them much better programmers than I. And that is something that I'm very proud of. Meanwhile I just run things now, and manage the projects. But the masters in these boards, people like Nominal, Laserlight, Salem, Phantomotap,... they don't exactly come knocking at my door. I have yet to have interviewed even one candidate of their caliber.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
