Hacker News Reader

Hacker News

Comment by thanatos_dem | Hacker News Reader

Full thread

thanatos_dem

Next post from danfox - “how to get 3 job offers in 3 hours”.

Already has been publicly contacted by:

- GitHub CTO

- SerpApi CEO

- SourceGraph CEO

Search is hot right now!

View on HN

Actually, It would more be like: "How I failed at 3 interviews, despite being directly contacted by execs."

That would be quite the dystopian interview nightmare.

Sure you built app on multi 20 core machines with functionality to search hundreds of millions of lines of code almost instantaneously, but are you someone I'd drink a beer with?

For some of those companies it would be "drink a La Croix with"

This snide remark dismisses the fact that working on software does mean working with other humans, not just unemotional robots devoid of any kind of irrational ideas. Being able to “drink a beer with” (and reasonably substituting the drinking of beer for just about any other social interaction) is an important part of being able to work with someone. Unless of course you believe an office environment consisting of a tyrannical manager barking orders at worker drones is a healthy relationship.

100%. I don't really care if you're a super genius if you're also a massive dick that everybody hates.

Are you having intimate romantic relationships with all of your co-workers?

If they get me out of work at 4:30 pm and keep the project I'm working on in quality code so I have less fires to deal with, that's good enough for me.

It's an ego thing to want to work with someone just like you instead of adapting yourself to others. It's basically bro culture. It's kind of what's wrong with technology culture.

Give me someone who is talented who makes great code so I can be home at 4:30pm and I don't care what their personality is like. Additionally someone who tells me when something is an issue even at my ego's expense is extremely valuable, over back patters and schmoozers who just want to keep everyone happy. That leads to a terrible product. I would not like to see whatever product you're working on is like.

You all should take a long look at yourselves and ask why you have to work with people who are just like you instead of being adaptive to other walks of life, personality, and backgrounds. Try getting out of yourselves for a minute. You might even learn something now outside of your own tiny tiny worlds!

That’s a pretty unfortunate interpretation of my comment, and not entirely logically consistent either.

I mean, if one person who rejects bro culture only wants to collaborate with other people who also reject bro culture, does that mean they are now proponents of bro culture?

I also find it frankly a bit weird for you to make grand sweeping assumptions about who some strangers on an Internet forum choose to associate and collaborate with. How do you know people here don’t work with people from other backgrounds?

I found your interpretation of my original 'snide' comment pretty unfortunate.

And not a single thing you just said makes any logical sense.

I do know I would never want to work on any project that you're in charge of because I guarantee they're nightmare environments.

Best of luck to you nonetheless.

I think when people talk about this, they mean to push back against the fact that people will often to be biased to hire someone they think they could be casual friends with, share interests with, etc.

I like my coworkers and I find them perfectly find to work and make small talk with, but I don't share interests with many of them and wouldn't really care to hang with them outside of work. That shouldn't be a criterion for hiring.

I have found it highly annoying to work in engineering orgs where everyone seems to have the same interests. Everyone talking about Star Wars, Dungeons and Dragons, Lord of the Rings, etc. constantly because it's assumed everyone else around also enjoys that conversation.

Couldn't whiteboard a solution without the temp variable.

I’m in a field and physical area with a pool so shallow - that it seems like straight up madness to throw questions like that at people and kick them out the door for it.

New game show idea:

CTOs from software companies interview at other software companies.

this would be awesome, i would watch this!

i bet they would all go back home and immediately fix their own hiring practices.

If only the answer to "how" was as simple as "writing a web service for searching GitHub repos with regexes," even though the problem is probably in itself non-trivial if there's this much interest in search at all. At least the specification is clear enough.

I guess what I mean to ask is, how would people know this is a "correct" answer to the "how" question beforehand? Is the answer literally just "search" because that's simply what's trending right now?

It also probably goes without saying he should be careful with what details to share.

I'm surprised as well, think why big tech companies didn't have this awesome search already.

If this were to be offered by an actual company (a first party solution), there are some features that'd be expected that make the problem space a lot harder. Here's an "intro to search" article that's a good read, and I'll use it to highlight some of the things that'd be different in a first party solution - https://medium.com/startup-grind/what-every-software-enginee...

(See the "Theory: the search problem" section)

Size: This is only indexing ~500k public repos. A first party solution would be expected to index all of it, public and private.

Indexing speed: This can take up to a few days to index. A first party solution would be expected to have a much lower index latency - seconds to minutes.

Query language: This can (and does) have its own simple query language. A first party solution would need to have support embedded into and not break backwards compatibility with the current query language.

Context-dependence: A first party solution would be expected to index private repos as well, and now the query context (logged in user) becomes another variable in an already multi-variate problem space.

Latency: Gets harder with scale, and a first party solution would likely provide a SLA/SLO around latency.

Access control: Same issue as context-dependence, with private repos being included.

There's also unknown but likely considerations around compliance and internationalization, which are quite tricky problems.

Note - I don't mean for this to be critical of the author at all. This is an awesome and useful tool, with a fantastic UX. I just want to make it clear that search at scale is a lot harder than it seems at first glance, especially as the feature requirements increase.

For GitHub, I would have to imagine only being able to search public repos with regexp would be good enough. GitHub has many strategies, but the main one is, they want to maintain, if not, expand their open source mind share.

The more reasons you give people to go to GitHub, the better off they will be in the future. So I do agree with you that as a commercial solution, this may not be viable, but for GitHub's public repos, this can turn into a very positive thing.

That might well be true but to scale this type of service to all public repos with decent latency and update ratio is a major technical challenge and likely very costly to maintain.

This is my personal observation, but GitHub appears to be a much more ambitious company, now that they are part of Microsoft. With a CEO that understands both the open source and the enterprise world and with Microsoft cash at hand, I don't think spending money to make search better would cause any concerns.

Doing technical things that GitLab, Bitbucket, etc. can't is quite valuable. It also helps with recruiting, since smart people want to work on difficult problems.

It may well be costly to maintain, but I think the operating cost would be well within the realm of an incumbent that wants to maintain and expand their reach. I've been studying the code hosting space for quite sometime and GitHub, from an outsiders perspective, appears to be much more focused and ambitious, which should cause serious concerns for GitLab.

Engineering manager for code search at GitHub here... this is an excellent summary of many of the concerns we have as we work on code search at GitHub scale!

Also by the co-creator of Django: https://news.ycombinator.com/item?id=22397023

Reply on news.ycombinator.com