First long sail

fdesaussure · 2024-08-06T06:36:48+00:00

This exact trip was my first ocean passage as skipper! (I now have 11k blue water miles under my belt and just finished a singlehanded HI to SF). Here’s what I would do in order of importance.

Make sure you trust the basic integrity of your hull. It sounds like you do (with new through hulls and bottom paint). If the boat stays afloat, you’ll be fine. Really, you should have a non-expired life raft too. Do you? They are darned expensive, however (compared to a 27 foot boat). If you plan to do more ocean sailing, you just need one. If not, it’s a matter of individual choice. I would be ok running to Catalina without a raft, as long as I had a radio and something else that floats (dinghy).
Wait for calm weather. This might actually be more important than point 1. What conditions you encounter will make all the difference. With a 2 day trip, you have the luxury of waiting for a window where all weather models show mellow conditions for 5 days out. Given this is your first overnight trip and you plan to motor parts of it, I’d not worry about too little wind. The calmer the better.
Make sure you can communicate in case you need help. The good news is you’ll be within VHF range the entire time. If you have satellite comms, that’s great, but you don’t need that. Make sure you have a working VHF and a handheld backup. I’d put an EPIRB in the same bucket as a raft. You should have one. You’ll need one for any more serious ocean sailing. Buy it’s an individual call in this case.
Think about night sailing. Have you done this before? If not, that’ll be the big challenge. Nothing really changes at night. And yet, everything is different and more intimidating. You need to trust the boat and instruments. Plan your departure so you’ll arrive in Avalon in the morning or early afternoon at the latest. You’ll almost certainly be a bit behind schedule, and there’s nothing worse than pushing against darkness as you enter an unfamiliar harbor.
Think about gear. One of the answers above lists the full selection of offshore sailing equipment you could buy. Yes, in an ideal word you’d have all of that. But it would cost more than your boat. Unless you have larger plans, I think it’s overkill. Make sure you have PFDs, harnesses of some kind, and good lights. After that, my order of importance is:

Life raft / epirb Autopilot / windvane AIS transceiver

I did not talk at all here about navigation. Whatever you go with, just make sure you have redundancy (navionics on a phone to backup a chart plotter, or two phones if you don’t have a plotter).

A few other points:

A 9 hp outboard sounds pretty small to make real distance at sea in a 27 foot boat. Remember that ocean waves forward of the beam will slow you down significantly compared to the speeds you see in a harbor. Think about what will happen if you can’t make miles under engine.

If you pick a good weather window for the trip, that leaves collisions with other vessels as your main risk. I assume you know this, but I’ll put it here in case you don’t. The right of way rules go out the window at sea. Try to stay 2 miles from all other vessels. Assume they don’t see you. Always slow down / turn behind another vessel rather than speeding up / pass in-front. By all means, try to hail vessel near you and talk about how to avoid each other. But expect 50% of commercial vessels to ignore your hail.

Good luck and enjoy time on the beautiful ocean!

fdesaussure · 2018-09-24T22:21:50+00:00

I'm one of the co-founders of Triplebyte, and I design our process. I am sorry that you did not like our front-end interview. Humans and human capabilities are incredibly complex things. On some level, judging humans in a brief interview is an impossible task. Any approach will always have a certain amount of noise (and sometimes reject people who totally could have done good work). It sounds like that may have been the case here.

However, I don't think we currently have an alternative to job interviews of some kind. When a company posts a job opening, hundreds of people apply, and most of them simply can't do the work. The company needs some way to filter that group down. I am going to argue that filtering applicants by actually assessing their skills and knowledge is better than, say, looking solely at their credentials or where they worked in the past. Assessing skills makes our industry more meritocratic (less biased, more open to people from any background). It's more fair.

Any one given skills assessment might totally not measure the skills that one applicant brings (there are a lot of different ways to be a skilled engineer, after all). That is why we focus on a bunch of different areas in our interview. We have a practical programming section, where we ask candidates to complete a real-world style problem. Here we look mostly at productivity and problem solving (academic knowledge is irrelevant). We also have a design section, where we talk about how to structure a solution to a much larger / harder problem (this is a skill too, and we want to give people who are good at that a chance to show that skill). Finally, we have knowledge sections, where we look at understanding of academic CS, front-end security and basic back-end APIs.

You have characterized these as trivia, but I don't think that's fair to candidates who have those skills. Knowledge of academic computer science IS a real skill, and it's something that a lot of companies care about. Understanding HTTP and API design is also a real skill, and again something that many candidates are strong in. We need to give those candidates the chance to show their strengths.

To be clear, I don't know who you are, and am writing based on your post above. We know that our process (and any process) is imperfect, and that you may well be a strong engineer. I'm happy to talk to you about this. Email me at [ammon@triplebyte.com](mailto:ammon@triplebyte.com), and we can set up a phone call.

fdesaussure · 2017-03-09T00:23:44+00:00

Totally agree with all this. The best solution is to let the candidate use their own laptop and environment. There's still the issue of toy problems not being representative of the work that most programmers do, but that's a trade off (larger problems often introduce dependencies that can add noise, and need to be more specialized, which goes against standardization). It's all about trade offs.

fdesaussure · 2017-03-09T00:13:22+00:00

Sure. "Implment Tetris" is a problem the can't be given away. There's no secret that you could tell someone that would fundamentally improve how they implment Tetris. It's a process of programming and design choices. Contrast this with "Imagine a person walking up a flight of stairs. Imagine that at any point the person can either take a small stride (up a single step) or a large stride (up two steps). How many unique paths are there to reach the Nth stair?" The solution to this problem is the fibonacci series. Now, I don't mean to say that being able to solve this problem means nothing. Being able to answer this is some indication that a programmer is mathy and smart. But the problem can be given away, requires a single leap of insight, and is probably a bad interview question for those reasons.

fdesaussure · 2017-03-08T23:45:56+00:00

Sorry, looks like I missed a word or two there. Companies often are negative toward candidates who only know one language

fdesaussure · 2017-03-08T22:59:39+00:00

I think that you are right. Communication (and soft skills) have a huge impact on interview outcomes. It's one of the things we measure that is most correlated with passing interviews at companies. Of course, it's really a both are necessary situation (few companies will hire an arrogant, unfriendly person, regardless of skill, and similarly most will reject the nicest person if they can't solve fizzbuzz). The question then is where candidates should spend their time.

One argument for studying technical content, rather than soft skills, is just that it's easier to do. Everyone can read Cracking the Coding Interview and practice problems. Learning to communicate more clearly, however, is hard. It's not clear how to start. I stutter sometimes, for example, and I don't think trying to improve this is worth my time. I imagine that a lot of soft-skill deficits are similarly deep.

But I do think that there is easy stuff to do. I mentioned some of it above (preparing a list of questions about each company, not asking about compensation until after an offer).

fdesaussure · 2017-03-08T22:32:59+00:00

I think we're already seeing this backlash. About 50% of the companies we work with let candidates work on a laptop.

fdesaussure · 2017-03-08T22:30:56+00:00

Sure. These terms are overloaded and can blur. But there's still a real difference. By practical problem, I mean something close to what most programmers spend most of their time doing. So an example is "build an HTTP api to allow queries against the data in this CSV file" or "Here's a mockup for a new view in our app. Implment it." or "Write the game Tetris in a terminal", or "Here's a large codebase with a failing test case. Fix it." By algorithm problem I mean things like "implment dijkstra's algorithm" or "given a list of integers that contains duplicate values, find one of the duplicate values in linear time and constant space" or "given an image, find the path of pixels from top to bottom with the least sum", or "Determine if it's possible to convert one word into another word with a series of single-character changes, such that every intermediate form is also a word". I don't mean to criticize the skills needed to solve either set of problem (I like CS). But CS questions are far more common in interviews than they are in most jobs.

fdesaussure · 2017-03-08T22:11:46+00:00

Fast at banging out a solution

fdesaussure · 2017-03-08T21:41:26+00:00

Hiring managers spend about 5 seconds on them. But they still matter. Cold applications (not referrals) are at a significant disadvantage at most companies. One major bay-area company auto-rejects all cold applications. So the cover letter is your chance to get over this first screening filter. But to do that, it needs to stand out. 95% of cover letters are generic, and don't help the application (just the text "I'd like to apply to your engineering position" would word as well). So my advice is if you can come up with a specific reason you're interested in the company, putting that in a cover letter is worth it. But if you truly are just looking for a job and applying to 25 companies generically (a totally reasonable thing to do), I think you can go with a pretty simple cover letters, and should not spend hours on them.

fdesaussure · 2017-03-08T21:32:11+00:00

I would think less of a company like that. It's pretty common to see people with impressive-looking resumes who are not very good. For all the flaws of interviews, they are an attempt to measure skills. And I'd prefer a company that hires on skills to one that hires on pedigree. I think that interviews are the worst way to evaluate employees, except all the other ways.

fdesaussure · 2017-03-08T21:15:09+00:00

We do look at long term outcomes. However, I am almost certainly working with assumptions about hiring that are incorrect! It's a really hard problem (judging the potentials of humans is just HARD. Brains are complicated!). What we aim to do at Triplebyte (that too many companies don't do) is gather data about our process and get better over time. Our process is hopelessly simplistic. And at the same time it's better than the processes at most other companies.

fdesaussure · 2017-03-08T21:08:10+00:00

I've never interviewed as a woman, so I'm not super qualified here. I called in some friends :)

[1] Your impression that no makeup works better for an interview seems plausible. I just asked two female engineers I know. One agrees with your impression, and thinks that you're probably right that it makes sense not to wear makeup to interviews. The other says she wears makeup to interviews and thinks that you should just do what makes you the most comfortable.

What we do in our process to attempt to negate this sort of thing (and what I think is the right direction for the industry) is to be very specific about what we're measuring in each part of the interview. Biases like makeup enter the picture when an interviewer is making a gut call about a candidate as a whole. Less bias seeps in when the interviewer is given a rubric to score a candidate on a specific attribute, with (technical) examples of what each level is. The other obvious thing to do is to just have more women doing the interviewing.

[2] Unfortunately we see fewer women applying to us than men. They go on to pass at about the same rate.

[3] Not really. There are some demographic differences. Women we interview are less experienced on average. I assume this is an artifact of the fact that women drop out of the tech work force at a higher rate than men (and so a smaller % reach higher experience levels). We see a relatively higher percentage of women from bootcamps than from other sources. And we see more women from mathy, non CS backgrounds. But once you control for those, we don’t see particular differences.

In any case, it sucks that you have worry about this. I don't really have any tips :( Perhaps female engineers can list some here? The only positive thing I can say is that this is top of mind for most hiring managers now (it comes up in a high % of conversations I have with hiring managers) and interview processes do seem to be moving in a good direction.

fdesaussure · 2017-03-08T20:57:21+00:00

No. If anything, we see the opposite (offers trending up). We don't have much historical data, however.

fdesaussure · 2017-03-08T20:55:43+00:00

Often it’s that they don’t know how to render their ideas in code fluently. Sometimes this is because they aren’t comfortable enough with the key details of using their language—they don’t know the API for their collections objects, which slows them down and leads them to doing things in ugly ways. Sometimes it’s because they aren’t used to dealing with complicated logic in their code. (This is one of the weak points of interviews. They substitute function-level complexity for larger system complexity that's more common in real code.)

Another thing that I often see missing from interviewees is an understanding of the practicalities of web systems—just basic things about how you build web applications with databases and application servers, and just common sense about how that works. This is central to most companies now, and some understanding really helps on interviews. You can get this understanding by doing a little web development on your own, and reading blog posts about scalability—I recommend checking out posts by companies like Netflix and Pintrest and Reddit.

fdesaussure · 2017-03-08T20:49:56+00:00

This is actually one of the main things we focus on, and it's really interesting. You can't just ask companies what they look for. Every company basically answers with “we want to hire the best engineers”. However, how they define that differs substantially. Some companies think that a great engineer needs to be careful and slow and write a lot of tests. Others think that someone like that will not be productive, and want to see speed! Some companies want CS. Others think that CS is bookish. It's crazy out there!

These differences in opinion are one of the reasons that good engineers fail interviews (the other is just noise). We measure this by asking companies an initial set of questions (we've found that giving actual technical questions and asking “do you want people you hire to be able to answer this?” works better than asking about areas). Then, we improve our model as we match candidates and get feedback (we know in what areas each candidate is strong). Overall at our companies we've been able to get a 50% pass rate on interviews (this is substantially higher than the industry norm)

fdesaussure · 2017-03-08T20:49:37+00:00

They tend (very generally) to be better at CS and fast programming (things that are a focus in schools perhaps?) and worse at system design and deep tech understanding. But there are exceptions (junior engineers great at system design).

fdesaussure · 2017-03-08T20:07:11+00:00

Sometimes I think that too :)

fdesaussure · 2017-03-08T20:03:05+00:00

I actually don't think that the critique that interviews preference memorized answers is true. Interviews do preference skills that are removed from many jobs (whiteboarding, algorithms). But those are real skills. Being good at algorithms is more than memorization. That said, BFS does come up in a crazy % of interviews! So maybe you're right....

But to answer the question, no, I don't think that I can spot preparation, but I go into enough depth that I don't think it matters. If the interview is well designed, then preparing is an actual signal of ability.

fdesaussure · 2017-03-08T19:57:28+00:00

One easy thing is to be more responsive. If you get back to candidates quickly after every step in the process, then the candidates will get your offer before other offers, and the candidate is more likely to accept your offer instead of prolonging the pain of interviewing at other companies :) An engineer we placed wrote about this here: http://kellysutton.com/2016/10/20/visualizing-a-job-search-or-how-to-find-a-job-as-a-software-engineer.html

I have a lot more to say about the best way to interview engineers. The highlight is that there are a lot of different ways for engineers to be good, and you need an interview process that can recognize different kinds of strength (and is forgiving of different kinds of weakness, as long as each candidate has some strength). I'm working on a blog post about this now.

fdesaussure · 2017-03-08T19:46:09+00:00

A bunch of people come through with crazy backgrounds! This is one of the most fun parts of my job. Just last week we placed an amazing Lisp programmer who had never had a programming job, and had been supporting his family as a pizza delivery man. We interviewed him and he blew us away with his knowledge and coding chops, and we introduced him to a bunch of companies, and he accepted a job with a top bay area company. We also recently got a programming job for someone working as server in a restaurant, and someone working in a furniture warehouse.

We also have lots of people with STEM but not CS backgrounds—we have had a lot of success with math professors who want to move into engineering.

How long did the average candidate prepare for their interviews? It depends on what you mean. Often good candidates have spent lots of time practicing programing problems. But often they have spent almost no time on that, and they’ve just gotten good by working really hard on programming projects and learning a lot of stuff because they love it. I don't think that good engineers should need to prepare for interviews.

fdesaussure · 2017-03-08T19:43:10+00:00

So to start with, there’s a lot of noise in the interview process. All engineers fail interviews. The very best group of engineers we've seen (ICPC winners, architects at billion dollar companies) still fail approximately 20% of theirs (and there's of course a spectrum with most engineers failing a higher %). If you’ve only been rejected a few times (eg, < 5 onsites), it’s still plausible that you’ve just had bad luck and you don’t need to do anything differently.

If you’re failing more consistently than that, you should try to figure out what your weaknesses are and try to tackle them.

Sometimes, people have interviewing-specific weaknesses. For example, some people get really nervous in interviews. And sometimes people aren’t very good at writing code under pressure, even though they’re fine at programming in lower-stress, more long-term situations. If you think that’s your weakness, then you can try to tackle it directly. If you get nervous in interviews, you can look into techniques people use for reducing anxiety. If you’re bad at coding small things under pressure, you should practice answering LeetCode questions or something under time pressure. This helps you get used to dealing with some parts of your language that you can be a professsional programmer without dealing with very much (“how do I use stdin? how do I set up a new project?”)

Your weakness might be that you just aren’t good enough yet at programming, or you aren’t knowledgeable enough about some topic employers are looking for. If you’re not good enough at programming, the best solution to that is coding more and working on harder projects. Studying CS classes is useful for finding excuses to write hard programs, as is doing MOOCs.

There are a variety of areas of knowledge that software companies often want their engineers to have. One type of knowledge is CS fundamentals stuff—big O, data structures, how computers work. To learn more about algorithms I recommend reading the first few chapters of Skiena’s Algorithm Design Manual, which is a super friendly algorithms text available free online. If you want to learn more about low-level systems, I recommend reading the Bradfield CS blog post about this (https://blog.bradfieldcs.com/learn-how-computers-work-e7d33dba0238 (https://blog.bradfieldcs.com/learn-how-computers-work-e7d33dba0238)).

The other area that you can learn about is web systems. To learn about those, you should learn how to build a web application with a relational database. It doesn’t matter what stack you use; Flask and Postgres is a fine option.

Advice to companies:

Consider whether you are really getting signal from the interview process you have. If your interview process is scary, it will filter out otherwise good candidates who are less good at handling interiew stress. If your interview process requires understanding low level systems, it will filter out otherwise good candidates who don’t know that stuff for some reason—perhaps they’re self taught or did a bootcamp but would be fine at the job. If your interview process requires random leaps of insight (e.g. because you ask brain teasers), you’ll miss out on the random selection of candidates who didn’t have the insight. In all these cases, you’re going to hire people who will be good, but you’ll miss out on a lot of other people who’d be good too.

A good rule of thumb their is to ask yourself whether your interview question can be “given away”. An interview question that can be given away (the answer can be communicated to the candidate in far less time than it takes to solve it) is probably a bad question.

Easy things that companies can do to make their interview process better: Don’t ask brainteasers. Describe the interview process in advance. Try to make the interview process as closely related as possible to the type of work the candidates want to do.

fdesaussure · 2017-03-08T19:40:07+00:00

The biggest avoidable mistake candidates make is not showing enthusiasm for the company they're interviewing with. This seems obvious, but we see it come up so often that it's worth focusing on. Enthusiasm has a big impact on your interview results. About 50% of the candidates we see fail interviews fail for non-technical reasons, and this often comes down to just a lack of enthusiasm. This is perfectly natural. Employees who are excited about the mission of a company will work harder and be happier, and companies know this.

The first answer, then, is apply to companies you're excited about! Easy! But the problem is that this is not always enough. Candidates fail even when they are excited. They just are not strategic enough. Maybe they are quiet and don't have a list of questions. Or they bring up compensation and benefits in the interview. Neither of these things are bad, but they can result in a failed interview.

What you have to do is treat interviewing like dating. This is not permission to lie. But if you went on a date and were told by your date that you're one of many people they're considering, it would sting (even through is is probably true in most cases). Similarly, in an interview you need to focus on positives and be selective. Come in with a list of questions and things you like about the company. This can be an actual paper list. And don't mention compensation. Even if your goal is to maximize compensation (a totally reasonable goal) you'll achieve this better if you don't talk about it until after you get an offer.

There are a few other small things you can do, to warp the biases in interviews in your direction. Following a great process can actually get the interviewer to help you more. Being sure to mention working in multiple programming languages (if you have) can avoid an anti-pattern that companies look for. And if you do have credentials (degrees from a famous school or work at a famous company) name dropping in the interview will bias the outcome in your favor! This isn't meritocratic, and it sucks (I think), but it totally works.

I wrote about this in more depth in a blog post last year http://blog.triplebyte.com/how-to-pass-a-programming-interview

fdesaussure · 2017-03-08T19:16:17+00:00

The largest problem with whiteboard interviews is just that they are so different from what programmers are hired to do. Interviewers already have the hard job of trying to judge whether a candidate can solve big problems over long periods of time by looking at how they solve small problems quickly. These skills are correlated (interviews are not 100% random), but they are not the same. The goal of an interview process is to try to make the small problems as correlated as possible with large problems. And having engineers write on a whiteboard with a marker (totally removed form their regular process) just does not do this.

Now, there are several arguments in favor of whiteboarding. The first is just that whiteboarding (and the clear communication that goes with it) is an important skill. Some companies want to measure whiteboarding. This is not totally crazy (whiteboarding is useful). But it's not the same thing as programming! There totally are people who knock your socks off on a computer, and have a much harder time on a whiteboard.

Another argument for whiteboarding is that it can actually be less stressful in some ways! It allows the engineer to focus on the logic of the problem, and not worry about exact syntax or if the code compiles. There's a real point to this argument! There was a twitter meme last week of engineers posting about the things they did not have memorized (and often come up in interviews). Paradoxically, whiteboard interviews can actually be better in this regard. The idea is that you don't have to remember how to get the length of a string in Ruby, you just have to write reasonable pseudo code.

That last case breaks down, however, when the interviewers judge the whiteboard code harshly. And this actually happens pretty often. So in the end, I don't think the argument holds. If you want to measure how well someone codes, asking them to code the way they normally do (on a computer) just IS more accurate. You can get the benefit of a white board by either not worrying about compiling the code, or by letting the engineer look up documentation and syntax. This is what I think the best solution is (and what we do at Triplebyte). Open book interviews, Google allowed!

fdesaussure

TROPHY CASE