Re: OT: Binary Search - Should They Know It?
- From: Henry <greenclay@xxxxxxxxxxxxx>
- Date: Wed, 20 May 2009 23:59:38 -0400
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.
jehugaleahsa@xxxxxxxxx wrote:
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.
- References:
- OT: Binary Search - Should They Know It?
- From: jehugaleahsa@xxxxxxxxx
- OT: Binary Search - Should They Know It?
- Prev by Date: RE: Reflection of Enum and cannot get TypeOf original Type
- Next by Date: displaying string-array elements as read-only (grayed) in propertygrid
- Previous by thread: Re: OT: Binary Search - Should They Know It?
- Next by thread: Re: Binary Search - Should They Know It?
- Index(es):
Relevant Pages
|
