Tips, tricks, and advice

Celeste holding a happy balloon, as if giving it to another person to bring a smile to their face.

Do you host interns at your company? I’ve started prepping for my springtime interns already – here’s a document I spun up to help me keep myself sorted as I identify potential projects, prep first-time intern mentees, and generally look forward to hosting an intern in 2021. Do you think I’ve missed anything important? Would you do it differently at your company?

Identify a project

Intern projects should be relatively small, or make up a small portion of a larger project. This makes it achievable in the limited amount of time your intern works with your team. (Be sure to verify how long you have an intern! Depending on your company and program, it can be as short as 6 weeks, though 8-12 weeks appears more common.)

Prep team mentor

Make sure that the mentor is bought in on the project, and thinks the project can complete in the time you all have. Also ensure that the mentor understands the various check-ins that they should be working toward with their mentee. Not just the standard midpoint check-in and final presentation, but also regular CRs, and other process controls, like items in your task-tracking tool.

  • Measurable sprint tasks
    • During each sprint, new tasks should be defined and monitored. The tasks should be measurable and small enough to be completed in one sprint.
    • College students may not have a habit of sub-dividing the project into discrete, measurable tasks, hence the mentor should provide assistance here.
  • Point the intern to right resources
    • In addition to the team specific resources, the intern should also be pointed to useful team or company resources e.g. your internal wiki, so that they can unblock themselves on common issues.
  • Testing is equally important
    • Interns may focus more on development than testing. The mentor should show them how to think about the relevant testing before the implementation e.g. manual testing vs writing tests.
    • If possible, plan to create some metrics for the intern project and compare the improvement from before-state to finished-state.

Work backwards from project acceptance

When you have identified a project, you will want to outline some notes and a success state at the end of the project. The success state is your acceptance criteria. From there, the team hosts (intern’s mentor and manager) can identify intermediate milestones (with the intern, ideally) and the intern can work toward those milestones during the internship period.

Set process checkins

The intern program generally requires two meetings, a midpoint check-in and closing meeting where you communicate your team’s hire/no hire decision to the intern. Those aren’t nearly enough milestones to ensure your intern is working toward a successful deliverable.

Additional check ins that help provide structure include:

  • Weekly 1:1s with the intern’s mentor and intern
    • Provides technical guidance and ensures the intern feels supported in their efforts
  • Weekly 1:1s with the intern’s manager and intern
    • Provides feedback on office norms, guidance on soft skills like working with a team, informs the intern about technical best practices and process controls, may include technical guidance but at a higher level than the intern’s mentor is able to give (since the mentor will have the most context on the intern’s work). Also provides a forum for career growth discussion and setting expectations, in the same way a manager would for a full-time employee
  • Regular cadence for CRs (e.g. every other week, or something else that’s both achievable, and sane)
    • This helps the team provide feedback on the intern’s code as well as improvement over time, and prevents the intern from getting lost and not completing their project at all
  • An early architecture review with the team
    • Allows the intern to work backwards from a success state while getting feedback and suggestions from a wider variety of viewpoints (beyond that of the intern’s mentor and direct manager)
    • Prevents the intern from going off in a wild or difficult-to-implement direction, because of the breadth of technical depth and experience from the team
  • A mid-point review / presentation with the team
    • Shows progress from the architecture review (i.e. the idea) toward implementing the project (i.e. reality)
    • Allows for suggestions on refinements and minor course-corrections
  • A final project review / presentation with the team
    • Demonstrates completion of the project and allows the team to gather more information for their inclined/not inclined vote
  • Consider gathering feedback from intern on their mentor
    • This is optional but would help both the intern mentor improve their future mentorship as well as the intern become comfortable with the formal, professional-style feedback provided on promo docs and in internal annual review tooling (since there’s an absence of either during part of a typical internship period)

Informal check ins between the intern and their mentor and manager should happen regularly.

Team culture / ceremonies / social events “buddy”

Consider pairing your intern up with a team member as a “buddy” in addition to a project mentor. The intern can reach out to the buddy for non-work related questions, or for questions about social or cultural aspects of the team, company, etc. The separation between mentor and buddy helps the intern feel comfortable asking certain – distinct – types of questions of each person. This also encourages the intern to meet more people on the team, from the start!

I started this blog, thinking I have information and interests that may help early- and mid-career technologists. I’m beginning to share tips, tricks, and learnings here. I generated some of these learnings through my own hard work, with years of trial & error. I gathered other tidbits via my voracious appetite for reading and love of sharing what I read. No matter how much work I put in, though, the one key ingredient leading to blog success is reader feedback. If you find any of this article helpful, do let me know (my email’s in the footer of this page). If you’re confused, ask me about it! If you disagree with a point I make, please take a moment to enlighten me. The single thing that I can guarantee will happen if you reach out, is that I’ll listen – if you’re lucky, I may even reply directly. This blog lives and dies on your feedback, so please do share!

I’ll bet you’ve heard your manager, senior staff, and leaders share their rules of thumb for managing their calendar, or scheduling their time. One guideline I hear at AWS is that you should spend 10% of each week learning new skills, or improving those skills you use to perform your job.

You might have heard about the book Deep Work. I’m just tossing it out there, really quick, that you might want to check out. See, Cal Newport wrote the book on reducing distractibility by scheduling Deep Work, and here I am writing a blog post about a different, related concept (and, I suppose, sharing Cal’s idea with you).

The single limiting factor in your schedule is simply having enough time, which leaves you to wonder… Celeste, have you found any rules-of-thumb that we should absolutely apply to our own calendars, and our own process controls?

Yes! I have something I believe you’ll like. I generated an ‘ideal schedule’ for me. I built it through trial and error, observing my emotions and work output each time I changed how I schedule myself over the course of years. I aim for a distribution across the following buckets in a “standard work week” of 40 hours:

  • 10% – about 4 hours – learning new job-relevant functional skills or iterating upon and improving existing ones
  • 20% – 8 hours – sustaining engineering – where I address my current source(s) of technical debt, or prevent more from occurring. Take a look at the article Manual work is a bug, which I absolutely love and live by, and comment further upon, below
  • 10% – 4 hours – get moving, get away from your desk, kitchen table, wherever you’re working and eat lunch, maybe even go for a walk! If I know I won’t need to take notes, I’ve enjoyed walking meetings, where I plug in my headphones and walk to the park a few blocks away, absorbing some nature as we walk and talk
  • 50% – 20 hours – performing core work: planning sprint, documenting programs, managing feature requests, retrospecting, mentoring peers, writing code, executing tests, standing-up, emailing, coaching, pairing, meeting, creating, interviewing, debriefing, offering feedback, managing incoming tickets, managing the ticket queue, escalating problems, sketching ideas, opening tickets to others, 1:1s, and so on – these are the tasks that you prioritize relentlessly, as without completing these tasks, you’re not out-putting any work
  • 10% – the last 4 hours – this gets unavoidably lost through context switching, breaks, and other low-output effort – even so, I try and pay attention here to see if I can further reduce this bucket, over time, and with focused attention to its reduction and eventual elimination

You’ll notice these buckets add up to 100% – exactly 40 hours – like I planned it or something. While I strive for the former, ideal ratio, I understand that nothing’s perfect, either. Some weeks I work more than 40 hours, and others I work fewer. Some weeks I focus primarily on one of my core work functions (like when I write a roadmap document), while others I focus on none in particular, bouncing between tasks at great speed. Some weeks I utilize different buckets, for example when I’m attending a conference and volunteering at a booth trying to recruit new teammates. That could conceivably slot into my ‘core work’ bucket, but I don’t typically categorize work travel into my core work bucket – just a personal preference. You are welcome to categorize your own obligations however works best for you, and if you have a neat spin on the matter, I’d love to hear about the special thing that you do!

You set yourself up for success with a program by scheduling it. Hopefully the scheduling guidelines I’ve shared help you think about the problem of calendar maintenance in a new light, and empower you to own your own time!

Appendix A: Links, Tips, and Tricks

If you were in the office with me, you would already know how much I love this article, since it outlines a dead-simple framework for iterative improvement, encouraging the reader to automate nearly everything in life and work: Manual work is a bug, “The successful engineer realizes that the earlier he starts collaborating, the sooner others can contribute. Together they can create a culture of documentation that spreads throughout the team. Thus, every project is collaborative and has a “stone soup” feeling, as all are invited to bring their skills and insights. The more people who embody this culture, the more success it has.” How thrilling is that!? It’s almost like open source for your office culture. Kind of (I might be stretching the simile a bit too far there.) If you already have teammates who clearly document their code and processes, you know exactly how special they are. Make sure to keep ‘em!

I don’t have as good a reference link for my second tip, but I suggest you A/B test your own life, as well as your own calendar. An A/B test allows the intrepid scientist to compare two treatments for the same scenario and see which has the more favorable output. Say… I know that I’ll be walking to the office in the rain several days this week, but I haven’t quite mastered the art of layering like the rest of Seattle. So on Monday I plan to wear my Patagonia fleece and my hand-me-down rain slicker, and on Tuesday I plan on wearing a barn-find vest, long-sleeved light Goodwill sweater, and a water-resistant canvas coat. I can objectively say which of the two outfits is more comfortable and breathable. Once I get into the office, I will check out how wet I’ve gotten, and see how cold I am (or am not). Both days, I’ll verify the amount of rain that dropped during the walk, and note the outside temperature. This helps me understand which combination of layers is more ideal for keeping me warm and dry during my winter commute. For every test condition and whichever treatment option turns out to “feel better” or increase your output or lets you see your mistakes more easily or whatever…use that! Then, remember to iterate on these improvements, as well.

Between improving your automation and continual self-testing, (and iterating on each) you’ll find your own productivity growing rapidly.

Yes, we all know by now that networking is somehow an essential to succeed in the career world, and there are about a zillion articles on how to network, who to network with, and why networking is so important. And yet, here I am looking to add something useful to the pile. I decided to write this simply because I felt that I hadn’t found the article that I once needed, anywhere in that pile. I’m sharing three steps to networking that feel authentic to me, have provided me with some measure of success, and may or may not gel with how you manage your own personal networking process – either way, I’d love to hear from you, what do you think about my twist on the idea? Keep reading… 😀

I have three steps that I use to network. I think, like many problems that you see articles about all the time, the wealth of opportunity to discuss and break down the issue means that a lot of folks take that opportunity to add their perspective. And on the Internet, it costs hardly anything to publish an article that will illuminate the solution to everyone’s concern. Networking is one of these big, ambiguous problems that we all hear we need to do, but no one seems to know exactly how to go about it. So, here’s what I do to network. I set a goal, build an algorithm to meet the goal, and then review my progress.

First, I start with a goal in mind – I need to meet three new people at this conference because I’m recruiting for an open job req, or I want to ask for help with a specific project and I suspect there’s someone in my circle with expertise in that exact thing (but I don’t yet know who), or similar. The goal needs to be concrete for this to work – I need to meet *three* new people, for example. If I just told myself, Celeste you need to meet some people at this meetup (it’s in the name!) then sure, I could maybe force myself to meet a person but my inner introvert would start squawking and who knows if I’d say hello to anyone after all.

Now that I have a concrete goal in mind, I break it down into its component parts – I build the algorithm for success. I know that there has to be someone in my circle who uses Guice and can help me troubleshoot the Inject problem I am having. How can I get an introduction to them? I can reach out to five people I know who use Java at work, and ask them if they use Guice or know someone who does, and could they introduce me on. Five emails or Slack messages or SMSes takes oh, five minutes to draft and send, and then from there all I need to do is wait for a response. If a day or so goes by and no one has responded, or responded in the negative, I know I need to find five more people to ping. If someone gives me a name, I quickly follow up with that person – as that’s one step closer to my goal.

Throughout the process, I review my progress. It wouldn’t do to forget to follow up with a person I said I’d reach out to, or to sit at that meetup staring at my phone screen, or whatever other idea I can come up with to procrastinate on my networking goal. This ongoing review helps me to iterate if I need to come at the problem at a slightly different angle than I originally thought, and lets me sanity check if I’m being a bit too hard on myself. I sometimes have a tendency to think in very rigid terms, and I might find myself in a spot where I have an 80% solution fall into my lap but I’m so focused on the 100% that I don’t notice the pretty-good option at all – and that’s a terrible place to trap yourself, don’t do it! If I am at a meetup and I’ve met two new people, but the second person has completely entranced me with their story of a product launch gone wrong, I may acknowledge that the event’s ending with me only 2/3 of the way to my goal, but I have developed a promising potential mentorship relationship with the person who’s number 2 of 3, maybe that’s a win. (Or maybe I make sure to shake hands with someone who looks friendly on the way out!)

Review also helps me recognize when I’m done-done. Yes, I have found that Guice expert and they were willing to help me troubleshoot my error, or I have met three new people at this meetup and I can go home and change into pajamas while congratulating myself on my job well done. It feels good to complete a goal, and reviewing that as I go allows me to access a fast feedback loop. (Faster feedback is better than slower feedback, as you can iterate more quickly to success!)

So, knowing now that networking can get broken down into three steps just like any other project you might want to tackle, are you going to give it a whirl? Let me know how it works for you! I’d love to hear your thoughts (and yes, I’m looking for a fast feedback loop on this blog post, you know it!)