1. talesofscienceandlove:

    Three JKUAT female students Tuesday May 27, 2014 won the Safaricom Technovation Challenge, for developing a mosquito repellent application dubbed Quitmosquito. The Second year Computer Science majors comprising Pauline Mbabu, Caroline Kimathi and Nancy Adhiambo emerged top with their innovation that employs ultrasonic sound frequencies to cause stress to mosquitoes, hence keeping them at bay. The App also integrates a music player for entertainment and to minimize user irritation at low frequencies. - @blackfemalecoders

    Thanks talesofscienceandlove for adding the pic! :)

    (Source: jkuat.ac.ke)

     


  2. Three JKUAT female students Tuesday May 27, 2014 won the Safaricom Technovation Challenge, for developing a mosquito repellent application dubbed Quitmosquito. The Second year Computer Science majors comprising Pauline Mbabu, Caroline Kimathi and Nancy Adhiambo emerged top with their innovation that employs ultrasonic sound frequencies to cause stress to mosquitoes, hence keeping them at bay. The App also integrates a music player for entertainment and to minimize user irritation at low frequencies.

    I hope they’re able to make it to San Francisco!!

     


  3. Rape and sexual violence is used as a weapon of war around the world. It destroys whole communities and ruins the lives of women and men, boys and girls.

    Over the last 18 months the political will to tackle these terrible crimes and injustices has dramatically increased. But political condemnations rarely lead to action on the ground. Angelina Jolie, the Special Envoy of the UN High Commissioner for Refugees, and the UK Foreign Secretary, William Hague, are hosting a Global Summit this June in London to bring together governments, civil society, media, military and judiciary to turn political will into practical action.

    It will be the biggest meeting ever held of its kind.

    In addition, the Dutch Embassy in London, UK Foreign and Commonwealth Office, MakeSense and Chayn will be combining forces to offer a #EndSVCHack hackathon for envisioning and designing technical solutions to combat sexual violence in conflict.

    These technical solutions will focus on supporting the four aims of the summit, which are: 1. Reporting and Documenting Sexual Violence 2. Supporting Survivors 3. Promoting Gender Equality 4. Improving Collaboration between Organisations and Activists

    Ideas will be crowdsourced beforehand and participants may choose from those submitted, or generate their own.

    This. sounds. so. dope.

     


  4. "Fake it until you become it" — Amy Cuddy

    I just watched this incredible Ted talk from social psychologist Amy Cuddy where she discusses using nonverbal communication (aka body language) as a way of influencing how you feel about yourself.  The most inspiring part of this talk for me starts at minute 16:02, where she tells the story of how she dealt with impostor syndrome and then was able to help a student overcome it as well.  I found it particularly inspiring because it reminded me of all of the points in my life and my career where I felt I didn’t belong and was terrified of what would happen when those around me suddenly discovered that I was not “supposed” to be there.  And the reasons I thought of to rationalize this impostor syndrome ranged significantly but in the end, despite those reasons, I deserved to be where I was.  I know I’m not the only one who has dealt with this, especially as a software engineer —- I have had talks with so many people of various backgrounds who felt they weren’t worthy of what they had achieved, despite all of the facts demonstrating the opposite.  I love Amy Cuddy’s philosophy of utilizing nonverbal communication as a way to combat that mentality and change how we view and appreciate ourselves.

     


  5.  


  6. A Quick Word on ‘The Stanley Parable’

    I played 'The Stanley Parable' tonight and it was seriously as awesome as my coworkers hyped it up to be.  If you haven’t heard of or yet played ‘The Stanley Parable,’ it’s a PC game out on Steam that is about a man named Stanley—well, I can’t tell you the rest or I would ruin the game for you.  It’s a not a long game at all: the first time around took me just under 2 hours and the second time from start to finish took less than 5 minutes.  It is the kind of game that made me think, not just about the gameplay but also about my own life.  It’s a game that reinforces the idea of agency (or questions it?) and I spent quite a bit of time afterwards reflecting on what ‘agency’ really means.

    I think agency can mean something completely different to each individual and is highly dependent on context, circumstance and possibly even previous choices.  I still can’t believe I switched up my whole life only just 8 months ago to move across the country to New York to pursue a program that seemed too good to be true and ended up being so good and completely true, only to then afterwards drive cross-country and land in the bay area.  I’ve been thinking about this quite a bit recently but, after playing this game, I realized it’s not just the consequences of the choices I made that make me feel a sense of agency; it’s the fact that I made these choices for myself.  It feels like a pretty powerful realization to have now that I’ve had it but it’s also something that I think we all so easily lose sight of when life isn’t going the way we want.  We tend to forget how much choice we really have.  We always have the choice to make our own choices, and each choice leads to another set of choices.  To bring it back to computer science terms, maybe life can be described as a decision tree where each node has an infinite number of branches from which we can choose to move to a next node to form our individual path.

    I encourage you to play ‘The Stanley Parable.’  You might play it and have a life epiphany like I did, or you might play it and think it’s silly. Either way, the choice is always yours.

     


  7. Why my first job was crucial (& what I got out of it for the next one)

    Hey Coders!  I’m finally in the Bay area, after all of the adventure it took to get here, including a crazy fun cross-country road trip.  I have officially landed on one single spot on the U.S. map and I’m happy to start calling the Bay area home.

    It’s been nearly a month now since I started as an engineer at Apportable and it has already been a blast.  My brain feels like it’s overflowing everyday with all of the new knowledge I’ve been acquiring.  Plus, I’ve gotten to help out with some really awesome projects so far, including working on the android version of this awesome game called OLO and representing our company’s booth at the Game Developers Conference last week.

    One of the aspects I have loved so far about starting at Apportable is how encouraged I was to just jump right in.  Though not required, they hope that new engineers can try to push code, regardless of how minor or major a change, on their first day.  Before my first day, I was feeling a bit intimidated only because it seemed like such a huge feat.  What if I didn’t understand the system well enough?  What if I still didn’t know what I was doing by the end of the day?  What if I wasn’t as experienced an engineer as I thought I was?  (Oh, impostor syndrome…).

    However, upon getting there, I realized that despite a number of differences from the atmosphere of my first job at Lexmark, there were also quite a few things that stayed the same or at the very least were familiar enough for me to pick up new things.  For instance, having gained a thorough understanding of Git from my previous job, I was able to jump right in and pull down the code I needed to start working immediately.  Having experience with build systems and Makefiles made it easier for me to understand how to build this platform I was working with for the first time by equating similar concepts that I had previously encountered.  And though the developer tools I now use at Apportable are not the same ones I used at Lexmark, having that prior workflow at Lexmark and knowing how I needed to set my workstation up to make myself the most productive I could be allowed me to set myself up in a matter of hours, rather than the number of days that it took the first time around.  By the end of my first day at Apportable, I pair programmed on a small project and was able to push some code changes and submit them to the rest of the engineering team for code review.

    The idea that prior experience helps inform new experiences seems obvious to me now, but I was super unaware of this while at my first job.  Back then, I had just come out of college and had no experience with things like version control, various text editors (and the shortcuts to make them more convenient to use), build systems, working with a super huge codebase….basically many of the tools and experiences that make up the daily life of a Software Engineer.  All I knew then was that I was eager to code.  Now I know there’s more to it than that: there exists a plethora of tools and resources that I can assemble to form a workflow that allows me to code more productively and efficiently (which is the reason I advocate computer science education programs incorporating classes on dev tools as part of their “software engineering” tracks, but I digress…).

    Though I was less attuned to it then, I know now just how much my first job taught me and how invaluable that knowledge is.  And thankfully, the foundation provided to me by my first job has helped support the weight of the new knowledge I’m acquiring everyday at my new job.

    If you have any insights you’ve gained from your own work experience, I’d be happy to post it!  Message me or email blackfemalecoders at gmail dot com!

     

  8. Hey everyone!  I’m currently moving cross-country to start my new job with Apportable in March.  Woohoo!  This means, however, that I won’t be as available as I would like to be during this time.  Boo.  Keep a look out for posts and awesomeness to start back up again in full swing in mid-March.  I’ll have driven across the country, started my new job and my new life in the Bay Area by then so I’ll have way more cool new posts and coding projects to talk about. :)

    Happy Black History Month and see you in March!

     


  9. print “Hello, World!: Notes on the Technical Interview\n”

    It’s been a little while since I last posted but that’s because I have been dedicating nearly 100% of my time to job hunting since finishing Hacker School in mid December.  After a seemingly never-ending and rather stressful job hunt, I am proud to say that I will be starting a new position as a software engineer with a company called Apportable!  Apportable is awesome — they have developed a platform that allows iOS apps to run on Android.  Their core mission is all about supporting iOS developers by making the process of converting their apps as seamless and easy as possible.  I love their sense of community spirit.  Plus, seeing as my interview involved some really awesome kernel hacking, it only makes sense that I would totally fall in love with them.

    Now that I have essentially found my dream job, I wanted to take some time to reflect on the process.  I’ll start off by stating the obvious:

    • Job hunting is hard
    • Interviewing for programming positions is hard
    • Interviewing is exhausting
    • Job hunting sucks until the very moment it becomes rewarding.  And then the relief comes.

    Knowing all of that, I think what really helped me get through it was attempting to turn what normally is an exhausting and stressful process into something really fun and enjoyable.  I’ll get into how I did that a little later, but first:

    What is the process of interviewing for a tech job like?

    The interviewing process tends to be pretty standard across most tech companies.  What normally happens is an exchange between you and The Company:

    1. You send in your resume and/or fill out the application for the job
    2. A recruiter from The Company emails you to schedule a time to talk
    3. You and The Company (either the recruiter or a hiring manager or an engineer) talk on the phone about the position, what you are looking for, your background, etc. (Note: you may get asked a short technical question that is meant to just demonstrate your understanding of basic coding concepts)
    4. Hooray, The Company likes you!  They now set up a time for you to skype/phone chat with an engineer where you will be asked to solve at least one coding problem.  This is meant to demonstrate your coding proficiency.  (Note: some companies do 2 skype/phone interviews, some just do one.)
    5. Hooray again!  The Company thinks you did great and they now want to bring you into the office.  They schedule a time to bring you in. (Note: They also will fly you out and put you up in a hotel if you are from out of town.)
    6. Once you’re in the office, you will have 4-6 1-hour long interviews scheduled for the day.  At least half of those interviews will involve coding in front of the interviewer, either on a whiteboard or on a computer.  The other interviews are usually with managers and they spend the time asking you more about your background and the projects you’ve worked on.  They see how well you “fit” the culture of the company.
    7. After that incredibly long day, The Company gives you either a yes or a no.  The response time varies and could range from the very end of the in-office interview to several days later.

    It’s a pretty long process.  So you can see how doing this over and over again, and often with multiple companies in parallel, can get to be pretty draining fairly quickly.

    Making the scary “Tech Interview” fun

    How do you make this long, drawn out, kind of scary process fun (or at least a little less scary)?!  Well, the easiest answer is attitude.  I like to think of my coding interviews not as a test but as a conversation between me and the interviewer.  The context of the conversation is the problem I’m trying to solve, and the interviewer and I discuss different approaches that can be taken to solve it.  Then I write out an approach on the whiteboard and we have a discussion about that approach.  Thinking of it that way tends to make it a lot less nerve-wracking for me and also allows me to forgive myself more easily if I make a mistake.

    Here’s a list of some things I do or try to keep in mind while I’m coding at the whiteboard in front of an interviewer:

    • I smile a lot.  Smiling relaxes my face muscles and makes me feel less tense. It also makes it much easier to keep things light and make the interviewer feel more at ease with me.  Sometimes the interviewer is just as nervous about having to interview someone as you are about being interviewed so smiling helps both people feel more comfortable.
    • I think out loud.  Any processing that is going on in my head, I just spit it out as I think it.  I’ve found that most interviewers I’ve encountered find it useful to know what’s going on in my head instead of having me just stand at the board in silence indefinitely.  That way they can interrupt me if it seems I’m going down a rabbit hole and redirect me towards the solution.  It also helps keep the interviewer engaged.
    • I draw my ideas.  I’m a really visual person, so I’ll end up sketching out my ideas on the board while I’m trying to think through the problem they’ve asked me.  As I sketch it out, I’ll talk through my understanding of the problem and how I’m thinking through the solution.  If I’m wrong, the interviewer can help me understand where I got off track and then clarify what I misunderstood.
    • I ask for feedback.  If I’m unsure about something, I’ll ask the interviewer to either further clarify or I’ll ask if I’m understanding the problem correctly.  This is especially useful if you have an interviewer that doesn’t seem to be engaging with you while you solve the problem.  While some may disagree, I think interviews are meant to be interactive.  Interviews are bi-directional: you are checking them out just as much as they are checking you out.  Based on your interaction, can you see yourself potentially working with that person every day?  I have found that observing how your interviewer approaches your interview can help give you a sense of how they may interact with you as a coworker.
    • I don’t chastise myself if I make a mistake.  This one is key.  It’s very easy for me to fixate on getting something wrong, even if the mistake is a minor one.  Fixating on a mistake while at the board only distracts me and makes it harder to focus on the task at hand.  If the interviewer gives me feedback indicating that I got something wrong, I immediately tell them they were right and thank them for the correction.  Acknowledging the mistake and even just the act of talking itself helps me release some of the anxiety.  I then forgive myself in the moment and forget the mistake altogether so that I can redirect my focus back to solving the problem.  I find that this really helps me stay on track and remain calm throughout the interview.

    These are the actions I recall taking in the moment while interviewing.  Doing these things doesn’t make the process any less tiring, but it can certainly help turn a super daunting day into a really fun and engaging day.  I had really awesome conversations with engineers from a bunch of companies and got to solve some interesting problems.  I think companies also like seeing an interviewee with a positive attitude because it makes the process more fun for them too and keeps the atmosphere light.

    Good luck to those currently job hunting and, per usual, email blackfemalecoders@gmail.com if you have any questions!

     


  10. Does the idea of digging into the Linux kernel sound just as equally awesome and overwhelmingly daunting to you?  Well, fellow Hacker Schooler and dear friend Julia Evans wrote an awesome post to help squash those fears by proving the seemingly impossible: Linux kernel hacking is totally doable and not scary! Shhh, it’s no longer a secret…