Search Results for "interviewing"

Skills a Bootcamp Doesn't Teach You: Part 3

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.

View Post

Skills a Bootcamp Doesn't Teach You: Part 4

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).

View Post

Skills a Bootcamp Doesn't Teach You: Part 2

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...

View Post

Skills a Bootcamp Doesn't Teach You: Part 1

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...

View Post

What Not to Say at a Recruiting Event: Perspective from the Other Side of the Table

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.

View Post