OT: Binary Search - Should They Know It?

[jehugaleahsa]

Hello:

Should the average programmer, like a full-time programmer, know when
to use a Binary Search? Should a serious programmer at least know what
it is? Not so much the name, but at least how it works...?

My opinion is that anyone who spends the majority of their work day
writing code should know what a binary search is.

Should they know when to use a Dictionary? I think they should.

I know a lot of people think that you shouldn't expect a programmer to
know trivial things. However, I don't think data structures and
algorithms are something you can really afford to overlook. Sure, I
don't expect someone to be able to implement them, but I do expect
them to know _when_ to use them.

You can't even get out of a decent CS program anymore without learning
the basics about such things. Maybe I'm being biased because of my
background... but I don't think so.

I know this sounds harsh, but when my company is trying to hire a full-
time programmer, we get a lot of candidates who come from a background
of short-term jobs. Their experience usually involves small projects
written in interpreted languages. When you are looking for someone
with experience in a language like C++ or C# and you need them to have
basic skills in software design, it is really frustrating to get a lot
of desperate, out-of-work hackers (essentially). I know that most of
the community is made up of such individuals and I am not
disrespecting them. These individuals do have their place in the
computer industry. I just wish there was a better way of filtering
them out from our searches (to avoid the bad feelings and wasting
everyone's time).

We have had candidates that could answer any C# question you throw
their way. They might even have a certification in C#. However, when
you ask them questions about their understanding on things like
software architecture, design patterns, etc., you get shaky answers.
You really can read all the GoF books in the world and only _think_
you understand. Unfortunately, their correct application requires
experience... lots of it.

So how can you tell if someone is knowledgable... and experienced? Is
it wrong for us to disregard someone because they aren't familiar with
the tools in our environment? We need someone who can hit the ground
running. We can't afford to waste the time to teach someone how to
program in Visual Studio and C#. We can't afford to redo all of their
work because they don't understand the principles behind our
development process and coding standards. I don't think we are being
unfair, by any means.

Another hard question is: if someone is very knowledgeable about C#
but doesn't have first-hand experience with design patterns and
software architecture, can we bring them up to speed? I was given that
chance and I am all the better for it, and I hope I've been more of a
grace to my company than a burden.

I guess I'm partly being paranoid. I have to relinquish some of my
control and trust someone else's work. I can't expect someone to come
in and know everything. It's so hard when you're the one on the
opposite of the table.

It would be nice to find someone who had read these books:

Gang of Four (maybe)
Patterns of Enterprise Architecture (definitely)
Applying UML and Patterns (preferrably)
xUnit Test Patterns (maybe)

They literally changed the way I program. They are also really long
reads. There are also some books that are equivilent. The information
they contain is what we really need. Unfortunately, I think most
people who understand these books are getting paid a lot more than we
can afford to pay. I can always lend these to whomever we do hire.

Big SIGH.

 

[Henry]

Hello.

It seems to me that one of your biggest concerns is to find someone who
has real-world, practical experience in addition to programming theory.
I've been through, on both sides of the interviewer's table.

Before I became a programmer, I was an electronic engineering
technician. When I got my first job, my boss - who was my interviewer
-, told me something
similar to what you're describing: "You know, we could hire an engineer
from a top school, and he can tell me where an electron is at any point
in the
schematic, but if he can't fix the control if it's broken, they're not
worth a damn to me."

I had a friend already in the industry, and he told me, "Don't worry
about memorizing every formula. What you'll get paid for is
trouble-shooting problems,
and when you think you've found a potential problem, knowing where to
look up the right formula." I'd say that this applies to your question
of whether or not
a programmer should know what a binary search is. I'd say they
absolutely should know what a binary search is, but they shouldn't
necessarily need to
memorize the algorithm and be able to write it out for an employment
test. You might ask a job candidate to give a description of the
thought behind the
algorithm - any algorithm - and from that you should have a pretty fair
idea if they're familiar with the data structure, algorithm, theory,
etc. that you're asking
about.

To see if they have the sort of practical experience you're looking for,
there are a number of questions you might ask:

1) Somebody in the company tells you, "We need an application for the
sales department. It has to do these five things: 1, 2, 3, 4 and 5.
What do you do?"
This is where they will reveal their business experience. You
probably want to hear things like, "I need specs. I talk to the users.
I hold a meeting. I want to
know what the users want and need. I want to see the current
application and find out how they use it. I want to find out why it's
no longer good enough, and \
why we can't just keep adding to it. I want to find out what they
need to do, day in and day out, that the software can't do. I want to
find out what kind of reports they're
looking for. I want to find out if management wants reports
built in that the majority of users can't access. I want copies of all
paperwork that they have to
fill out. (An old standard, but still valid.)" If they mention
topics like these, that's a good sign.

2) Ask them, "How do you build an application?"
If they say, "Once I have specs..." (a good sign) "I build the
application and then I deliver it." that's a bad sign.
If, on the other hand, they say things like, "Once I have specs
and have a good understanding what they want, I write everything up and
distribute a document that
spells everything out. I want everybody's approval in writing so
I can get started. I build prototypes of various key forms, menus,
reports, etc., and again get approval.
I then build basic functionality and again get approval. I then
fully build the application and again get approval. Then we start user
testing. (User Acceptance testing,
Unit Testing, QA testing, load or stress testing, etc.) We have to
do testing all aspects of the application to ensure that it does
everything it's supposed to do, it's
accurate, it's reliable, and it's fast enough. Once it gets
approval in its final form, we run parallel testing to compare its
performance in production to see how it behaves in
a real-world, networked, multi-user environment." Again, if they
talk about things like these, that's a good sign.

3) Ask them about their approach to building reports. If they haven't
built many - or any - well, that's not good. If they say things like,
"I gather all of the data first, so it
can be validated later, perhaps manually (via SQL queries, etc.)
and let the report display groupings, subtotals and grand totals." (If
the reports ever give unexpected
results, you can access the data already developed without
depending on the report to build the data.)

4) For a desktop application - not a Web form - show them a mock-up of
a simple GUI. Ask them, "Take a look at this form. Every user screen
should include one crucial item. Do you think this form is ok to
give to the users?" Here's the catch: the form you show them should
not include a Cancel or Exit button.
You want the candidate to spot this, since every form should have a
way out. This might not be a deal -breaker, but it should stick in your
mind.

I'm sure that there are a lot of other questions that you could ask to
get a feel for the candidate's general business experience. I'm also
sure that there's a lot of room for
disagreement with my suggestions. Be that as it may, I hope that this
is of some help to you. Good luck.

 

[Henry]

Hello.

It seems to me that one of your biggest concerns is to find someone who
has real-world, practical experience in addition to programming theory.
I've been through, on both sides of the interviewer's table.

Before I became a programmer, I was an electronic engineering
technician. When I got my first job, my boss - who was my interviewer
-, told me something
similar to what you're describing: "You know, we could hire an engineer
from a top school, and he can tell me where an electron is at any point
in the
schematic, but if he can't fix the control if it's broken, they're not
worth a damn to me."

I had a friend already in the industry, and he told me, "Don't worry
about memorizing every formula. What you'll get paid for is
trouble-shooting problems,
and when you think you've found a potential problem, knowing where to
look up the right formula." I'd say that this applies to your question
of whether or not
a programmer should know what a binary search is. I'd say they
absolutely should know what a binary search is, but they shouldn't
necessarily need to
memorize the algorithm and be able to write it out for an employment
test. You might ask a job candidate to give a description of the
thought behind the
algorithm - any algorithm - and from that you should have a pretty fair
idea if they're familiar with the data structure, algorithm, theory,
etc. that you're asking
about.

To see if they have the sort of practical experience you're looking for,
there are a number of questions you might ask:

1) Somebody in the company tells you, "We need an application for the
sales department. It has to do these five things: 1, 2, 3, 4 and 5.
What do you do?"
This is where they will reveal their business experience. You
probably want to hear things like, "I need specs. I talk to the users.
I hold a meeting. I want to
know what the users want and need. I want to see the current
application and find out how they use it. I want to find out why it's
no longer good enough, and \
why we can't just keep adding to it. I want to find out what they
need to do, day in and day out, that the software can't do. I want to
find out what kind of reports they're
looking for. I want to find out if management wants reports
built in that the majority of users can't access. I want copies of all
paperwork that they have to
fill out. (An old standard, but still valid.)" If they mention
topics like these, that's a good sign.

2) Ask them, "How do you build an application?"
If they say, "Once I have specs..." (a good sign) "I build the
application and then I deliver it." that's a bad sign.
If, on the other hand, they say things like, "Once I have specs
and have a good understanding what they want, I write everything up and
distribute a document that
spells everything out. I want everybody's approval in writing so
I can get started. I build prototypes of various key forms, menus,
reports, etc., and again get approval.
I then build basic functionality and again get approval. I then
fully build the application and again get approval. Then we start user
testing. (User Acceptance testing,
Unit Testing, QA testing, load or stress testing, etc.) We have to
do testing all aspects of the application to ensure that it does
everything it's supposed to do, it's
accurate, it's reliable, and it's fast enough. Once it gets
approval in its final form, we run parallel testing to compare its
performance in production to see how it behaves in
a real-world, networked, multi-user environment." Again, if they
talk about things like these, that's a good sign.

3) Ask them about their approach to building reports. If they haven't
built many - or any - well, that's not good. If they say things like,
"I gather all of the data first, so it
can be validated later, perhaps manually (via SQL queries, etc.)
and let the report display groupings, subtotals and grand totals." (If
the reports ever give unexpected
results, you can access the data already developed without
depending on the report to build the data.)

4) For a desktop application - not a Web form - show them a mock-up of
a simple GUI. Ask them, "Take a look at this form. Every user screen
should include one crucial item. Do you think this form is ok to
give to the users?" Here's the catch: the form you show them should
not include a Cancel or Exit button.
You want the candidate to spot this, since every form should have a
way out. This might not be a deal -breaker, but it should stick in your
mind.

I'm sure that there are a lot of other questions that you could ask to
get a feel for the candidate's general business experience. I'm also
sure that there's a lot of room for
disagreement with my suggestions. Be that as it may, I hope that this
is of some help to you. Good luck.

 

[Cor Ligthert[MVP]]

Why,

It is in my opinion like the mystic around boxing an even more than the
latter from the first days of programming.

That are not anymore the bottlenecks in programming. Using bad graphics on a
screen can make programs slow.
As 99% of the solutions are related to graphics, that is more a point of
view.

Being busy with things as a "binary search" shows mostly that you are an
hobbyist with old habits currently.

You wrote "They literally changed the way I program", so you was not able to
do that before you were confronted with that.
Why would anybody else not have the chance to do that?

But then for newer things which are still relevant and not old animals as
the binary search.

Just my opinion.

Cor

 

[Cor Ligthert[MVP]]

Why,

It is in my opinion like the mystic around boxing an even more than the
latter from the first days of programming.

That are not anymore the bottlenecks in programming. Using bad graphics on a
screen can make programs slow.
As 99% of the solutions are related to graphics, that is more a point of
view.

Being busy with things as a "binary search" shows mostly that you are an
hobbyist with old habits currently.

You wrote "They literally changed the way I program", so you was not able to
do that before you were confronted with that.
Why would anybody else not have the chance to do that?

But then for newer things which are still relevant and not old animals as
the binary search.

Just my opinion.

Cor

 

[Jeroen Mostert]

First off, all the replies you've gotten so far are good, each focusing on
different aspects, and I agree with all of them. So if I write something
that appears to disagree below, I'm probably lacking nuance rather than
voicing actual disagreement.

Should the average programmer, like a full-time programmer, know when
to use a Binary Search?
Yes.

Should a serious programmer at least know what it is?

A serious programmer should be able to implement it.

A Real Programmer (tm) is able to implement it correctly. In one try. On
paper. While proving its correctness at the same time. And then give you an
implementation in PDP-11 assembly language. With the actual machine code in
the margin. While recounting an amusing anecdote about the last time he did
something like this.

However, Real Programmers (tm) are not necessarily what you need for any
given job. For some jobs you don't even need serious programmers.

I know a lot of people think that you shouldn't expect a programmer to
know trivial things.

Triviality is no measure of uselessness. If someone couldn't tie their shoes
or multiply two numbers below ten because it's trivial, being told that they
could always look up the procedures for that if they needed it would be
small comfort. It's just too easy to imagine situations where those skills
would be needed without external help or time for a study session. (Granted,
the choice of footwear is usually your own.)

In a sense, the trivial stuff is the most important. This is what you have
to know, without having to think about it, to be effective at your work in
the first place. It's the highly detailed and complicated stuff that rarely
requires you to know everything about it all the time.

On the other hand, it is true that the trivial stuff is tested for much more
often than genuine problem-solving skills, simply because it's easier to do.
Actually, asking someone "show me a binary search" or "what is a class" is
more of a test for the interviewer, as they have to be able to interpret the
answer and follow up while the interviewee could spit out a memorized response.

And there is a difference between trivial stuff and trivia. If a programmer
can't tell you what Shell sort is, how the 8086 segment registers work or
what the C# "partial" keyword is for, this says very little about their
qualifications as a programmer in general. Whether it matters to the job
you're hiring them for is another matter altogether, of course.

These individuals do have their place in the computer industry. I just
wish there was a better way of filtering them out from our searches (to
avoid the bad feelings and wasting everyone's time).

It's funny that you started with binary search, because it's a pretty good
basis for testing technical skills at various levels.

The most basic question could be "how would you find an item in a sorted
collection"? If they don't know what binary search is at all, they'll
probably give you a linear search -- or they'll insist to know the language
or framework, so they can look for a search function. Or maybe, if you've
got a lost non-programmer on your hands, they'll interpret the question as
"how would you (a human being) search in a sorted collection (like a
library)"? It's up to you whether to show them binary search at this point
or decide that that's already not good enough.

If they do show you binary search, or you show them (just what it does, not
why), ask them to explain how it works. This can be very insightful, as
you're not only testing technical insight but also communication skills. Are
they essentially talking to themselves or trying to convince you? Is the
explanation simple or roundabout? Abstract or concrete? Do they insist on
technical precision or do they keep it intuitive?

You can go lots of places from there. Ask them for a concrete implementation
in a language, about the bugs in that implementation (whether there are or
there aren't, you're sure to get a good story), present a modified problem
for which you could still use a binary search (like finding the largest
element smaller than X), ask them about the computational complexity (or if
they don't know what that is, just why this is faster than a linear search
and how many steps you'd need on average to find an item), whatever seems
like a good way of finding out what their game is.

How far you want to go with this and which responses are "correct" depends
on what sort of candidate you're looking for. And of course this story
mostly ignores engineering skills, which are much harder to test for without
having them build larger things.

So how can you tell if someone is knowledgable... and experienced?

The proof of the pudding is in the eating. If the interview convinces you
that they're suitable for the job, hire them for a trial period.

Is this costly? Yes. But any lesser test is not going to convince you. The
only real way to reduce the costs is to make the screening process better
(or just more stringent), and this requires skilled interviewers who know
what they're looking for and who won't settle for ticking off canned answers
from a list.

Another hard question is: if someone is very knowledgeable about C#
but doesn't have first-hand experience with design patterns and
software architecture, can we bring them up to speed?

You need to hire people who can bring *themselves* up to speed. Someone
who's very knowledgeable about programming (not just C#) has the necessary
acumen to learn about design patterns and software architecture. Those
things where invented/discovered (take your pick) by programmers in the
first place.

Searching for a candidate who has all the skills you're looking for in
exactly the right proportion is both hard and unlikely to be cost-effective.

It would be nice to find someone who had read these books:

Gang of Four (maybe)
Patterns of Enterprise Architecture (definitely)
Applying UML and Patterns (preferrably)
xUnit Test Patterns (maybe)

If you really think that, you can just demand your candidates have read
those books. Unfortunately, this is really going to limit your choices in a
probably unnecessary way. Are you really looking for someone who can do the
job or someone who thinks exactly like you? What if someone thought that one
or all of the books you read were unnecessary or overrated? Would you even
be willing to argue or would it be an automatic non-hire?

They literally changed the way I program. They are also really long
reads. There are also some books that are equivilent. The information
they contain is what we really need.

Then you should *really* demand that candidates have read those books,
because it also allows candidates to get an idea of whether the company is a
good fit for *them*. If I were presented with a job that really emphasized
that I have to have read those books, I'd conclude that the company is too
enterprisey for its own good and I would probably look around for something
else, and this would be better for both of us.

 

[Jeroen Mostert]

First off, all the replies you've gotten so far are good, each focusing on
different aspects, and I agree with all of them. So if I write something
that appears to disagree below, I'm probably lacking nuance rather than
voicing actual disagreement.

Should the average programmer, like a full-time programmer, know when
to use a Binary Search?
Yes.

Should a serious programmer at least know what it is?

A serious programmer should be able to implement it.

A Real Programmer (tm) is able to implement it correctly. In one try. On
paper. While proving its correctness at the same time. And then give you an
implementation in PDP-11 assembly language. With the actual machine code in
the margin. While recounting an amusing anecdote about the last time he did
something like this.

However, Real Programmers (tm) are not necessarily what you need for any
given job. For some jobs you don't even need serious programmers.

I know a lot of people think that you shouldn't expect a programmer to
know trivial things.

Triviality is no measure of uselessness. If someone couldn't tie their shoes
or multiply two numbers below ten because it's trivial, being told that they
could always look up the procedures for that if they needed it would be
small comfort. It's just too easy to imagine situations where those skills
would be needed without external help or time for a study session. (Granted,
the choice of footwear is usually your own.)

In a sense, the trivial stuff is the most important. This is what you have
to know, without having to think about it, to be effective at your work in
the first place. It's the highly detailed and complicated stuff that rarely
requires you to know everything about it all the time.

On the other hand, it is true that the trivial stuff is tested for much more
often than genuine problem-solving skills, simply because it's easier to do.
Actually, asking someone "show me a binary search" or "what is a class" is
more of a test for the interviewer, as they have to be able to interpret the
answer and follow up while the interviewee could spit out a memorized response.

And there is a difference between trivial stuff and trivia. If a programmer
can't tell you what Shell sort is, how the 8086 segment registers work or
what the C# "partial" keyword is for, this says very little about their
qualifications as a programmer in general. Whether it matters to the job
you're hiring them for is another matter altogether, of course.

These individuals do have their place in the computer industry. I just
wish there was a better way of filtering them out from our searches (to
avoid the bad feelings and wasting everyone's time).

It's funny that you started with binary search, because it's a pretty good
basis for testing technical skills at various levels.

The most basic question could be "how would you find an item in a sorted
collection"? If they don't know what binary search is at all, they'll
probably give you a linear search -- or they'll insist to know the language
or framework, so they can look for a search function. Or maybe, if you've
got a lost non-programmer on your hands, they'll interpret the question as
"how would you (a human being) search in a sorted collection (like a
library)"? It's up to you whether to show them binary search at this point
or decide that that's already not good enough.

If they do show you binary search, or you show them (just what it does, not
why), ask them to explain how it works. This can be very insightful, as
you're not only testing technical insight but also communication skills. Are
they essentially talking to themselves or trying to convince you? Is the
explanation simple or roundabout? Abstract or concrete? Do they insist on
technical precision or do they keep it intuitive?

You can go lots of places from there. Ask them for a concrete implementation
in a language, about the bugs in that implementation (whether there are or
there aren't, you're sure to get a good story), present a modified problem
for which you could still use a binary search (like finding the largest
element smaller than X), ask them about the computational complexity (or if
they don't know what that is, just why this is faster than a linear search
and how many steps you'd need on average to find an item), whatever seems
like a good way of finding out what their game is.

How far you want to go with this and which responses are "correct" depends
on what sort of candidate you're looking for. And of course this story
mostly ignores engineering skills, which are much harder to test for without
having them build larger things.

So how can you tell if someone is knowledgable... and experienced?

The proof of the pudding is in the eating. If the interview convinces you
that they're suitable for the job, hire them for a trial period.

Is this costly? Yes. But any lesser test is not going to convince you. The
only real way to reduce the costs is to make the screening process better
(or just more stringent), and this requires skilled interviewers who know
what they're looking for and who won't settle for ticking off canned answers
from a list.

Another hard question is: if someone is very knowledgeable about C#
but doesn't have first-hand experience with design patterns and
software architecture, can we bring them up to speed?

You need to hire people who can bring *themselves* up to speed. Someone
who's very knowledgeable about programming (not just C#) has the necessary
acumen to learn about design patterns and software architecture. Those
things where invented/discovered (take your pick) by programmers in the
first place.

Searching for a candidate who has all the skills you're looking for in
exactly the right proportion is both hard and unlikely to be cost-effective.

It would be nice to find someone who had read these books:

Gang of Four (maybe)
Patterns of Enterprise Architecture (definitely)
Applying UML and Patterns (preferrably)
xUnit Test Patterns (maybe)

If you really think that, you can just demand your candidates have read
those books. Unfortunately, this is really going to limit your choices in a
probably unnecessary way. Are you really looking for someone who can do the
job or someone who thinks exactly like you? What if someone thought that one
or all of the books you read were unnecessary or overrated? Would you even
be willing to argue or would it be an automatic non-hire?

They literally changed the way I program. They are also really long
reads. There are also some books that are equivilent. The information
they contain is what we really need.

Then you should *really* demand that candidates have read those books,
because it also allows candidates to get an idea of whether the company is a
good fit for *them*. If I were presented with a job that really emphasized
that I have to have read those books, I'd conclude that the company is too
enterprisey for its own good and I would probably look around for something
else, and this would be better for both of us.

 

[Paul]

I carried out a major project for an ISP in my last job where several
developers in different location had been working on a project for several
months. The Lead developer had since left and I was approached to become the
lead on this project and given a 2/3 month deadline. needless to say 7
months worth of work had been done from specs from the back of a postage
stamp and had to be scrapped, not only that but the diferent teams had
created elements of software that needed to interact but had not dicussed
intefaces between the software, yes they would never have worked.

Anyway I did the design and had to implement startegies and factories
throughout as specs still were not finalised. Luckily this design made the
app flexible enough to cope with any changes from our perception of the
project to the final requirements.

Anyway I had developers with different skills on board and all class
structure had been created by myself. The developers with a C++ background
were a nightmare to get to follow any pattern and kept creating amazing
stuff (re-use is not big on C++ developers minds me thinks) that just had to
be re-written, whereas the .net/vb background programmers could be given a
problem and would solve it within the guidlines of the class structure and
..net framework that had been laid out for them. So do I care if someone can
describe to me how a hashtable works in the background? No I could not give
a damn, someone with an ounce of business knowledge coupled with a good head
for solving business problems using .NET can work with me anyday.

Anyway I have read a few of those book but the main rule that stands for me
is that complexity is the devil give me someone who will solve a problem
simply and ably the same way everytime rather than some genius that creates
unreadable, unmanagable code that changes with the wind, and yes I probably
learnt that the hard way in my career. I would be suprised if most people do
not, sometimes it takes been given responsibility to realise.

BTW I know some that would say patterns are unreadable and unmanagable but I
put that down to their lack of understanding. ;-)

I also tend to write applications to spec and with little to no support
issues, and I put that down to the light in the tunnel of my development
career - USE CASES and PATTERNS and I have to agree the book by Larman is a
revelation. I however have never used TDD and I also have never come accross
an implementation of TDD where all TDD tests passing has resulted in Use
Case testing actually working, so I resort back to Keep it Simple Stupid and
carry on with what I know works. Im sure I will get flamed for that but hey
as long as my employers are happy with the results, Im also happy.

 

[Paul]

I carried out a major project for an ISP in my last job where several
developers in different location had been working on a project for several
months. The Lead developer had since left and I was approached to become the
lead on this project and given a 2/3 month deadline. needless to say 7
months worth of work had been done from specs from the back of a postage
stamp and had to be scrapped, not only that but the diferent teams had
created elements of software that needed to interact but had not dicussed
intefaces between the software, yes they would never have worked.

Anyway I did the design and had to implement startegies and factories
throughout as specs still were not finalised. Luckily this design made the
app flexible enough to cope with any changes from our perception of the
project to the final requirements.

Anyway I had developers with different skills on board and all class
structure had been created by myself. The developers with a C++ background
were a nightmare to get to follow any pattern and kept creating amazing
stuff (re-use is not big on C++ developers minds me thinks) that just had to
be re-written, whereas the .net/vb background programmers could be given a
problem and would solve it within the guidlines of the class structure and
..net framework that had been laid out for them. So do I care if someone can
describe to me how a hashtable works in the background? No I could not give
a damn, someone with an ounce of business knowledge coupled with a good head
for solving business problems using .NET can work with me anyday.

Anyway I have read a few of those book but the main rule that stands for me
is that complexity is the devil give me someone who will solve a problem
simply and ably the same way everytime rather than some genius that creates
unreadable, unmanagable code that changes with the wind, and yes I probably
learnt that the hard way in my career. I would be suprised if most people do
not, sometimes it takes been given responsibility to realise.

BTW I know some that would say patterns are unreadable and unmanagable but I
put that down to their lack of understanding. ;-)

I also tend to write applications to spec and with little to no support
issues, and I put that down to the light in the tunnel of my development
career - USE CASES and PATTERNS and I have to agree the book by Larman is a
revelation. I however have never used TDD and I also have never come accross
an implementation of TDD where all TDD tests passing has resulted in Use
Case testing actually working, so I resort back to Keep it Simple Stupid and
carry on with what I know works. Im sure I will get flamed for that but hey
as long as my employers are happy with the results, Im also happy.

 

[jehugaleahsa]

Thank you for your opinions, experiences and insights. I know it is
hard to write anything remotely negative without getting flamed for
it. For instance, I thought I was really careful to say things like,
"The information they contain is what we really need," and I still got
nailed for it.

The original post was brought on by an interviewee we talked to
yesterday. He had attended a Master's C# program (I'm not sure what
that is). He knew most of the C# trivia (and that is exactly what it
was), but he didn't really have much to say about OOP or algorithms.

One of the questions: "What is a fast way to find a value in a sorted
list." It is pretty generic. I don't necessarily say its a .NET
List<T> or a C++ List<T>. We've been getting all kinds of interesting
answers (but not one that sounded confident). "A linear search." "I'd
create some kind of Dictionary." These are at least answers. The
linear search scares me, but at least he/she was trying. The
Dictionary shows that the person knows about the class, but that he/
she don't have formal training. I can't discard someone because he/she
didn't take up a CS degree. I think something like 50% of programmers
aren't formally trained. It is also really hard to gauge someone's
skill set over the phone.

Statistics (found in Steve McConnell's Code Complete (a man who's way
too opinionated in my opinion )) cited that good programmers are as
much as 10 times as productive as novices. 10 TIMES! I sure don't want
to get the wrong person. As far as I am concerned, that type of
productivity will slow me down. We are pressed for time as it is.

Joel Spolsky says you shouldn't hire anyone if you're not sure (and
you're a big rich private company). His book has some helpful, yet
somewhat unrealistic, tips for hiring someone. It's a good book to
read if you want to get hired. Too many employers read it and take it
as God's truth and hire anyone who follows the recipe inside. They
obvious really concentrate on the part about not giving trivia
questions but totally miss the part of about testing their problem
solving abilities. If someone doesn't know how to loop through the
numbers 1 through 10, they don't and it's not something they can pick
up quickly.

We are really looking for two things: 1) Someone who knows the .NET
platform and 2) someone we know can take our software and adopt our
coding standards and practices. I'd be willing to give 6 months (half
a stinking year) to allow someone to catch up. They've really got a
challenge ahead of them. They'd have to become familiar with some more
of the advanced .NET concepts (generics, nullables, async delegates,
etc.). They have to become familiar with a basic understanding of OOP
and design patterns. They have to learn enough about the business to
understand the code and the process (I'm still learning it).

The more they have to learn, the more I realize we need someone with
experience in .NET. A Java programmer might be okay. A C++ programmer
with a strong background in OOP may be okay. I also realize that OOP
and design patterns take experience and time to absorb, and six months
probably won't be enough time to grasp (from no experience at all)
enough to get by in our system.

Pete can contest to the number of posts I've had asking how to do
something dealing with performance. Even though performance is
irrelevant to 90% of our system, that 10% is sink or swim. So it would
be nice to know that the person coming in at least knew _something_
about which algorithms and data structures to use for those
situations. I can't expect them to know how to implement the code, but
to know which .NET classes should *probably* be used would be
preferred.

Craig Larman's book really is a great book (not a plug). It does focus
more on the agile side of development. It does have awesome
explainations for moving from use cases to software systems. It even
touches on UML and design patterns. OOP is becoming the standard
development methodology. Real-time programs, embedded programs and
scripts are some of the last categories of software that can make more
sense to be implemented in a procedural manner. Understanding the
_principles_ behind GRASP are really important for modern large-scale
programs. Whether you know of it as GRASP or not is irrelavent.

So, IMHO, I don't want someone whose experience is limited to moving
data between Excel and Word in VBA or writing small, web-based
applications. I need someone with experience with large object-
oriented programs. However, it seems that no matter how blunt you are
in explaining that, you still get a large number of hackers. We'll
just have to make the filtering process more strict. Sorry for making
anyone disgruntled.

 

[jehugaleahsa]

Thank you for your opinions, experiences and insights. I know it is
hard to write anything remotely negative without getting flamed for
it. For instance, I thought I was really careful to say things like,
"The information they contain is what we really need," and I still got
nailed for it.

The original post was brought on by an interviewee we talked to
yesterday. He had attended a Master's C# program (I'm not sure what
that is). He knew most of the C# trivia (and that is exactly what it
was), but he didn't really have much to say about OOP or algorithms.

One of the questions: "What is a fast way to find a value in a sorted
list." It is pretty generic. I don't necessarily say its a .NET
List<T> or a C++ List<T>. We've been getting all kinds of interesting
answers (but not one that sounded confident). "A linear search." "I'd
create some kind of Dictionary." These are at least answers. The
linear search scares me, but at least he/she was trying. The
Dictionary shows that the person knows about the class, but that he/
she don't have formal training. I can't discard someone because he/she
didn't take up a CS degree. I think something like 50% of programmers
aren't formally trained. It is also really hard to gauge someone's
skill set over the phone.

Statistics (found in Steve McConnell's Code Complete (a man who's way
too opinionated in my opinion )) cited that good programmers are as
much as 10 times as productive as novices. 10 TIMES! I sure don't want
to get the wrong person. As far as I am concerned, that type of
productivity will slow me down. We are pressed for time as it is.

Joel Spolsky says you shouldn't hire anyone if you're not sure (and
you're a big rich private company). His book has some helpful, yet
somewhat unrealistic, tips for hiring someone. It's a good book to
read if you want to get hired. Too many employers read it and take it
as God's truth and hire anyone who follows the recipe inside. They
obvious really concentrate on the part about not giving trivia
questions but totally miss the part of about testing their problem
solving abilities. If someone doesn't know how to loop through the
numbers 1 through 10, they don't and it's not something they can pick
up quickly.

We are really looking for two things: 1) Someone who knows the .NET
platform and 2) someone we know can take our software and adopt our
coding standards and practices. I'd be willing to give 6 months (half
a stinking year) to allow someone to catch up. They've really got a
challenge ahead of them. They'd have to become familiar with some more
of the advanced .NET concepts (generics, nullables, async delegates,
etc.). They have to become familiar with a basic understanding of OOP
and design patterns. They have to learn enough about the business to
understand the code and the process (I'm still learning it).

The more they have to learn, the more I realize we need someone with
experience in .NET. A Java programmer might be okay. A C++ programmer
with a strong background in OOP may be okay. I also realize that OOP
and design patterns take experience and time to absorb, and six months
probably won't be enough time to grasp (from no experience at all)
enough to get by in our system.

Pete can contest to the number of posts I've had asking how to do
something dealing with performance. Even though performance is
irrelevant to 90% of our system, that 10% is sink or swim. So it would
be nice to know that the person coming in at least knew _something_
about which algorithms and data structures to use for those
situations. I can't expect them to know how to implement the code, but
to know which .NET classes should *probably* be used would be
preferred.

Craig Larman's book really is a great book (not a plug). It does focus
more on the agile side of development. It does have awesome
explainations for moving from use cases to software systems. It even
touches on UML and design patterns. OOP is becoming the standard
development methodology. Real-time programs, embedded programs and
scripts are some of the last categories of software that can make more
sense to be implemented in a procedural manner. Understanding the
_principles_ behind GRASP are really important for modern large-scale
programs. Whether you know of it as GRASP or not is irrelavent.

So, IMHO, I don't want someone whose experience is limited to moving
data between Excel and Word in VBA or writing small, web-based
applications. I need someone with experience with large object-
oriented programs. However, it seems that no matter how blunt you are
in explaining that, you still get a large number of hackers. We'll
just have to make the filtering process more strict. Sorry for making
anyone disgruntled.

 

[Arne Vajhøj]

Should the average programmer, like a full-time programmer, know when
to use a Binary Search? Should a serious programmer at least know what
it is? Not so much the name, but at least how it works...?

Yes and yes.

Should they know when to use a Dictionary? I think they should.

They should know when to use a hash based lookup and be smart
enough to check if it is already in the standard library.

It is less important that they know about
System.Collections.Generic.Dictionary (even though I would
be a bit skeptical about a .NET programmer that did not remember
the name, because it is such a common class).

I know a lot of people think that you shouldn't expect a programmer to
know trivial things. However, I don't think data structures and
algorithms are something you can really afford to overlook. Sure, I
don't expect someone to be able to implement them, but I do expect
them to know _when_ to use them.

Algorithms are data structure are not trivial - it is core.

So how can you tell if someone is knowledgable... and experienced? Is
it wrong for us to disregard someone because they aren't familiar with
the tools in our environment? We need someone who can hit the ground
running. We can't afford to waste the time to teach someone how to
program in Visual Studio and C#. We can't afford to redo all of their
work because they don't understand the principles behind our
development process and coding standards. I don't think we are being
unfair, by any means.

Most people can learn VS and C#.

Learning good design is much more difficult.

Another hard question is: if someone is very knowledgeable about C#
but doesn't have first-hand experience with design patterns and
software architecture, can we bring them up to speed?

If they know C# and has a decent theoretical background then
go ahead.

Knowledge about design patterns is just one of many skills.

And for gods sake avoid anyone right out of school that
claims to be an expert in software architecture.

It would be nice to find someone who had read these books:

Gang of Four (maybe)
Patterns of Enterprise Architecture (definitely)
Applying UML and Patterns (preferrably)
xUnit Test Patterns (maybe)

Yep.

I would consider #1 and #3 most important.

The topics in #2 should come later.

And #4 is more specific.

They literally changed the way I program. They are also really long
reads. There are also some books that are equivilent. The information
they contain is what we really need. Unfortunately, I think most
people who understand these books are getting paid a lot more than we
can afford to pay. I can always lend these to whomever we do hire.

If your software is of high complexity, then hiring few good programmers
(and paying them well) may be a lot cheaper than hiring a lot of bad
programmers no matter how cheap they are.

Arne

 

[Arne Vajhøj]

Should the average programmer, like a full-time programmer, know when
to use a Binary Search? Should a serious programmer at least know what
it is? Not so much the name, but at least how it works...?

Yes and yes.

Should they know when to use a Dictionary? I think they should.

They should know when to use a hash based lookup and be smart
enough to check if it is already in the standard library.

It is less important that they know about
System.Collections.Generic.Dictionary (even though I would
be a bit skeptical about a .NET programmer that did not remember
the name, because it is such a common class).

I know a lot of people think that you shouldn't expect a programmer to
know trivial things. However, I don't think data structures and
algorithms are something you can really afford to overlook. Sure, I
don't expect someone to be able to implement them, but I do expect
them to know _when_ to use them.

Algorithms are data structure are not trivial - it is core.

So how can you tell if someone is knowledgable... and experienced? Is
it wrong for us to disregard someone because they aren't familiar with
the tools in our environment? We need someone who can hit the ground
running. We can't afford to waste the time to teach someone how to
program in Visual Studio and C#. We can't afford to redo all of their
work because they don't understand the principles behind our
development process and coding standards. I don't think we are being
unfair, by any means.

Most people can learn VS and C#.

Learning good design is much more difficult.

Another hard question is: if someone is very knowledgeable about C#
but doesn't have first-hand experience with design patterns and
software architecture, can we bring them up to speed?

If they know C# and has a decent theoretical background then
go ahead.

Knowledge about design patterns is just one of many skills.

And for gods sake avoid anyone right out of school that
claims to be an expert in software architecture.

It would be nice to find someone who had read these books:

Gang of Four (maybe)
Patterns of Enterprise Architecture (definitely)
Applying UML and Patterns (preferrably)
xUnit Test Patterns (maybe)

Yep.

I would consider #1 and #3 most important.

The topics in #2 should come later.

And #4 is more specific.

They literally changed the way I program. They are also really long
reads. There are also some books that are equivilent. The information
they contain is what we really need. Unfortunately, I think most
people who understand these books are getting paid a lot more than we
can afford to pay. I can always lend these to whomever we do hire.

If your software is of high complexity, then hiring few good programmers
(and paying them well) may be a lot cheaper than hiring a lot of bad
programmers no matter how cheap they are.

Arne

 

[Arne Vajhøj]

Me too. Some people get too wrapped up in new methodologies...

The first 3 are rather broad in their topic.

Arne

 

[Arne Vajhøj]

Me too. Some people get too wrapped up in new methodologies...

The first 3 are rather broad in their topic.

Arne

 

[Arne Vajhøj]

It is in my opinion like the mystic around boxing an even more than the
latter from the first days of programming.

That are not anymore the bottlenecks in programming.

Good algorithms and data structures are still important for
good performance.

And even though good implementations exist in the standard libraries
today then understanding which and when requires some basic
understanding of how they work.

Using bad graphics
on a screen can make programs slow.
As 99% of the solutions are related to graphics, that is more a point of
view.

I am bit skeptic about that 99% for general C# programming.

Arne

 

[Arne Vajhøj]

It is in my opinion like the mystic around boxing an even more than the
latter from the first days of programming.

That are not anymore the bottlenecks in programming.

Good algorithms and data structures are still important for
good performance.

And even though good implementations exist in the standard libraries
today then understanding which and when requires some basic
understanding of how they work.

Using bad graphics
on a screen can make programs slow.
As 99% of the solutions are related to graphics, that is more a point of
view.

I am bit skeptic about that 99% for general C# programming.

Arne

 

[J.B. Moreno]

One of the questions: "What is a fast way to find a value in a sorted
list." It is pretty generic. I don't necessarily say its a .NET
List<T> or a C++ List<T>. We've been getting all kinds of interesting
answers (but not one that sounded confident). "A linear search." "I'd
create some kind of Dictionary." These are at least answers. The
linear search scares me, but at least he/she was trying. The
Dictionary shows that the person knows about the class, but that he/
she don't have formal training. I can't discard someone because he/she
didn't take up a CS degree. I think something like 50% of programmers
aren't formally trained. It is also really hard to gauge someone's
skill set over the phone.

The question is actually too generic -- is it a linked list, a double
linked list, an array masquerading as a list, something else? If the
list is an IEnumerable<T> or a SortedList it doesn't have an index and
without an index....

Instead of asking what is, ask them to do: "I'm thinking of a number
between 1 and 100"...

 

[J.B. Moreno]

One of the questions: "What is a fast way to find a value in a sorted
list." It is pretty generic. I don't necessarily say its a .NET
List<T> or a C++ List<T>. We've been getting all kinds of interesting
answers (but not one that sounded confident). "A linear search." "I'd
create some kind of Dictionary." These are at least answers. The
linear search scares me, but at least he/she was trying. The
Dictionary shows that the person knows about the class, but that he/
she don't have formal training. I can't discard someone because he/she
didn't take up a CS degree. I think something like 50% of programmers
aren't formally trained. It is also really hard to gauge someone's
skill set over the phone.

The question is actually too generic -- is it a linked list, a double
linked list, an array masquerading as a list, something else? If the
list is an IEnumerable<T> or a SortedList it doesn't have an index and
without an index....

Instead of asking what is, ask them to do: "I'm thinking of a number
between 1 and 100"...

 

[Cor Ligthert[MVP]]

Arne,

System.Collections.Generic.Dictionary (even though I would
be a bit skeptical about a .NET programmer that did not remember
the name, because it is such a common class).

First I had the idea to write only,

Arne what is a generic dictionary and why has it to be generic?

You wrote as a reply to me, that you had doubt if 99% of programming was
currently done around graphics.

It is something I didn't investigate and I think it can even not be
worldwide investigated, because as it is not like that it is rapidly going
in that direction.
Keep in mind that Internet and games are as well all around graphics and
that is currently a main part of the industry.

It can be that for games a binary search can be important, but guys like me
who are mainly working with databases are not using all kind of
intermediates. They rely on the tools they get like Linq or AdoNet which
give us enough . Using extras, which seems to make things faster slow in
fact only things down.

Don't misunderstand me, I know what they are, but I wont tell that it is for
everybody a must to know.
I just know it because that I can place all those things in their historical
evolution, from courses I have done and have seen persons endless discussing
about that.

But you should be happy that you don't have to learn all those things I had
to learn in this business and have never used.

Cor