15 years ago job hunting for entry-level jobs was not as tough as it is today, but it still wasn't easy. Here's a screenshot of my Gmail when I was first starting out. In addition to job hunting on Monster, and other job boards, I'd scour Craigslist looking for any job or gig that just gave me something to add to my resume/portfolio - for whatever cash they could afford. I cast a wide net (as you can tell by some of the subject lines...somehow I was a "photographer" who didn't even own a camera). My hope was with enough projects, I could eventually build up enough experience to land a job, and (eventually) it worked out. Here's the bit worth noticing: There's a lot that never replied. Some did, but still went nowhere. Eventually just 1 of those emails (the top one) turned into a project. That project helped me get interviews. The many interviews turned into 1 just one job offer. Things quickly got easier from there. So while today may be even harder, I

If you're looking to showcase your skillset to hiring managers, consider: large projects can be diluting your skillset. Unless you're trying to look entrepreneurial, structure your projects so each of them shows a different technical skill.

Seeing some Entry/Jr Coders talk about submitting 200+ applications - I mentioned this in my infographic thing I posted yesterday, but want to emphasize it more: If you're not tracking where you've applied you absolutely , 100%, need to be. It's not about creating a list to keep count - there's important data in there. If you've applied to the same company 5x and they're bad about getting back to you, save your time. Or maybe it helps you save face from applying twice to the same place. If you're bad about remembering when you should follow up - tracking your next actions will help you. You can even get more analytical with it: Say you just updated your resume, and suddenly you are getting more responses (or less responses) - you'll be able to track that. Lastly - you 100% absolutely should mention this in the interview. From my vantage as a hiring manager, hearing how someone organizes their job hunt tells me so much about how they'll organize their

I've never made an infographic, but thought I'd try my hand at it. Anyway, here are some tips for all those coding bootcamp grads who are about to start their job hunts.

If you've been looking for a job for months and haven't had traction, know that  interviewers can sense desperation, bitterness and frustration. It's hard to fake enthusiasm. If you're feeling burnt out, it's going to spill into the interview, and even if you land the job - it'll spill into your first few weeks. Try this: Pause: Recharge. Give yourself a few days away from it. Seriously. Don't cheat. Do something you enjoy doing - and do it because you enjoy doing it, not because you are frustrated. Nothing ruins a hobby more than having a cloud hang over you. Give yourself the opportunity to relax. Give yourself a break. Revamp: When you're ready to start again, update it all. Your resume, your portfolio, your LinkedIn profile. By having a new resume, portfolio, YOU will feel fresh, new, re-invigorated, motivated. Maybe you'll spot things in your old resume that may have worked against you. Even if you fix something trivial like an extra comma, you&

This awkward picture of me was taken more than 15 years ago - 1 day after my last college final, and 1 day before my first professional interview. I spent the last of my student loans at Sears to buy a poorly fitted shirt, flowy dress pants and tie that the salesman had to tie it for me. I was nervous because I was graduating with a Physics degree but ultimately just wanted to code, code, code. These were the days before bootcamps, when almost all coding jobs expected you to have a CompSci degree. I was thrilled when I got the offer. The 3 people who interviewed me will always hold a special spot in my heart. They saw past a lot: the lack of experience, the wrinkled shirt, the general naivete, the lack of a CS degree. They got to know me and what I was hoping to do. They knew I was begging for a chance, and they were willing to give it. As a result, I never wanted to let them down (and still don't to this day.) They forever influenced my own approach to hiring because they showed m

- I can't disclose my level of talent until the offer stage, but I can assure you my talent and effort are certainly competitive. - As a rock star dev, I'm looking for a Madison Square Gardens place to work. But on a more serious note - you can take any standard interview questions and redirect it to ask some very interesting questions: - How do you stay current with the latest tech trends, and keep your code base from growing stale? (Honestly: Why does anyone expect candidates to be more up to date than their own code base?) - Tell me about a time when the team had a conflict. How was it resolved? - It looks like you this role has been open for a few months. How has the team adapted? (You'll get asked about gaps in your resume, you should definitely ask about gaps in resourcing.) - If this role is a backfill, why did the last person leave? - I'm curious to know about a recent challenge the team faced, and how they overcame it.

Over the last year, I've seen many struggle to break through the Entry-Level Coder barrier. It's a tough challenge, and it's easy to lose confidence. What I wanted to do is offer perspective by describing the process (for better or for worse) from the hiring manager's perspective and *why* it can be so tough for job seekers. What's described below is not specific to one place but generalized across companies of various sizes. I think the industry can do better and this is an attempt to highlight the tricky parts of hiring so we can make the process better and do right by those entering the industry. This next one's dedicated to people like DeVontae Moore, Joseph Edmonds, and Dakota Coppage who have tons and tons of grit. If you're a hiring manager with an open spot, you should keep an eye out for those who are persistently grinding away to land that first job.

Hosted the first ever code/collision tournament last week - it was really exciting to see the strategies come together and duke it out. Big thanks to Connor Ellsworth, Gabrielle Tobermann, Nathan Baldwin, and Jason Garey for participating!

After covering portfolios, and interviews - and realized I should cover resumes. This stuff is based on 10+ years hiring devs and what I and many hiring managers typically look for. (It's also the format I use for my own resume!)

With the Holidays, December can be a slower month for interviewing. That makes it a great time to practice! Here are some tips on how to set yourself apart from other candidates.

People talk about 3 years going by in the blink of an eye. That's not always the case. Not if you knew someone like my brother, Sal. He passed away 3 years ago today - and, if you knew him, you'd understand what I mean when I say: 3 years feels like forever. My brother used every second. No exaggeration - he was the type of person who celebrated his 1 billionth second on earth, and looked forward to his 2nd billionth. If you ever travelled with him, you'd undoubtedly experienced those times when - at the end of the day, just as you were getting ready to turn in for the evening - he'd come up with some plan to drive 90 minutes somewhere, without telling you where and only promising that 'you'd love it.' And you knew you could trust him on that. Maybe you'd protest, but ultimately you'd go - and after having a great time, you'd be cringing as you waited for him to say "I told you so." But he never would. He was the kind of person who woul

With Thanksgiving almost upon us, most hiring managers are likely not going to review anything until after Thanksgiving. This is a PERFECT time to work on your portfolio and GitHub. Here are my quick thoughts on how you can build something that will really help you stand out. Update [5/19/2022]: Now that you've build your portfolio MVP, check out your next steps !

Coding Tip: If you're working on a particularly large problem/feature/technical challenge, step away from the computer. Go for a walk, wash the dishes, sweep the floors - occupy yourself with something fairly routine and automatic, and just think through your problem. If you're overwhelmed and not sure where to start, try this: What does your output need to look like? (Output could be the return value of a function, the output of your application, or the UI) Does your output need to look like that? (Reframe your problem, and spend time thinking of how you might make the problem easier if the output were different from #1) Think of your input(s), and again ask: could you use more inputs, less inputs, or a different kind of input altogether? (Inputs can be function parameters, user input, etc.) Now, work outside-in, top to bottom: You have your input, what's the first thing you need to do to get the inputs in the right state? Should you filter? Should you clone the array? En

Someone I know, someone I consider a mentor, recently called me 'frenetic.' And it was a fair criticism - but one I think that could use a little explaining.

When I was a kid, I wasn't allowed to play video games. That was the rule. I couldn't play them, unless I made them. And that's how I learned to code. I made games in Basic, then QBasic, then Visual Basic, some C++, and then a whole lot in Flash & JavaScript. The thing I loved about coding video games is it exposed me to so many challenges you don't typically see with application or web development. Applied physics, trig, collision detection. My favorite was building a computer player to be my opponent. These days, as many enter development through boot camps, and self-guided course, they leap frog over the amazing world of game development and get right into building applications, missing out on some really interesting opportunities. But it's hard to create games these days: Our expectations for what games need to be are much higher than when I was getting started. On top of that, the languages we use to code games are not what we'd use for application deve

I've seen a lot of resumes in my time. Resumes are one of those things where everyone has an opinion - but having done this for a while, and comparing notes with others that I respect - I wanted to offer up a template I put together that covers everything from: Changing careers, Multiple roles at one company, Project based work, Fitting it all on one page. Give it a look & feel free to share. Let me know how it goes! Resume Template [Google Docs]

If you're looking for growth, one area we you don't want to neglect is our ability to make great pancakes. Sundays are for pancakes, so to help kick start your growth efforts in this critical area I'm sharing a recipe I've been iterating on for 5 years. Place a sieve over a bowl, and add in: 1 1/2 cups all-purpose flour 2 1/2 teaspoons baking powder 1 teaspoon salt 1 tablespoon white sugar Shake sieve to let dry ingredients mix and fall into bowl. Next melt 3 tablespoons of butter (I use the microwave and zap for 19 seconds, and then swirl to to let the rest melt down.) Let the melted butter cool, and while it's cooling add: 1 1/4 cups milk 1 egg to your dry ingredients. When your melted butter is lukewarm, add slowly add it in, whisking until smooth, but allow a little clumping - don't over whisk. Let stand 5 minutes so that the baking powder can do its job and create fluffy bubbles. Heat grill to 235F. Butter up the grill surface. Pour 1/4 - 1/3 cup of batter

Too many hiring managers need to remember: Experience isn't a reflection of how much time has elapsed but by how much was accomplished. 2 years, 4 years, 6 years on one project is less valuable than 2 projects, 4 projects or 6 projects. It's not to say 6 years on one project isn't valuable - there'll be a lot of depth to the candidate's knowledge, but when you're looking for someone with 2 years of professional experience you - you can just as easily substitute that depth with breadth.

You'd think that being a coder for 15 years would have me confident I'm no longer an impostor - and yet, it's still something that I wrestle with. But though the feeling hasn't gone away, I have gotten better about how I manage the feeling and how I respond to it. Here are 5 ways I've learned to address feeling like an impostor.

When it comes to the decisions you make when writing code, you can either be intentional about those decisions, uninformed, or apathetic. Here are 4 ways to be more intentional about how you code.

Continuing with the theme of commitments, I wanted to share a story from earlier in my career. In 2007 I launched a website that went viral. It was bigger than I could have imagined, bigger than I'd dreamed, bigger than I'd intended, and demanded more commitment from me than I had prepared to give.

 

#DadBot v2.0: The new procedural programming interface has been released. Due to memory constraints, only 5 programmable memory slots exist. While a future release may look to expand the memory slots and provide functional programming capabilities, this first release allows the user to familiarize themselves with basic programming and reinforces the need to look a head, and work a problem in reverse.

 #DadBot v1.0: While procedural programming capabilities are not yet available, the user interface allows the controller to familiarize themselves with the basic functions of the #DadBot.

Just a short one this week - rather than listen to me, a recent episode from Adam Grant's WorkLife podcast is worth giving a listen, and considering - especially as it relates back to last week's episode. Adam Grant - How to stop languishing and start finding flow

If you've ever had an idea, an earth-shattering, ground-breaking, disruptively novel idea that inspired and motivated you to go beyond just "Ideation" to "Implementation" you'll undoubtedly know that nothing ever seems as good or as perfect as when it was still an idea. Imagine if that wasn't a problem: The thing in your mind perfectly made a reality. The bit of writing perfectly captures your sentiment and purpose. The drawing, flawless. That bit of code, executing without issue. Perfect inventions, perfectly innovated to perfectly adapt around an ever changing world. Never needing improvement or intervention. Never a "why doesn't this work like planned?" Never struggling with execution. Never a question of skill, only a question of the idea itself.  The 'Imagine' we know is not the 'Imagine' John Lennon imagined. There must have been parts of the 'Mona Lisa' that DaVinci agonized over, and grew frustrated that he c

 If you're not having regular 1 on 1s, or you're unsure of what to talk about, here are 4 things to try out.  These meetings are critical for any manager to build a strong relationship with their team members, and ultimately contribute to the longevity of the relationship.

A strange thing occurred this morning: I normally use a battery-powered ultrasonic toothbrush that does a pulsing buzz after 2min to signal that my brushing is over. Because the battery had died I used a regular toothbrush for the first time in months. 4 mins into brushing, I started asking myself why the the brush hadn't done it's pulse/buzz thing. I continued to brush a while longer when I realize the problem isn't the toothbrush. My exit condition was broken. I had become an infinite loop.

The most critical question when interviewing any candidate is simply: are they technical in the way I need them to be? And yet, time and time again we rely on the same standard set of questions that don't quite tell us how effective someone will be in the role we have. Assessing someone's technical ability in an hour doesn't have to be a stressful experience - for the candidate, or the interviewer. There are better ways to understand someone's skill, and here are 5 ways to go about it.

A fter talking about fears, let's do something about them. Let's make some commitments, and take some steps towards putting them to rest. Maybe all your worst fears about yourself are true - but if they are, taking the right next steps won't keep them true for long.

It's easy to feel overwhelmed by all the terms, acronyms, jargon, methodologies, and techno-babble. So here's a super simple trick that will not only help you learn them, it'll also help motivate you in the long run.

Building "Rugged" software is critical in today's environment where software is used in many ways we can't always predict, and is exposed to attack. Here are 4 considerations when you're building rugged software. I f you don't know much about the Rugged principles, check out: https://ruggedsoftware.org/

After years of interviewing and hiring hundreds of Jr Coders for tech roles, I wanted to offer up the top 5 things I'm always looking for. It's a challenge landing that first job, so hope this helps out.

Calling out my fellow hiring managers: I know you want to think you're doing highly academic research work, but the truth is most of the "problems" you're dealing with on a day to day basis have been solved. The bulk of day to day coding work is no longer algorithmically complex. You need implementers, integrators (and there's nothing bad about that.) You don't need to be DaVinci to appreciate the Mona Lisa. Similarly, you don't need to produce complex algorithms to appreciate them and use them effectively. Stop stressing out Jrs and turning good people away by having them write out algorithms they'll never be doing from scratch. This does not inform you of their skillset. Ask questions around the problems space they'll be working in over the course of their time there: 1) You have a collection of objects and you need to filter based on a property, how would you do this? 2) You need to find the total count of objects that match a certain criteria,

Recapping the responses to the questionnaire about your fears (What are you afraid of, and how do you manage your fears). The responses were interestingly consistent and I was asking myself why that may be, and how that relates back to what this whole experiment with Increments is all about.

Modern IDEs and modern languages have allowed us to really focus on writing the code that matters, the code that solves the problem we're wrestling with. It allows us to ship code faster and produce solutions quickly. But: just like any musician, any athlete, sometimes it's good to occasionally do things the "hard" way just to keep your baseline skills sharp. Here's 5 quick drills to try out once in a while just to keep testing that muscle memory.

I've been thinking a lot about bagels lately. Maybe because I like them. Maybe because I'm dieting. Maybe because in crazy pandemic times, thinking deeply about bagels is a welcome distraction. One of my favorite bagels is a plain bagel with plain cream cheese. But I hate ordering it. It sounds like I'm belittling that which I love. Or perhaps it sounds like I'm proclaiming to the universe that I am undeserving of the more fancy bagels. The truth is that the double-combo of Plain on Plain is a spectacular delight that far exceeds the unfair critical suggestion of its moniker. Said differently, plain bagels are far from plain. I read recently how people should not chase the new and shiny project, until they finish what they're doing. That's something I used to always struggle with - and have had to constantly remind myself of my familiar refrain: Substitute novelty with nuance. Find what is intriguing, interesting, immersive in the thing that has grown familiar,

Ahh, the legendary hero programmer who hath vanquished bugs and pulled marathon coding sessions fueled by energy drinks and fantasy metal. Want to be one? Here are 4 tips on getting to that legendary status...

"The opposite of Play isn't Work. It's Depression." - Brian Sutton-Smith Unless your battling depression, when you're doing it right Work, Play, Life, are all the same thing. I don't get people talking about "work/life balance". If it were a Venn diagram, 'Work' would be entirely inside Life. You can't have Work without Life. I'm not obtuse here - there's plenty who try to make the work take up as much of life as possible, but by virtue of their relationship, Life is the priority. To hijack Brian's quote: the opposite of Life isn't Work, it's Death. Ultimately, I'm advocating for more Play. Play is what blurs the lines around Work. With enough Play, the lines become invisible, and you're just left with Life. It's okay to be silly at work. It's okay to be yourself. If you see Work and Life as two separate things, it means you're living two separate lives. That means you're doing even more work to

Season "0" was just getting started, helping me iron out kinks and figure this thing out... incrementally. We'll be coming back to the topic of Growth many times throughout, but for now we're pivoting to Season 1 where we'll be talking a bit about fears and vulnerability.