clbecker

Toolfinder is just a simple way to endorse software for what it's good at and to find tools based on what you need.

I always found it a slog to search for new software to do something I needed-- most recommendation sites just give you generic star ratings, or you have to dig through a whole article or comments to figure out if it does what you want.

I thought this idea would be a super simple way to rate tools for specific features or jobs they do rather than just rating the tool as a whole.

Hi - (creator of subtask.co here) - Noticed a few signups coming from hn and thought I'd pop in. We're still in an early beta phase now and so pricing is still TBD - we're happy to have any input on what would work for folks though.

The engineers working on a team might spend hours in sprint planning meetings, doing research, and working out an approach with their team before they start coding anything. How would you expect to get a fair assessment of someone by dropping them in the middle of someone else's code work, and putting them on the spot?

In my experiences working with developers, there’s only a few issues that have made an employee difficult to work with. Most of it is around personality, motivation, and communication. It’s rare that I have a difficult time working with someone because they lack certain skills (but do have the motivation to learn them), and for all of the devs I’ve gotten to know and work with over the years, I feel like a detailed review of their previous work experience would have told us enough about their skills.

Good things to check for:

how open minded are they? - Do they stubbornly stick with a certain way of doing things? - How readily will they apply someone else’s feedback? - Do they insist on doing things their way? - Do they think all code written by others is crap? - How much do they bristle at someone else’s code style vs working with it?

How well can they communicate with non-technical people? - How do they talk about their interactions with product managers/marketing/sales/customer service/etc? - Do they blame any issues on customers or colleagues being "idiots"?

Can they talk through a past problem they solved? Can they talk through the whole context of a problem they solved? - do they understand the customer problem they were solving and why it was important? - can they speak to multiple approaches that were considered and what their drawbacks were? - A great one is, did they go down a wrong path and learn something?

- Some other things to assess are - do they focus on the right problems to solve? Do they have a history of building systems that are more complicated than they need to be? Do they over-optimize areas where it’s not necessary or do they have a sense of where potential bottlenecks might lie; how to find them; when the right time is to worry about them?

If they can talk through a past problem they solved in detail, that’s a super great sign. The more detail they can get into and help you understand, the better. If they just start gushing technical details, they’re either nervous, or they had a very siloed role in developing the solution. I personally prefer engineers who can get invested in the context of a problem.

When it comes to coding in an interview I’ve found that very simple coding problems can surface all the info I need about their coding proficiency. - if the problem is simple, they’ll be able to just “stream” the code from their head on either a whiteboard or a machine. - experienced developers will even manage to talk through edge cases and workarounds - if they struggle with this challenge, then they’re not going to do better with a more complicated problem. - for experienced devs I’ll want to see that they’re proficient with the syntax of at least one language (if they don’t remember a specific method name, that’s ok - problems that can be solved by a google search shouldn’t be held against them)

- springing a complex coding question in front of them and expecting a perfect solution on the spot is a lot to ask for. “Real” solutions to complex problems will be debated and built upon by multiple people. If you go through this exercise, focus on how they tackle the discussion itself.

- I avoid brain teasers and puzzles. There’s plenty of good developers who can solve a real-world problem well but suck at solving technical brain teasers.

- In any interview, its important to take notice of how nervous the interviewee is. Some people may be able to handle interviews better than others. When you’re nitpicking their answers later on, keep this in mind. Some candidates might blank out on an otherwise simple problem; some might ramble on and seem disorganized. I’ve seen too many candidates get turned down because of a few specific details they mishandled due to nerves.

Thanks to the Hacker News Gods, my account is no longer blocked on here. I'm happy to answer any questions about the original blog post.

That looks pretty cool. As far as scaling issues went, the bulk of them were addressed just by using Solr on pretty beefy hardware (for our full library of 30+ million images, we're running on Dell r510s w/ 24 cores and 128GB Ram). Of course, depending on your hardware limitations there's compromises you can make to increase speed / reduce memory usage - i.e. the fewer fields you need to index and sort on the better & the lower the cardinality of each field, the better too. Also, since our input only consisted of one slider, we were able to run all the distance calculations beforehand, and just store a score that represented the image's distance from the given slider position - something like that might also work for you, since you're using a limited palette of input colors too.

Sorry about that! The labels on the actual prototype were a bit vague and undescriptive anyway - basically most of the sliders represented various statistics taken over the histograms for each dimension in the LCH colorspace (mean, median, stddev, etc), and then there were a few magical sliders that, to this day, I think only one engineer around here knew how they worked...

Also worth noting that Elasticsearch can be swapped for Solr for this just as easily. Some projects like Kibana do what's described here under the hood. Kibana has a fairly narrow focus though -- in that it deals mostly with web server logs -- whereas solr/elasticsearch can be used as the foundation of a variety of big data analytics tasks beyond that.