Also Kagi.
I decided to start paying for search results when even DDG started giving me sponsored results for the top 3-4.
830 karma · joined December 3, 2008
I decided to start paying for search results when even DDG started giving me sponsored results for the top 3-4.
Early in my career I worked at a company where we only wanted to hire the "best" people. However, after several years many of us began to notice a slow, downward trend in the quality of our products (games) were and how well they were selling.
One theory that we started floating around was that the "best" people we were interviewing for was actually more in line with "people who think like us". We were really good programmers, artists, and designers, so naturally people who thought and worked like us would be good, too, right? And they were. But that thinking also ignored the fact that people outside our bubble could be equally as good (or better), and bring new (and better) ideas that could expand the target audience.
Later, when I worked at a biotech, there was no [explicit] DEI program, but from the very top (CEO) all the way down, we consistently were hiring for "different than us". We actually wanted different experience and different ways of thinking. When we'd follow-up with each other after someone interviewed, we'd ask "what does this candidate bring that currently don't have?" And it made such a huge difference!
When creating drug studies, having a minority race (equally) represented on the team would result in meeting comments like "we also need enough genetic data from the latino population to ensure ...".
Having women on the team meant getting challenged with knowledge like "mothers have a more difficult time participating in medical studies, so what can we do to remove those barriers for them so we can get a broader test population that includes women?"
Having someone on the team with a relative who was anti-vax meant being always hyper aware of that audience and made us think about it.
Could a team of all white men (I use that demographic simply because it's what I belong to) also recognize those same issues and address them? It's possible, but it's likely not going to happen by default. That's not out of malice; I believe everyone wants to do the best they can. But when people are working hard and moving fast, they naturally just fall back to their defaults for quick decision making and those defaults are born of their own personal experiences.
Anyway, don't hire minorities and people different from you to tick some box (whether for legal reasons or not). Don't make the mistake of thinking "I'm awesome, so people like me are the awesome ones."
Awesomeness comes in all shapes and sizes. Hire people who challenge you and your experiences and challenge them and theirs in return! You, your team, the product, and the company will be immeasurably better off for it.
I have friends with BTC, but no one I know with any have actually used it for purchasing anything. From what I can tell it’s just a speculative commodity that - due to its constant rise in value - no one wants to just exchange it for a pizza (for example) since tomorrow it might be worth more.
This is why the Fed works hard to always keep a steady inflation. Without it, no one would spend the money they have and the economy would grind to a halt.
BTC is basically a fiat currency with rampant deflation.
Combine that with the knowledge that BTC are limited in quantity, and it’s basically a guessing game as to what happens when the last one is mined. My guess is a lot of speculators (ahead of that moment) start trying to cash out.
There are so many things apps like Duolingo expose you to, but don't explain, and don't provide enough context to learn on your own. A simple example of this would be how in English we ask "why", but in Russian there's both "почему" and "зачем". Both mean "why", but using one instead of the other will result in very different answers. Duolingo will expose you to both words, but will never teach you why you'd use one over the other.
If you're serious about wanting to get good at speaking a foreign language, then I'd recommend finding a way to talk to a native speaker in an environment where you're either both in a "learning" mode or it's difficult to fall back to your native language. There's also something to the idea of "shared trauma" while you're both learning. Suggestions:
* Volunteering at a local immigration center. I did this in college and it was easily one of the best experiences of my life. I helped those who couldn't speak English go shopping, fill out forms, etc. I wasn't fluent in their language, but was helping them learn English while also learning.
* Use an app like Tandem or HelloTalk to find native speakers in another country who are trying to learn your native language. If you find someone with a passion for learning who is at the same "level" of learning that you are, it's a great experience.
* Audit university classes.
It'll feel painful and slow at first, but once you can get past the hump of being scared to speak (note: everyone goes through this stage), things will just start clicking. Also, there's a magical point where your vocabulary will just start skyrocketing. You'll be able to just infer meanings from context and recognize common roots, etc. It's a great feeling when it happens.
One other suggestion: use streaming services to watch children's shows in the foreign language. And turn on the subtitles in the foreign language as well, which will allow you to read and listen at the same time. Apps like "LingQ" also do this with children's books. If you already know the story and understand the context of what's going on, that's even better.
- Dead Mountain by Donnie Eichar (an examination of the Dyatlov Expedition).
- Piranesi by Susanna Clarke (fantasy).
- Be Useful by Arnold Schwarzenegger.
- Black Hawk Down by Mark Bowden.
Hopefully the other responses here give me something good to read for Christmas break. :-)
Can anyone here confirm that?
I agree with the previous commenter. It isn’t about breaking things out even moving fast (in my experience), but about getting “the juices flowing”.
I’ve found that when there’s a request for some new tool or thing, people have a very difficult time defining [all] the real world needs. They know they need X, but don’t remember - or even realize - they also need Y, Z, etc. Or worse, many people have been conditioned through corporate culture that they can’t even ask for things that would make their lives easier.
Getting something basic in someone’s hands quickly with the desire of creating a loop of feedback, feature, feedback, … gets the end user more focused and engaged with the final product, which gives the engineers more focused requirements. I’ve found it also gives the engineers the opportunity to make suggestions and get more invested.
This is something I've personally wanted to dive into the psychology of more.
Maybe it's just me, but I've noticed that - in the days of streaming and everything being on-demand - picking what to watch is actually very frustrating to me. Quite often, I'd much rather just browse "live" TV and stop on something I like.
I'd never think to myself "I feel like watching The Goonies". But if I'm flipping channels and The Goonies happens to be on - 20 minutes into it - I'll stop there and absolutely enjoy watching the rest of it.
I wonder why that is.
My wife absolutely hates seafood. So, if I don't want to pick I just start heading in the direction of somewhere like Red Lobster and she'll always think of something else rapidly.
She'll do the same to me with something like a vegetarian place.
What's hilarious is when one of us starts heading somewhere we think the other won't like and they don't change it. We end up eating there and usually have a great time anyway. I've learned to like eggplant that way, and she's started growing more fond of Thai food.
Whoever was driving would mentally pick a place and start driving there. The other - before getting to the parking lot - could pick anywhere else and that’s where we would go instead.
We’ve been happily married 26 years now and still follow that same rule for choosing where to eat. ;-)
And chapter 2: Pontious Pilate absolutely sealed it for me; I love that book!
This isn’t to disuade you from game dev (I have very fond memories of my time in games and most of my best friends are from that industry), but rather to let you know that I have experience in games, domains similar to what you do now, and radical career transitions.
First, I highly recommend the book "What Color is Your Parachute?" It’s very much a book about exactly this. I do X, I want to do Y, and coming up with a plan and intermediate goals on how to migrate in that direction. In the process, you end up learning most of what you’ll need, too.
Next, ne of the key points of the book worth focusing on is in finding overlapping skillsets that can get your feet in the door and begin giving you experience in games. For example:
* Data science is directly applicable to telemetry data capture, analyses, A/B testing of features, etc. While not "game code", many games today capture tons of data about their players, what features are used, ignored, never touched, etc. And game developers are decidedly not data scientists.
* Web development is important for game home pages, community building, exposing in-game data to the world (think MMOs and being able to lookup other players online, see their talent builds, gear, etc), and much more.
* Financial software (depending on what part of financial software you write) has crazy performance requirements and deep understandings of various financial attacks in network communication that are also important to games.
Finally, I can promise that most people you interview with in games are going to care a whole lot more about what you’ve done (and completed!) than what you’re interested in doing or passionate about.
A common metric in game interviews for candidates is "how many games have you shipped?" This isn’t about dick-measuring, but about knowing that you’ve stuck it out with a team through the really hard times taking something to 100%. You haven’t shipped a game yet, but you probably have similar stories about difficult projects - both at work and personal - that were difficult to take across the finish line. Focus on those.
If you don’t already have a GitHub repo filled with little side game projects you can share with potential companies, that’s another big feather in your cap. Doesn’t matter if they are Unity, Godot, your own engine, interactive fiction (text-based), a MUD, or something else. Right or wrong, in games these things can matter a lot when applying for a job.
Last note: games can be a LOT of fun. But it’s also probably a LOT more work than you think. The stories you read online about crunch are very real. But the people I’ve worked with in games were some of the best people I've ever met or worked with. And even though I don’t make games professionally any more, I still make them; I’ll never get rid of that itch. :-)
One strategy I use is - when looking at the (reasonable) options - to try and focus more on those that have the following properties:
1. The cost of doing them is lower; and
2. The cost of them failing is lower.
You want to be able to recognize a mistake quickly, backtrack (as little as possible), and pivot rapidly with considerably more information than you had when you were originally choosing between different options. With the newfound knowledge, you may now realize all the options you considered before were wrong.
Also, remember that "not choosing" is the same as choosing, but usually worse because you’ve not only wasted time, but may not realize the choice you made until much later.
* Thinking Forth by Leo Brodie
* Lisp In Small Pieces by Christian Queinnec
* Compilers (the Dragon Book) by Aho, Sethi, and Ullman
* Smalltalk-80 (the Blue Book) by Goldberg and Robson
But on the non-technical side, the book that probably had the biggest impact on my career was "What Color Is Your Parachute" by Richard Bolles. It is what convinced me I could transfer my skills from video game dev into another field and how to come up with a plan to do so.
* Use a 3rd party service like ReplIt (https://replit.com) or Code Anywhere (https://codeanywhere.com/pricing). These are fine, and have native iOS apps used to connect to their services as well.
* Pay for a cloud instance and use an SSH tool to connect to it.
The downside to these two options (depending on your needs) is that you are pretty much just targeting Linux and building CLI apps. But that may be totally fine for you.
Personally, I pay $60/year for SplashTop (https://www.splashtop.com), setup a SplashTop server on my home computer, and then use the iOS client to connect to the my home computer and continue programming. And I get the benefit of being able to do other things as well (like playing Steam games) if I want.
Edit: similar to SplashTop, you could also - if interested in Windows - pay for a Shadow PC (https://shadow.tech) and connect to that.
When a team decides to switch programming languages, which would be a major undertaking, it’s typically for one of the following reasons:
1 - There is a deeper understanding of the problem space and the initial language doesn’t actually help the team from creating bugs that would be determimental to the continued operation of the business (eg, choosing Erlang when 9 9s of uptime is of absolute importance or a systems language when nanoseconds matter).
2 - Time has passed and there are many frustrations the team is dealing with in either maintaining - or extending - the current codebase. And there is now a belief that switching everything over to $LANGUAGE will solve those problems. This is rarely true and almost always a red herring as (typically) institutional knowledge of what the original set of problems $ORIGINAL_LANGUAGE solved are forgotten/ignored due to them not ever being a problem. But as soon as you flip the switch, the team will be acutely aware of them.
In the end - unless it’s made for a legit business reason (see: #1) - more time will pass and the same team will be frustrated with a different set of problems.
I hope you can see the hypocrisy in this statement: you want the candidate to take on the risk you're unwilling to, in a situation where you hold all the cards.
What if a candidate said $110k? Would you still offer them $160k if you felt they were worth that? Or would you take advantage of this newfound information and offer them less than what you thought the job was worth to you?
Because of this - as a candidate - when someone asks me "what salary are you looking for?" it's an immediate turn-off for me. I pretty much refuse to answer the question or ask what the salary range is for the company.
My favorite thing that a company can do regarding comp is to publicly state what their roles, titles, and salary ranges for those are. Then specify in the job description what title they are hiring for and link to that information.
This absolutely is great for the already-working employees as well as candidates. Knowing what title I am, how much I can expect my compensation to be upon promotion, etc. is beneficial for everyone. You can also publicly state the trade-offs your company has chosen to make regarding compensation and attract candidates who appreciate those things.
Perhaps your base salary is lower than the norm, but you offer other things that make up for it. Examples of things worth more to me than base salary:
* More vacation time * 100% remote * 100% medical coverage * 9+% 401K match * ESPP, RSUs, ... * Very short vesting times * Paid child care (possibly on-site)
The list goes on. I guarantee - unless you are grossly underpaying your employees - that if you just publicly list title : salary, heavily promote your other benefits, and have recruiters link to that, you'll end up being much better off.
- If you could snap your fingers and change/improve one thing at the company, what would it be.
The responses could be technical, cultural, about management, communication, etc. But this question has never let me down. If I a random distribution of different things, I know that - like any company - there's always going to be different things that people don't like (and that I won't like either). And I'm just asking myself if any of these are not a good fit for my personality.
However, if I notice multiple people all identifying the same one or two items, then the higher I get in the food-chain of interviews, I might pivot the question, calling it out:
- I've heard multiple times now $PROBLEM, what would it take to address it?
The best answers come from mid-level management. They'll usually be very frank about any cultural issues that prevent the problem be solved, but are aware of it. Regardless, the higher up I get, this one question usually has me knowing whether or not this is a place (culturally) that I want to be at.
These are fields such as: research, biotech, pharma, cyber security, medical, utilities, oil/gas, space (NASA), air (Boeing), defense, ...
If you don't have skills immediately pertinent to domains such as these, you may have skills that are tangentially related and allow you to get in the door and then become indispensable and branch/learn.
Also, you may have skills that are huge benefits and don't even know it. Examples: applied probability, databases, big data, ETL pipelining, business continuity, encryption, 3D visualizations + animation.
I'm in biotech/pharma (48 y.o.), and know several programmers who started as web developers and ended up making front-end UIs (e.g. Streamlit apps) that were of immense benefit to the researchers. Over time they pick up some genetics, move over to help other teams, etc.
Also, while I think there's less of it on HN than the rest of the internet, most people overstate their income, savings, skills, experience, etc.
There's also a confirmation bias taking place, because most people aren't posting "I can't retire until I'm 72 because I have 4 kids to put through college and the stock market has screwed my 401k!" Your sample size on this is extremely small. ;)
<insert star wars "stay on target" meme here>
Ignore what you _think_ everyone else around you is accomplishing. Focus on yourself. Most of what you believe is taking place around you is smoke and mirrors.
I'm starting my answer, though, with a comment that your question (and opening sentence) don't really match the rest of your post. Why will be apparent soon, I hope. I'm also going to assume that "remote" implies that working hybrid isn't possible due to distance.
Your post title and opening statement lead one to believe that the most important desire you have is to work remotely. Likewise, you end with a question about what to work/focus on. But the entire body of the post is a bullet list of random things that you've worked on or enjoy working on.
So, my first thought is: what is actually important to you? Do you want to work remotely or work on what you are passionate about? Those are not necessarily mutually exclusive, but - for example - if you are most passionate about robotics, working remotely likely won't be an option.
Let's assume that your post title is accurate and the most important thing is working remotely. Why is irrelevant; you have your (valid) reasons for this. So, what can help you in this?
As noted, there are some fields and subfields for which this won't really be an option. Put those out of your mind if working on-site is a non-starter for you. And other fields will be more conducive to remote work than others.
Next, while you asked (or I inferred in your question) about tech, etc. to learn, my response is about traits. I'll assume you're smart and can learn anything you put your mind to and are interested in. If you land the job, I'll assume you're qualified for it. So instead, you want to know what you can talk about in an interview to better your odds of getting the job, but also can enable you to be successful at it once you have it!
The traits I'm going to list are ideal for any employee at any company. But they are MORE important for remote (IMO), because it's a lot easier + faster to spot dead weight in-office. Remote people can sneak by and cause problems for longer. So when I'm interviewing someone for a remote position, and I've already determined they have the necessary tech skills, these traits are where I hyper focus and give extra weight.
1. Take great pride in your work and always desire to present the best with every commit.
I will absolutely look at your code in GitHub and ask questions about it. Can you talk about something you wrote a year ago? If not (often I can't), did you leave yourself - and others - enough breadcrumbs and comments to figure it out again? Or is it a jumbled mess that you walked away from?
2. Don't let your fellow team members down.
You're still in school, so I'll ask about team projects. If possible, I might contact professors. It's not for everyone, but military service is a HUGE plus to me personally. I'm not suggesting to enlist, but if you were in ROTC (for example), be sure and talk about it. Did you have other experiences that were similar (volunteering, Big Brother/Sister, TA classes, ...)?
3. Be self-motivating and organizing.
Be capable of finding something interesting in even mundane tasks and manage yourself (work won't always be "fun" and sometimes you gotta just roll up your sleeves). Be able to organize the work, track it without constant oversight, and have the ability to take it to completion. If stuck or you don't know what to do, don't be afraid to ask for help and say so.
Note: if you find yourself at a company where saying "I don't know" or asking for help is frowned upon, get out of there as fast as you can.
4. Excellent communication skills.
I think remote work requires considerably more communication (of various kinds: email, DMs, PPTs, video) than in-office. To be clear, I don't care about things like being shy or speech issues (e.g., I stammer), but the quality of the communication. Your team shouldn't ever be questioning where you are, what you're working on, where it's at, what you're waiting on, etc.
I hope some of this helps.
That said, what _powers_ those models: encoders, attention, and transformers, has been a massive leap in AI model generation. This cannot be overstated!
I don't care about AI generating a token or pixel. What I care about is being able to throw very complex data at a model and have it "learn" relationships between them in ways I couldn't see before and then being able to perturb the data to see what how that changes the "meaning" of it.
For example, in biotech (my particular field), training models on the gene expression profiles of healthy vs. diseased tissues and then perturbing expression levels (in silico) to determine if doing so encodes the gene profile as "healthy" is ground-breaking. As data profiles of are added it has the potential to also reveal potential toxicities of gene inhibition (or expression) without ever needing to test it in the lab saving $100s of millions.
The party tricks are neat, and they are what bring in the $$. But it's the building-block use-case getting very little attention where all the benefits are going to be had in the coming years. And they are coming fast!
P.S. My personal prediction is that the next massive leap in AI is going to be a paradigm shift away from how we train and simulate networks. The current framework of more and bigger GPUs to process larger and larger models is unsustainable. Someone, somewhere in the next 5-10 years will revolutionize how this is done and THEN we'll have our true, AI "revolution".
- I'd like to acquire <resource> at time T for N units of time.
- I'd like to acquire <resource> for N units of time, give me possible T's.
First, it's was a great benefit to identify what "unit of time" was. For my case it was 30 minutes; this helped tremendously as you'll see.
Next, for the first question (I want <resource> at time T), once I had enough data that actually searching became slow enough such that a return of "resource not available" became problematic, I found a bloom filter seriously improved things. It allowed for not only the common case fails to fail really fast, but bit-shifting the filter also allowed for some very fast parallel queries of "nearby" time slots. I was able to rapidly return things like "2pm isn't available, but 1:30pm is".
Last, for the second question (I'd like <resource> for N units of time), this is _very_ similar to a heap memory allocator. At its simplest it's just a b-tree of slots, etc. Grabbing a big slot, splitting it up, etc. This gets even easier if there are time boundaries that cannot be crossed (eg, a day).
To be clear, the allocator approach isn't about you managing a BTree like you have been. It's about a tree of _available_ time slots that are _free_. Initially it begins as a tree with a single node for all time. Make a request, scan the tree for a time slot large enough to meet the length needed, subdivide it, etc. If a time slot is not longer needed, you put it back into the tree by scanning for the node it belongs to (or fits between), coalescing, etc.
Hope this helps!
For example, I can see the death in front of my house from a year ago, which was the driver suffering a heart attack while driving. He was the only victim and it wasn’t the crash that killed home.
Would love to be able to compare areas for things like:
- DUI - speeding/reckless driving - cycling victims - pedestrian victims - multiple vs single vehicle - medical cause
Curious how you claim zero false negatives though (as in missing a person it should have detected), unless you’re reviewing all the data or have another system hooked up to it verifying? Or perhaps you simply mean to imply nothing bad has happened due to a missed detection?
In curious hope it did during Halloween with all the costumes? Are you able to have it pre alert you that kids are coming to the door?
Still going to read more. Thanks for the citations.
Not discounting the rest of your statements (I love FP for all the reasons), but I really despise - and discount - statements like the one above. I feel they are disingenuous:
"This large-ish program that grew over time with evolving needs and uses was rewritten at a later date once the requirements and use-cases were fully understood and - amazingly - we were able to greatly simplify the code!"
It probably could have been rewritten in BASIC and still resulted in fewer LOC. That's not to discount the null checks, "zero bugs", or other factors. My favorite part of programming in Haskell is that 99% of the time if it compiles it just works, and I can refactor code + add features without concern.
This is your real question, I think. And there are different answers here based on who you are and the role you have at within the company.
First off, I strongly recommend a policy of "never lie". I don't care what the situation is. People are natural lie/bullshit detectors, the truth always reveals itself. Once you lose trust getting it back can be near impossible to do. And most industries are "small" in that word gets around quickly. Just don't do it.
Next, we'll ignore decisions you disagree with that can be considered insider information. Those are as simple as the equivalent to "no comment" or just blatantly ignoring the question and removing yourself from the environment.
Finally, there are three situations remaining:
1. You disagree and are a decision maker (others will be looking to you for answers and leadership)
2. You disagree, are a decision maker, but are letting the team under you make the call.
3. You disagree but are in a simple IC role, perhaps lending thoughts or ideas into the discussion, but play no role in the decision making itself.
If you're a decision maker just be honest. If necessary, outline the problems, the proposals, where (your desired) proposal fell short or why it was rejected. Outline what was liked about the accepted decision, etc. Also take the time to state where the accepted decision may fall short and plan for those contingencies. It's not a zero-sum game. If the decision is from on high, never have the attitude of of "we're taking one for the team" as opposed to "leadership recognizes that we can manage the difficulties that may ensue, but <other teams> will benefit exponentially more because of this choice". If the decision is from those under you, be supportive. Have regular check-ins to make sure your concerns are being addressed and be a cheerleader for them. Understand why they made their choice. What problems did they see that you didn't? etc.
If you're just an IC (or even a decision maker accepting a decision from on-high), you have to ask yourself "is this the hill I want to die on?" Does it really matter if we use Ruby instead of Haskell? If the company doesn't allow hybrid or remote work? Only you can answer these questions for yourself. If you really care and have made that known, then start looking for other employment. If not, then when someone asks, tell the truth: you disagree, this is why, but there's things at every job that will be problematic and this - in the grand scheme of things - is minor, not worth fussing over, and then note (also for yourself) the positive aspects of the decision for the greater good of the company.
Also, I'd like to bring up one other thing you didn't ask about, but can be important. It's possible that you don't care too much about the decision made, but very much care about the reason(s) why as they may be a fundamental indicator of future decisions you will care about. When those happen, bring them up appropriately and early. If they aren't addressed, start looking elsewhere or - in my experience - your life will end up miserable. But a great boss will address them and may even be happy/surprised.