Live data from Hacker News

Ask HN: Have you ever regretted hiring a developer?

news.ycombinator.com

101–110 of 114 posts

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

#101

Earlier quoted context omitted.

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

How do you structure your reference checks? And what do you do for new hires who are very early in their careers and don't have real work references? Also, I'll note that three of the above employees were sourced via referral from either other employees or friends of execs.

See my other response for more context, but we have a behavioral interview-style reference call script, which is universal for all roles at the company. But it still does tend to reveal good knowledge about the candidate's technical ability, even with generic questions. Occasionally, I'll add an additional question for tech context, but I find the basic script to be pretty comprehensive.

I'll echo the sibling post for inexperienced candidates. References from jobs in other careers also work. But to be honest, if someone can't find anyone to speak in-depth about their achievements and teamwork, they are going to have a really tough time passing the bar to get hired. We don't generally do work samples of any kind, but I'd probably have to make an exception in that case, to get some kind of picture for how they work.

We've certainly had a couple people not work out on our engineering team. But I don't think we've ever hired a total dud or a toxic person.

It's interesting that you mention internal referrals, because I think that can be a major source of bias. People feel obligated to put in a good word for their friend, and if I hold the referrer in high personal regard, my natural skepticism of them as a reference diminishes. I feel referrers should say their (small) piece at the beginning, but from that point onward, the hiring process needs to be independent of their influence.

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

#102
I freelance with a lot of startups. I remember times when it did not work out well for people who hired me and I assume that they regretted hiring me. The problems were as follows :-

1. They had very vague requirements and they overcomplicated their MVPs. I had to charge them by the hour and because the requirements would change, their costs went up. It was quite difficult for them and I could not really do much - because they underestimated the development effort it takes and were overtly confident of their product market fit.

2. The other being that they were single business cofounders and overvalued what they brought to the table. Thus they were not able to get onboard tech cofounders quite soon.

This is from a very startup perspective where many times founders are very passionate and too optimistic about what they are building.

I think a good way to handle such situations for a developer is to mentor them early on and built trust with them; so that they let you help them simplify their MVP goals.

Also I think for the hirer, building trust with a developer who has the understanding of the product would be great. As a hirer, if you can gauze that s/he is truly curious about the product - would be good. You cannot expect them to buy into it; and it is more likely that they will have a lot of doubts about the product offering initially. It could take a while for a developer to buy into the offerings of a product vis/vis the risks involved.

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

#103
post #29

In my case when I've regretted it was much because the "attitude problem". For a team of 10 devs (I've recruited all of them), I remember two specifically cases in which I regretted to hire those guys. Guy #1: A "developer" who was trash talking everyone (even me) and then he pretended he didn't do it or he alleged "I didn't say that", he complained about every one of his teammates, he pretended and believes that he…

> he was harassing me to give him attention I was swamped of work and attending useless meetings and I couldn't give him much attention, so he started sending me whatsapp messages and e-mails at ridiculous hours and complaining because "I didn't reply his messages" Sorry, but this doesn't sound so horrible on his part. Are "useless" meetings more important than getting work done at your company?

Well, those meetings were useless, but as I said first he just wanted to trash talk about other people (he wasn't calling for attention to show me work, I used to sync up with him about work frequently), and those meetings even useless were much important than listening crap like .. "I couldn't connect all the day to the network, somebody banned my mac address" (that wasn't true of course, he just had issues on his environment but instead of think of that, he was paranoid about someone on the team hacking him or something)

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

#104
post #32
post #29

In my case when I've regretted it was much because the "attitude problem". For a team of 10 devs (I've recruited all of them), I remember two specifically cases in which I regretted to hire those guys. Guy #1: A "developer" who was trash talking everyone (even me) and then he pretended he didn't do it or he alleged "I didn't say that", he complained about every one of his teammates, he pretended and believes that he…

Serious question--for some reason, I've always believed that previous employers tend to avoid saying anything negative about their former employees. Is this not the case?

Well, after Guy #1 left the company I met a former colleague of him on other company, and she told me "why you didn't call us? we would advise you to not hire this guy!" so that's where my assumption came from, you're right, there are probably people that will hide the truth just to be diplomatic.

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

#106
post #95

Earlier quoted context omitted.

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 d…

Sounds like you're married to the fact that data should be an [object].

> How much time do OO programmers spend denormalizing data and using bloated ORMs?

OO programmers that try to make data into objects sure. Those are the same programmers that love document based datastores because they don't have to think about their data - just get a nice "object" which fits their "everything must be an object" programming mindset.

Thing is, data is relational, and data isn't an object.

It's much better to use views of data, eg. "get me what I need to display a listing page in an eshop" - which entails getting the price, photos, title, description, delivery cost etc. - in a single list that you can then use - the database can do this for you - and all the underlying details are abstracted away, better yet - your app server will never have to CARE that at some points product.photos changed from being a simple array of strings to a fully fledged table - because the view remains the same.

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

Okay so you're saving the entire list of 'followers' of a user inside the user document

What happens when you have a really popular user with a million followers...

What do you do when you update a user who happens to follow thousands of other users...

Oh you don't do it like that in that case? I guess... you're now relational.

Denormalization only helps with performance up to a certain degree, and in fact what you save on read access you pay dearly in update access or stupidly huge extra storage/memory.

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

#107

Earlier quoted context omitted.

Didn't try that yet. But that would only work for microscopic node js libraries. I mean when someone asks you: "are you proficient with SuperAwesome ORM XYZ?" Apart from the fact that the person on the phone probably won't even know what an ORM is, it's not possible to learn an API by heart in 5 minutes. ;) (I doubt it's desirable but that's another thing.) I understand the desire of people wanting to have competent…

Maybe. Or you could invest the short time you said it takes to come up to speed, do that, and call them back. You'd be much more valuable to them and should be able to get a job more quickly with higher value to you.

I'm sure you're right but on the other hand I'd then declare myself as having not enough value. I find it already ridiculous which amount of preparation some companies ask, just for a simple interview. Doing even hours (or days - in case of a lib) for making a good impression on the phone is just insane. Interviewing with 20 companies would then be a half year full-time job.

On the other hand taking a few days to get to know something is still waaayy better than taking months for the exact same thing. But yeah, that's just over the top for recruiters who just want to go through a checklist.

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

#108

Earlier quoted context omitted.

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 d…

Sounds like you're married to the fact that data should be an [object]. > How much time do OO programmers spend denormalizing data and using bloated ORMs? OO programmers that try to make data into objects sure. Those are the same programmers that love document based datastores because they don't have to think about their data - just get a nice "object" which fits their "everything must be an object" programming minds…

Thing is, data is relational, and data isn't an object

Only if you are more concerned with the data first approach instead of thinking about the domain first.

It's much better to use views of data, eg. "get me what I need to display a listing page in an eshop" - which entails getting the price, photos, title, description, delivery cost etc. - in a single list that you can then use - the database can do this for you - and all the underlying details are abstracted away, better yet - your app server will never have to CARE that at some points product.photos changed from being a simple array of strings to a fully fledged table - because the view remains the same.

It's only "much better" until everyone wants there own one off view that has to be kept in sync with the code and reverting/branching/versioning has to keep in sync with what the hundreds of brittle views, stored procedures, etc. that are being created. Instead of treating the data store like a dumb data store. By putting as much logic in the business later as possible. I can not only branch, version, etc. I can completely unit test my whole application and mock out the data store.

Okay so you're saving the entire list of 'followers' of a user inside the user document What happens when you have a really popular user with a million followers... What do you do when you update a user who happens to follow thousands of other users...

Mongo best practices are to think about the orthoganility of your relationships - one to few, one to many, or "one to quintillions" and choose whether to embed based on that.

But going back to thinking in terms of DDD an aggregate roots, a user would be an entity, an address of the user would be a value type that belongs to the user - embed it into the document. A user's followers would be entities, that would be a related object that should be able to change independently. In that case use Mongo references.

and all the underlying details are abstracted away, better yet - your app server will never have to CARE that at some points product.photos changed from being a simple array of strings to a fully fledged table - because the view remains the same.

If I'm changing the representation of the data. I still have to change it somewhere - whether the database -- where you don't have proper versioning, branching, source control -- or the app server. If you're changing the representation in the app server in more than one module/microservice, you're doing it wrong. With a microservice/module, I can still represent the data as old clients expect by versioning the API and have much better tooling than have five different versions of the view that never die.

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

#110

Earlier quoted context omitted.

I'm not sure what to make of that. Assuming the product isn't genuinely boring, is it the norm then that developers without a direct financial incentive in the growth of the company should just be drones who type code in exchange for a salary?

Looking at it from the other perspective is it sensible to centre your life on a job that may not even exist tomorrow?

Showing some enthusiasm doesn't mean centering to your life around it
Post reply on HN