The Artima Developer Community
Sponsored Link

Weblogs Forum
Hiring the Rowing-Forward 30%

54 replies on 4 pages. Most recent reply: Jun 13, 2008 7:56 AM by Patrick Band

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 54 replies on 4 pages [ « | 1 2 3 4 ]
Kiran Shimpi

Posts: 1
Nickname: kshimpi
Registered: Apr, 2008

Re: Hiring the Rowing-Forward 30% Posted: Apr 19, 2008 12:00 AM
Reply to this message Reply
Advertisement
Forget it - Good guys have no future. Only people who show off have their future instilled in corporate world.

Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Re: Hiring the Rowing-Forward 30% Posted: Apr 19, 2008 12:22 PM
Reply to this message Reply
> (worrying about whether a candidate
> prefers vi or emacs makes for a bad team member is the
> sort of near-sighted pettiness I never expected to hear
> from Mr. Eckel, by the way)

Not sure how you translated "prefer" from "If a programmer is hardwired to only use emacs or vi (for example) and could never consider using anything else..."

So if I wasn't clear, I'm not talking about preference. I'm talking about whether you can change, or if you've decided that everything you already know is all you ever need or want to know.

Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Re: Hiring the Rowing-Forward 30% Posted: Apr 19, 2008 12:24 PM
Reply to this message Reply
> Trying to get back on topic...
>
> In my experience, many programmers get fanatic about
> something, like RDBs, "proper use of MVC", TDD, Eclipse
> RCP, applying every pattern in the book even if irrelevant
> and confusing. Even if not fanatic, they get focused on
> certain things.
>
> This is all rowing, not necessarily backwards, but in some
> direction that isn't the solution. In an idea world, the
> manager could combine resourses so that the sum of their
> vectors is forward.

Good point. Identifying people who are rowing backward is relatively easy compared to rowing on a tangent. What do you do when somebody is going in approximately the right direction but steadily, and determinedly, diverging?

Eivind Eklund

Posts: 49
Nickname: eeklund2
Registered: Jan, 2006

Re: Hiring the Rowing-Forward 30% Posted: Apr 21, 2008 12:24 AM
Reply to this message Reply
[About what has happened for me when I've been able to push aspects of the relational model - not SQL, but relations - through my system]

> > I have simplified dealing with data quite a lot, and I
> > have been able to do quite a bit of code generally
> instead
> > of having to repeat code.
> >
> > There is less information about how various tables are
> > related etc in the system than before, as relations are
> > pushed through the system and manipulated instead of
> > building queries against the database at each point.
>
> OK. I'll buy that this could make it much easier to get
> data to the code (I don't want to say query, because I
> think that's not quite right) in a lot of circumstances.
> What I don't buy is that this fundamentally changes the
> e difficulty build the systems that act upon or otherwise
> use this data. I don't think that you are arguing that it
> does so I'm not sure we are in disagreement.

I don't think we are.

To me, "fundamentally changes" would be a large quantitative change; what I'm seeing is (guesstimate) maybe 2-3% improvement overall for my app, with the advantage that these 2-3% are somewhat concentrated in making the app more easily changed and managed. It isn't the world, it's just a nice benefit, which I expect to be slightly larger for a complete implementation.

Eivind.

Florin Jurcovici

Posts: 66
Nickname: a0flj0
Registered: Feb, 2005

Re: Hiring the Rowing-Forward 30% Posted: Apr 21, 2008 2:19 AM
Reply to this message Reply
> Employers always wonder if the employees are good enough
> or not. But really they should be asking themselves, "Am
> I a good employer? Why should anyone work with me?"
RIGHT!!! But then, this would mean there's a company being
well managed, and this, in my experience, is quite seldom.

Could this be so because the natural selection process for
companies is waaaaaay to soft?

> From what I understand, no one is randomly toxic. The
> difference is in how various people respond to abuse.
> When you abuse people they respond differently (not in
> no any particular order):
Disagree on that. Unfotunately, there are ppl who are toxic
in just about any environment, even if they aren't abused
at all. IMO, it has to do with education - not the professional
knowledge they got in various schools, but the social skills
they acquired while growing up.

If somebody becomes toxic at one company, then switches to
another one, he'll usually keep the poison for maybe several
years. If somebody became intoxicated earlier, during school,
maybe in the family or in the neighborhood, it may take a lifetime
to detox him.

> That said, I believe the interview process is something
> that's going to go away. You simply cannot interview for
> good programmers. You have to see them work. The best
> way to hire a good programmer is to simply see them work
> for a while. You have to find a way to arrange it. If
> you cannot find a way to do it, you lose. Those who
> figure out how to hire programmers without interviews, but
> rather, by actually putting them to work, will win.

We usually organize a test, after each interview. The test consists
of something any reasonable programmer could do in maybe two hours,
but the time granted is up to four hours. We try to make the test
look as much alike with real work as possible - i.e. we talk to the
ppl during the test, look at what they did, discuss alternatives with
them, etc. At the end, we have worked a little with the potential new
employee, and also have a short piece of code to analyze. Would/could
this work for you?

But IMO the interview won't go away. It's the best way to assess the
social, non-professional aspects of a job seeker. After all, an interview
means communicating, and communication is what makes a good or bad fit
into a team.

Maybe the interview process at your company is flawed? I have seen several
situations (mostly in multinationals, but not exclusively) in which only the
third or fourth interview actually gets you face to face with ppl you will
actually work with, in which stupid HR ppl scare you off with stupid remarks
about payment, or make you sick with how wonderful the company you consider
working for is, and so on. I surely agree that this sort of interview should
go away. Nevertheless, human stupidity being in no short supply, I doubt they
ever will.

Florin Jurcovici

Posts: 66
Nickname: a0flj0
Registered: Feb, 2005

Re: Hiring the Rowing-Forward 30% Posted: Apr 21, 2008 3:30 AM
Reply to this message Reply
> The relational model is not about tables, that's just an
> artifact of SQL implementation, currently. There are, as
> yet niche, RM databases which are column stores. Whatever
> can be specified in hierarchical/network terms can be
> built better (more compactly and efficiently) in a
> relational database. One does need some training to know
> that.
>
> Dr. Codd proved, since he was out to skewer IMS (aka, xml
> in today's jargon), that the relational model of data was
> not only the best, but first, model of data. The
> hierarchical (xml) and network (sorta kinda, object)
> databases of the time were passive stores for the code,
> generally COBOL, with a bit of PL/1 to the side. It's the
> ignorant younguns who, not having done or studied
> databases, think that xml (the usual suspect, but OODBMS
> too) is some brand new magic bullet. It is not. It is a
> proven dead end.
Ugh! Extremism! IMO, stating that OODBMSs are a dead end is plainly wrong. It all depends on what you are using it for. I have a hard time believing that the native, hierarchical database traditionally used for directories is a worse solution than a relational one. I'm sure there are other examples too.

You probably wanted to say that relational databases have a far wider domain of applicability. This I can agree to.

> Those who ignore the past are doomed to repeat it. And so
> it is in IT; perhaps more than most other "professions".
> I mean, would any civil engineer now build a bridge in
> the manner of the Brooklyn one? That way was abandoned,
> for good reason. But IT folk will hype old wine in new
> bottles, if they see a way to make a buck; or lack the
> smarts to understand the math.

:-) This, IMO, has something to do with IT being comparatively a pretty young field, on one hand, and on the other hand being significantly different than other, more established, engineering domains. Not (only) with the vast majority of programmers being not quite as good as they should be.

> The notion that xml is a data model is false. But one
> needs to have read the history of data and data models (as
> distinct from specifications). xml is a specification.
> It has no algebra.
>
> The point of my comment, in context of the OP, is that by
> returning to the thrilling days of yesteryear where data
> is subsumed to (by definition) client code, we return to
> the bad old days of fragile data. Worrying about *coders*
> is the problem. Coders view data as mud, to be shaped as
> they see fit. For some kinds of systems (games, for
> example) this is fine. For multi-user, transaction driven
> systems, this is the wrong question. For such systems to
> be robust, the data must have precedence. Clients only
> draw pictures of the data.

You say it yourself! It all depends for what you do the app.

Could it be that you you mean only a subset of all enterprise-level apps being developed/used nowadays?

The apps we usually do are ones with highly dynamic data models, with ever changing requirements, and I can tell you for sure that relational databases simply get in the way. Unfortunately, there's no real alternative (OODBMSs are way to weak, in what functionality we could use) to RDBMSs, so we have to use ORM tools/frameworks/toolkits/libraries.

However, there are also occasional projects where we know that the amount of data will be small, the user will typically be working with maybe a few dozen objects at a time, not more, and most of the work will be done offline - the highly dynamic evolution of the data model staying just the same. Now what use would be a relational database be in such an app?

> The cure is to seek and employ smart data folk, whenever
> the system is multi-user, transactional, and has a need
> for "data persistence". That's not all systems, just the
> ones that matter.

I think this is way overstated. Why would anybody pay for systems that don't matter?

> To the extent that au courant buzzwords like SOA and RIA
> get managers and the like thinking that they can ignore
> the database's natural control of the data, and have
> "intelligent clients" reading and writing where they will
> when they will; there lies the path of perdition.

I guess you are a bit behind some issues in the industry - the business issues. I'd really love to see you develop an app integrating about a dozen data sources, each with its own access technology, then maintain the app with minimal effort while the data sources keep changing technology and structure. And do this without some decoupling layers (let's call them services) in betwen.

Just an example: my company buys us lunch every day. Our caterer publishes the weekly menu on the web. We need to do weekly orders, but there's no such facility provided by the caterer. Even if it was, the caterer would probably be unwilling to manage company and employee accounts for each of his customers. You can be darn sure the caterer needs a proper database containing all orders for one week ahead. Nevertheless, what's the use of this database to us? Do you think we will ever get access to it, in order to develop an app siting atop of it, so we can order online? That's where web services have their place, and where nothing else (IMO) can do a better job. We did an app which reads the weekly menu from the web, publishes it internally, lets all employees place the orders, then, only when time is due, places the order for next week.

Could you call this app critical? I guess not - we could surely do the ordering by mail, if there was no other way. But doing it this way saves time, both for the caterer and for us. And you know, time is money.

Eivind Eklund

Posts: 49
Nickname: eeklund2
Registered: Jan, 2006

Re: Hiring the Rowing-Forward 30% Posted: Apr 21, 2008 3:49 AM
Reply to this message Reply
> But IMO the interview won't go away. It's the best way to
> assess the social, non-professional aspects of a job
> seeker. After all, an interview means communicating, and
> communication is what makes a good or bad fit into a team.

According to psychology (both what references I have come across reading psychology and according to a friend of mine that's a certified psychologist specializing in personality testing and work as professional head hunter), this is incorrect. People believe they can add something to a hiring process by running interviews, and in reality, basing things on anything else is better.

The ability to interview well seems to be negatively correlated with being able to do the job - even astrology does a better job, because it adds in randomness to counter the tendencies from the interview.

I find this intriguing, and at the very least food for thought. I'd be uncomfortable hiring somebody without an interview - but knowing that science seems to say interviews doesn't work, I'd preferably do an interview as a reject process rather than an accept process (ie, if somebody looks good after tests and interview horribly, I might reject them even though the tests says otherwise.)

Eivind.

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: Hiring the Rowing-Forward 30% Posted: Apr 21, 2008 3:49 AM
Reply to this message Reply
> for. I have a hard time believing that the native,
> hierarchical database traditionally used for directories
> is a worse solution than a relational one. I'm sure there
> are other examples too.
I think the complaint is that the heirarchical directory itself is the mistake however it is stored. Allegedly half the population can't reliably manage such structures. So while I don't need a search engine to find files on my computer, many people do find them useful.

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: Hiring the Rowing-Forward 30% Posted: Apr 21, 2008 6:11 PM
Reply to this message Reply
> Good point. Identifying people who are rowing
> backward is relatively easy compared to rowing on a
> tangent. What do you do when somebody is going in
> approximately the right direction but steadily, and
> determinedly, diverging?

I'm brainstorming here, don't have all that much experience or success in doig this...

To avoid backwards rowers, somehow you need to identify people who are flexible enough to adapt and not one-track fanatics. Look for a broad (but not ridiculous "I'll list every buzzword") resume. If somebody in an interview keeps coming back to one particular thing, that's a red flag. If they mention Dr. Coad in every Artima post, that's a red flag.

For getting the tangential people rowing forward, chalenge their assumptions. They want to use JBOSS. They want to use Spring for DIP. Why? Does it help serve a SW requirement? Or is it to support mocks to support TDD to support a SW requirement? If the latter, is it worth the hassle? Maybe it is, this is not a knock on Spring, but by challenging their technology assumptions it reminds them that we are really building a WidgetOrderProgram, not unit tests or some Widget messaging system.

Patrick Band

Posts: 3
Nickname: bantri
Registered: Jun, 2008

Rowing against the tide Posted: Jun 13, 2008 7:56 AM
Reply to this message Reply
Interesting topics... Thx

Flat View: This topic has 54 replies on 4 pages [ « | 1  2  3  4 ]
Topic: Hiring the Rowing-Forward 30% Previous Topic   Next Topic Topic: Testing without setup and tearDown

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use