Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Have you ever regretted hiring a developer?

news.ycombinator.com

Post reply on HN
Print view View original

91–100 of 114 posts

Re: Ask HN: Have you ever regretted hiring a developer?

#91

Post by tonyedgecombe »

celdon25 wrote: post #33
brianwawok wrote: post #21

Earlier quoted context omitted.

You are implying there is a downside. In my example they are the same in all aspects you measure.

Since all other things are equal, the solution is simple. The person with the degree is more likely to have student loan debt, so a salary of X dollars per year will go further in the case of the one without the debt. The person with the debt is more likely to require more money for the same level of satisfaction. All other things being equal, of course.

Also everybody else would choose the degree candidate so you have no competion for the other, you are likely to get them for less money and they will be more loyal.

However I suspect there is very little rationality in hiring, even amongst this community.

Re: Ask HN: Have you ever regretted hiring a developer?

#92

Post by pcurve »

brogrammernot wrote: post #38
pcurve wrote: post #36

Earlier quoted context omitted.

Other than hiring someone as contractor first, have a trial run for 6 months, what do you think is a good way to minimize issues like this?

Re: trial run. I do not suggest this. I'm not a world class developer, but I'm a good one, maybe great depending on the day but I had 3 offers to be contract to hire and I refused. You may save yourself a bad hire, but more than likely you will do so at the cost of missing out on hiring a handful of good ones. If I'm interviewing with you and you don't trust me enough to make me an employee from day one then why shou…

I agree. Good ones always have good options. I avoid contract to hire, because even a talented developer who chooses to stay as contractor will avoid contract-to-hire positions.

I guess you just have to go with who you think is the best candidate, and if the decision turns out to be incorrect, fire quickly.

Re: Ask HN: Have you ever regretted hiring a developer?

#93

Post by always_good »

celdon25 wrote: post #33
brianwawok wrote: post #21

Earlier quoted context omitted.

You are implying there is a downside. In my example they are the same in all aspects you measure.

Since all other things are equal, the solution is simple. The person with the degree is more likely to have student loan debt, so a salary of X dollars per year will go further in the case of the one without the debt. The person with the debt is more likely to require more money for the same level of satisfaction. All other things being equal, of course.

Seems like you're really stretching it.

The one that went to uni probably got laid a lot more, too. So as they're working in an office space with no women and possibly not meeting any women on the side, they are less likely to have a social crisis when they're working their 60th hour of the week.

This is kind of fun!

Re: Ask HN: Have you ever regretted hiring a developer?

#94

Post by omidfi »

wheelerwj wrote: post #57

This is an interesting question, because it signals that you are most likely very new to hiring, and maybe ill-equipped to handle managing people in general. Although, at least you're asking questions. First, very rarely does a manager regret a hire even though it's very common for a hire not to work out. Hiring and interviewing are in terrible shape right now, and more often then not lead to terrible hiring/job acce…

Thank you for your insightful comment.

You're right,this is new for me. But fortunately I'm not making decisions, or managing people at the moment. I'm just learning.

I'll check out the books.

Re: Ask HN: Have you ever regretted hiring a developer?

#95

Post by zepolen »

scarface74 wrote: post #77
zepolen wrote: post #14

Earlier quoted context omitted.

Meh, takes me back to a couple years ago when the MEAN stack was all the rage, I was pointing out flaws/problems which would arise from: - Mongo not having a schema, relations - Angular having a fundamentally flawed update system But of course the argument was that 'MEAN is what everyone is using, its easy to find MEAN developers'. Sure, if you mean it's easy to find kids who learnt how to make apps, via a MEAN stack…

I'm relatively new to Mongo and I've only used it in C#. But a few points: I would only use Mongo as a backing store for a micro service. All access would be through one service that enforced business rules, data integrity, and would be responsible for exposing business objects/aggregate roots. App servers are a lot cheaper/easier to scale than database servers. By keeping all of the logic in the business tier, it's…

See, what you just posted is a typical response which tries to justify Mongo, even though you yourself have little experience with it!

Fine, I'll bite:

> All access would be through one service that enforced [rules, integrity]

That's a very good idea; you just described what a database is. Now why take it upon yourself (and team) to reimplement that yourself when there exist quite a few that have had thousands of programmer years scrutinizing every detail to create the most robust and optimized systems... these are much better programmers than you or I for this job, these guys eat shit and live databases.

> App servers are a lot cheaper/easier to scale than database servers. By keeping all of the logic in the business tier, it's a lot easier to scale/load balance.

Ah there it is, the typical FUD, by moving everything out of the 'database', you can scale.

Nope, that's not true.

The only thing that doesn't scale easily with a database server is joins - In all other cases it's possible to (even with an rdbms) scale infinitely via sharding. In fact there are many implementations that do so, and they are usually faster than Mongo.

Now onto joins, these get implemented in the "app server" by the inexperienced developer in 2 ways:

A. Real joins using normalized data

1. generates a ton of network congestion from getting the data

2. ton of cpu because because json decoding/encoding

3. ton of cpu because scripting languages vs optimized C

4. the use of O(shit) algorithms to make the joins

5. inconsistencies when things fail like network or disk or shutdown

B. Redundant data

1. use a ton of memory/disk

2. create deferred overheads in order to keep things sync

3. despite that, end up with inconsistent data all over the place

4. wont actually be faster or scalable(!!!)

In both cases they end up creating a bottleneck once you start caring about concurrent access not messing up your data.

Watching Mongo evolve is like watching the past 30 years of rdbms - which started out as flat text files which were 'fast and simple' - gaining indexes, efficient datastructures, foreign keys, disaster recovery etc.

But it's all good, and I can't complain, I make a killing putting out fires caused by badly architected systems.

Re: Ask HN: Have you ever regretted hiring a developer?

#96

Post by shshhdhs »

pryelluw wrote: post #63
dilap wrote: post #50

Earlier quoted context omitted.

The perfect code guy doesn't sound so bad.

Until you ship a product so late that its declared DOA. Perfect coders are more dangerous than shitty ones. They usually slow down progress in the name of perfection so much that nothing gets done. IMO.

For a startup, sure. But the machine doing LASIK surgery on a human's cornea dozens of times per day absolutely should have a perfect coder. There are some industries where sloppy code should get you fired, because it will get someone killed.

Re: Ask HN: Have you ever regretted hiring a developer?

#97

Post by wheelerwj »

omidfi wrote: post #94
wheelerwj wrote: post #57

This is an interesting question, because it signals that you are most likely very new to hiring, and maybe ill-equipped to handle managing people in general. Although, at least you're asking questions. First, very rarely does a manager regret a hire even though it's very common for a hire not to work out. Hiring and interviewing are in terrible shape right now, and more often then not lead to terrible hiring/job acce…

Thank you for your insightful comment. You're right,this is new for me. But fortunately I'm not making decisions, or managing people at the moment. I'm just learning. I'll check out the books.

wanting to be good/get better is half the battle. I'm sure if tou keep trying to learn you'll do great.

Re: Ask HN: Have you ever regretted hiring a developer?

#98

Post by stouset »

pryelluw wrote: post #63
dilap wrote: post #50

Earlier quoted context omitted.

The perfect code guy doesn't sound so bad.

Until you ship a product so late that its declared DOA. Perfect coders are more dangerous than shitty ones. They usually slow down progress in the name of perfection so much that nothing gets done. IMO.

I don't know that I agree that perfect coders are more dangerous than shitty ones. When you're behind on a project because someone is taking too long, it's upfront and obvious and usually they can be encouraged to speed up things as long as they document where work needs to be done afterward.

Bad developers are the gift that keeps on giving. Everything looks great, you ship, it mostly works, and then you spend four years struggling to build anything on top of what was written, squashing data-loss bugs that take weeks to track down and can never have their root causes fixed, etc.

Companies that end up in the latter situation are basically zombies. They're already effectively dead, but nobody knows this is the case for years, pouring time, effort, and money into a bottomless sinkhole.

Perfect coders can also serve as really good mentors on teams, and catch serious issues everyone else would have missed.

Re: Ask HN: Have you ever regretted hiring a developer?

#99

Post by scarface74 »

zepolen wrote: post #95
scarface74 wrote: post #77

Earlier quoted context omitted.

I'm relatively new to Mongo and I've only used it in C#. But a few points: I would only use Mongo as a backing store for a micro service. All access would be through one service that enforced business rules, data integrity, and would be responsible for exposing business objects/aggregate roots. App servers are a lot cheaper/easier to scale than database servers. By keeping all of the logic in the business tier, it's…

See, what you just posted is a typical response which tries to justify Mongo, even though you yourself have little experience with it! Fine, I'll bite: > All access would be through one service that enforced [rules, integrity] That's a very good idea; you just described what a database is. Now why take it upon yourself (and team) to reimplement that yourself when there exist quite a few that have had thousands of pro…

A. Real joins using normalized data

Then you end up denormalizimg your data anyway in the business layer anyway because most real world applications work with denormalized data and being a good DDD person you work with "aggregate roots". With Mongo you can store and load the whole aggregate root as is without the whole "object relational impedance mismatch".

1. generates a ton of network congestion from getting the data 2. ton of cpu because because json decoding/encoding 3. ton of cpu because scripting languages vs optimized C

I don't use scripting languages. I use C#.

4. the use of O(shit) algorithms to make the joins

If you're doing a lot of joins with a non relational database, you're doing it wrong. You should be Store the whole object hierarchy as one document.

If I'm doing joins. I'm using Linq which should be doing joins based on hashes.

5. inconsistencies when things fail like network or disk or shutdown

Again you should be storing the whole document with the relationships.

B. Redundant data 1. use a ton of memory/disk 2. create deferred overheads in order to keep things sync 3. despite that, end up with inconsistent data all over the place

You're doing it wrong you're using a non relational database like a relational database.

4. wont actually be faster or scalable(!!!) In both cases they end up creating a bottleneck once you start caring about concurrent access not messing up your data.

If you use it like an RDMS it won't be. But if you're storing all of the related data as a document, using good algorithms when you have to join, it is faster. How much time do OO programmers spend denormalizing data and using bloated ORMs?

Re: Ask HN: Have you ever regretted hiring a developer?

#100

Post by acjohnson55 »

lj3 wrote: post #40
acjohnson55 wrote: post #18

Earlier quoted context omitted.

That's one reason we rely heavily on thorough, structured reference checks.

Does that actually work? I've never had anybody ask me for references for a technical job. Few people are going to say anything bad about a former employee for fear of being sued. And that's if the candidate plays fair. For less than $100, you can bribe three people to say you're the next best thing to Steve Jobs himself.

It works great! I agree that we're unusual in the weight that we put in our references, but I've never had it be a blocker with an applicant. We run every reference through the same script of questions, for a call that tends to last about 30 minutes. Since many engineers often talk in interviews about what their team did, versus their own contributions, the third-party viewpoint is very helpful for getting that perspective. We've found references to be helpful in differentiating between average, good, great, and exceptional individual performance, and extremely helpful in understanding a candidate's teamwork. I personally find it vastly more useful than whiteboard coding and work samples for predicting how a candidate will actually perform.

Aside from their usefulness in making hiring decisions, as a manager, it has been great for jump-starting my relationship with my new hires with context on how they have worked in the past. That has been really helpful.

I agree with you that references have some limitations. We do, of course, expect that applicants will cherry-pick their references to make themselves shine. Yet, I typically get very candid feedback from the reference providers. I think most people simply aren't built to straight-up lie for someone else, even if they are a friend. References are typically someone in some level of authority someplace else, and they put their word on the line. Most people seem to take that seriously.

Another limitation is that people often can't use their current boss as a reference, and for people on an upward career trajectory, that may exclude someone who is capable of talking about the applicant's greatest career achievements. This was the case for me when I applied to my current role.

Lastly, we have to keep in mind that any single reference is colored by the biases and personality of its provider. And some applicants simply have access to better referrers than others for reasons out of their control. All we can do is make judgment calls when it comes to these things.

Post reply on HN