When I talk to current or recent bootcamp students, I'm often asked about how to break into the consulting field as a developer. Technical skills are certainly important, and you need a baseline of knowledge in order to speak intelligently with your peers and customers. However, soft skills are critical in landing a job, developing relationships, and navigating difficult situations on the job. Some of my favorite resources for developing soft skills include: #### [The 2-Hour Job Search](http://2hourjobsearch.com/) by Steve Dalton People hire people they like and want to work with 8 hours a day. This book is an excellent resource in learning how to get out of the job application resume blackhole and to dive into conducting "informational interviews" with people at your target companies. Along the way, you'll pick up a bunch of interpersonal skills, and maybe even a few lasting relationships. #### [Insight](https://insight-book.com/) by Tasha Eurich Ever meet someone whose impression of himself is wildly off from the way people actually perceive him? We all have that coworker or friend-of-a-friend. This book describes the secret to soft skills success, which is learning to process feedback and become more self-aware. #### Mentorship Nothing replaces having strong relationships in the tech community. Don't wait for your company to assign an official mentor - reach out to people you trust, and go out on a limb to contact people with whom you'd like to have a relationship. They'll be able to give you the most relevant feedback and a distanced perspective. <br> #### Mock Interviews In job seach mode, my husband and I interviewed one another frequently to practice both technical and soft skills. Communication, listening, negotiation... they're all practiceable, repeatable skills with enough time. It may seem like magic, but it's not. <br> --- Next up on the blog? My favorite resources for the job search and for developing technical skills right out of a bootcamp or undergrad.
Plenty of articles are written about employers recruiting for culture fit, but it's harder to find advice from the other side of the table. It is just as difficult for you to get a taste of company culture in a short series of interviews as it is for them to evaluate your technical skills and social fit with the team. However, figuring out early whether a company's values align with yours can save you months, or even years, of tension and frustration on the job. The hardest part comes down to __asking the right questions__ (without sounding pushy) and deciphering the sometimes-nebulous answers! Here's an example of a telling exchange: > __Candidate: "How does your company value work-life balance?"__ > __Interviewer: "Well, we get evenings and weekends off, if that's what you mean!"__ (after sending the candidate a follow-up email at 11pm the night before) __Translation:__ No, getting evenings and weekends off is not what you meant. Listen for concrete, meaningful examples of how a company either lets their employees strike a balance and recharge outside of work, or how they work employees into the ground. Other tips? Try to make contact with employees who are in similar roles, or even on the same team as the position you're targeting. They will often give the unfiltered truth and do not have to worry about the implications of communicating through an HR channel. You can also ask probing questions about whether or not the person you're talking to values spending time with his/her coworkers outside of work. Once you find a good culture fit, you'll reap the benefits of a positive, upward career spiral.
A coding bootcamp is a fantastic accelerator for learning practical development skills. However, there are some skills (both technical and soft) that a bootcamp doesn't or can't teach you. Part 4 of this series explores learning how and when to ask for help when you're truly stuck as a junior developer or as the new person on a team. ### Humility and knowing when to ask for help Sometimes self-sufficiency, Google mojo, and crossing your fingers just aren't enough. Especially if you're struggling with topics that are specific to your company's business domain or that aren't readily "Google-able", there are times when you can only go so far by yourself. As a new employee, asking for help can be a tumultuous situation rife with politics...you don't want to seem dumb, but you also don't want to bang your head against a problem just because you're too proud to ask someone. However, swallowing your pride can get you un-stuck quickly and feeling happy about your work. #### Remedies: - Develop relationships with colleagues away from the computer. Often people seem too busy to make small talk, but relationships are best built at "the water cooler," and people are usually open to small breaks throughout the day. Building common ground with a teammate can lead to a better working relationship. People are usually more willing to help you if they've gotten to know you at least a little bit. - If a colleague with valuable information (think "tribal knowledge") seems unwilling or too busy to help, try to schedule time in a style that he/she prefers. Some developers prefer that you send a calendar invite to block off time; others are more flexible and willing to engage in the moment. Get to know the people on your team and how they prefer to be approached. Also, try to understand the situation a busy colleague might be in. Is a project going live soon? Focus your effort on approaching them after big deadlines have passed. - Let go of your ego. I often think back to the questions I asked in the first few months on the job, and I blush at the thought of them. But, in the end, I'm not embarrassed. I needed that information at the time, and everyone has been the new person on the team - just make sure to seek out people who can actually empathize with you and remember when they were new (there will always be arrogant jerks).
The topic of the day? Self-sufficiency. To be fair, the bootcamp does teach this skill to some extent. However, the most successful bootcamp students, and subsequently, the most successful junior developers, master this one. It's even a valuable skill outside of tech... ### Self-sufficiency The main point? Avoid being the employee who asks the developer next to her a question that's easily Googleable and then blocks off hours of the developer's time to go over these items. I have a golden rule that if I'm going to ask a senior developer for his/her time, then the first page of Google results for the main topics I'm struggling with better come up purple. I also try to come up with at least 2 ways to approach a problem so that I can present options I've researched to someone who is trying to help. #### Remedies: - Learn the tricks of Googling for the best results. - Documentation is your best friend. It can seem daunting during the bootcamp, but as you learn more, it will become less intimidating and much more useful. Don't be afraid to go down the documentation rabbit hole - you will come up having learned a bunch. - Learn the patterns of searching for information. Documentation is usually structured in a similar way across languages/technologies. Keywords/tags can be useful on Stack Overflow. If you notice your search terms aren't pulling up relevant results, see what paths lead you to more success.
ICYMI, last week I started a series on skills that a bootcamp doesn't teach you out-of-the-box. In an attempt to supplement the bootcamp student's tech education, I'm sharing some lessons I've learned in the first year or two on the job. Tip 2, without further ado... ### Error handling My bootcamp exposure to error handling could be summed up as: "Try-catch blocks? Sure, I guess you could use one of those." However, I can't stress enough the importance of learning where and how to appropriately throw or catch errors. It doesn't seem too important until you're faced with a customer with thousands of documents piling up in a system because your script blew up on a lousy null pointer. #### Remedies: - As you build your own projects, don't just gloss over the try-catch blocks in tutorials and think to yourself, "I'll deal with that later." Learn how to properly present errors to the user and how to elegantly let a script error out. - Learn to write meaningful error messages and implement (when appropriate) custom exception classes. Make them meaningful not just to you, but for the developer after you. - Know when to throw an exception when it truly is an exception. I'll leave the explaining to the [Microsoft Docs ](https://docs.microsoft.com/en-us/dotnet/standard/exceptions/best-practices-for-exceptions "Microsoft Docs")on this one...
As a recent (well, turning not-so-recent as the 1-year mark fades into the distance) bootcamp grad, I'm often asked by potential and current students what lessons I learned as I came out of the bootcamp and dove into the "real world." The transition out of the safe bootcamp cocoon and into being responsible for troubleshooting production code as the sole developer on a project was not an easy one. I hear these sentiments echoed by many fellow grads and junior devs - people seem to agree that the first 3-6 (or even more) months in your first dev job can certainly be invigorating, but it can also be overwhelming and frustrating. If you've recently graduated or are about to soon, hopefully these tips will help supplement the bootcamp experience and ease your transition into that first, coveted dev job. This is tip one, with many more to come: ### Debugging/troubleshooting code in a larger system No matter how many capstone projects you complete with fellow bootcamp students, the experience of debugging a larger code base with multiple systems interacting in a tangle of different styles of code will be jarring. In an academic setting, it is hard (read: impossible) to mimic the architecture and complexity of a system with multiple layers. You will definitely face the challenge of staring an error message in the face and having to dissect exactly where the problem lies while thinking "I have no idea where the hell that message is coming from." #### Remedies: - Observe how more senior colleagues (or, if your company has them, tech support reps) triage problems. Learn what tools they go to first and how they eliminate environmental factors one by one. - Get familiar with reading stack traces and learn how to find the root cause of an issue, not just its symptoms. The top-level error message can often be a red herring. - Contribute to open source projects or start to build your own. The beauty of open source projects is that they give you direct experience trying to understand someone else's train of thought. - Say "yes" to learning new technologies. Just because your job description didn't include learning a new stack, operating system, tool, or language, doesn't mean that it won't be useful to you. The best developers on our team are able to debug not only the OnBase side of our code, but also the 3rd-party systems with which we integrate. Stay tuned for more...
Over the summer, I said yes to a last-minute volunteering opportunity to represent Hyland at a recruiting event. It was a typical set-up, with a couple of us manning a booth and triaging a stream of job seekers, people generally interested in tech, and even some mayoral candidates (no, I'm not kidding). I had always followed the canned advice of how to behave at a recruiting fair as a candidate (look presentable, have copies of your resume handy, etc.), but being on the other side of the table reinforced why this kind of advice is repeated so often. My colleague and I were both developers representing the company. Since we didn't have titles on our name badges, people approached us as if we were in HR. To me, that would've meant they would try to make a good impression. However, I got quite the grab bag of strange interactions with people. It may come as a shock to you, but the following are some behaviors that are repulsive to recruiters (or just enthusiastic volunteers like me): - __Standing Too Close:__ Personal space is important. Enough said. - __Personal Hygiene:__ Closely related to the above point, make sure you shower since you'll be in close proximity to people making decisions about your livelihood. - __Overly-Aggressive Elevator Pitches:__ The employee on the other side of the table is a person, too. They want to have a conversation, not to be talked at. - __Poor Preparation:__ The most frustrating question to hear is something that is easily Googleable..."What does this OnBase, wait - is it called Hyland - company do?" will not make you stand out as a candidate. - __Not Asking Questions:__ On a related note, recruiting fairs are the time to ask those questions that you can't get through stalking, I mean, researching the company! Taking the time to ask thoughtful questions goes a looooooong way. - __Approaching the Booth and Saying Absolutely Nothing:__ Recruiters don't want to painfully struggle to string along a conversation that's dying. They'd go on a blind date for that. You should drive the interaction with good questions about the position you think you'd be the best fit for. A conversation has ended poorly if it closes with the recruiter saying "I'm not sure, but you can feel free to expore our current postings online and apply!" On a final note: recruiters' mailboxes are probably teeming with messages from eager candidates, but people who don't have to make hiring decisions (me, me!) can be a great source of information and, if you're lucky, give you the unfiltered truth about a company's culture, work/life balance, day-in-the-life, and the answers you're really looking for. Grab the low-hanging fruit of making that cold "call" on LinkedIn...you'd be suprised who bites and how much intel you'll gain.
Blog powered by: Contentful API and CMS, Handlebars.js, Node.js