So sue me, I've been busy

So sue me, I've been busy


MyLife, MyRamblings, Tech, JobHunting

by Maria on 20 Oct 2014 - 06:56  

This is a longish rambling essay, I mean a super interesting essay, explaining why I haven't posted in so long (I've been very busy!), what I've been up to (talking to people, ye gads!), and some advice for job hunting, especially if you aren't currently worried about employment (cause job hunting sucks and you should worry, er I mean, prepare before you're out there!).

I want to tell you a story. A few years ago, I found myself pregnant fairly soon after receiving word that I would be losing my job. The only reason I mention that I was pregnant is because that meant I really couldn't spend much time job hunting before I lost my job, even though I had quite a few months warning. I would be getting decent severance, so I wasn't too panicked. Yes, the economy still sucked, but it was starting to recover, and tech jobs were the first returning. Other people staying in Seattle from my lab had managed to find new employment before my boss moved, which I also took as a good sign. The last time I had been out looking for work was during the dot com bust, and while it had taken a few months, I had more experience this time. So, a few months after my boy was born, my job went away and I received a rude awakening. The job market had changed.

I've already done a rant about tech interviews, so I won't rant about that again. And of course, the job market had changed in quite a few ways in 12 years, but one of the biggest lessons I learned was the importance of networking in today's market, and how when you find yourself unemployed, that is not the ideal time to start networking. We have all heard about how important networking is, but what does that mean? Well, I think the bottom line is, it means getting to know lots of people that are willing to recommend you for a job. Yes, someone you meet once or twice at a networking event may tell you that their company is looking for someone that has your skills, and they may even get your resume in front of the hiring manager, which is definitely a step up from applying through a website, don't get me wrong, but it is not your most likely route to a job. What you really want is for someone who knows you, your work ethic, your personality, and your skills and also know the hiring manager pretty well, to recommend you. Someone you met at a networking event a few times, just can't do that. So, the way to effectively network is to get to know as many people as well as possible. Not just any people, but people that understand the skills needed to do your job, iow people doing your job or a pretty similar one. You need to get to know them as well as possible by talking shop, and a lot of it, and not just about your favorite movie or whatever. You know you have probably reached that with someone when you would be completely comfortable recommending them for a job, so yeah, this takes a while, and if you can do joint projects, all the better. And then, when you are looking for a job, you should personally hit up every one of those connections, and ask them if they have heard of any job openings you may be interested in. And remind them you are looking on a regular basis, but somehow strike that balance of not being a pest, but keeping your name in their thoughts. I'm afraid I don't have much advice on that last one, and I suspect it depends on the person and the method as much as anything.

So now I can finish my story. The reason I had lost my job was because my boss had moved to NYC, and I was unable to move to NYC. After months of hitting total dead-ends looking for work, my old work called me back in to take down some servers that my former boss had left running. Someone new was taking over his old space, so all of his old stuff needed to be taken care of. I went in and dealt with everything, and started to walk out the door. And then I stopped and went back, because I thought, well I should probably introduce myself to the new person and let her know who I was so she could contact me if she found more stuff or had questions about anything. When I went in and introduced myself, she started asking me about what I had done for Mike, my old boss, and it turned out she was in the same boat Mike was, she had moved across the country and left her programmer behind. Neuroscience research with primates is a small field, so of course, she knew Mike, and so Mike's recommendation was valuable, and skills needed for both jobs greatly overlapped. So, when I finally found employment, it was a combination of serendipity and because of someone I knew well. Yeah, n of 1, I know, but, heh, the internet.

So, when I looked back on my 12 years of being a sysadmin and a software dev, I realized that I could pretty much count on one hand the number of other software developers I knew in the Seattle area. So, if I didn't know very many people who could recommend me, and I suck at interviews, it is no wonder I had such a hard time finding a job in the tech market! Why did I know so few other developers? This was for many reasons, but the main one was that I was in academia in a fairly secure job the whole time, and wasn't really thinking enough about life after my current gig. My ways of improving myself had always been books, mailing lists, and classes, which doesn't get you out in the community much. Plus, I had been working as both a sysadmin and a developer, but quite frankly the sysadmin required much more constant learning and tended to hog my learning time, because it involved so many different technologies and programs. I decided during my period of unemployment I wanted to focus on software development, and clearly, if I was going to continue to be a coder and be able to deal with any future unemployment or career moves, I was going to have to change how and what I was learning drastically. And so, the introvert starts the slow task of reaching out.

I started going to various meetups, and other local meetings of coders and learning more about how to become a better developer, figuring it would be good to kill two birds with one stone. And, while it has never been clear to me why I would want to kill two birds with stones, it was abundantly clear why I needed to both network and become a better developer. Since I was a self-taught developer, who had spent all my time in academia, I knew there were some holes in my skills and knowledge. In the meantime, I was really loving my new work at the University, but I was a little worried, because I was once again working by myself in a science lab with a bunch of primarily science researchers who knew a little about coding. One day at an event I was talking to people about becoming a better programmer. They were emphasizing pair coding, code reviews, working in a team, etc. and so I asked how I could improve when I worked by myself. One of the developers I was talking to told me that he didn't think anyone could become a great programmer working by themselves. Not the answer I was looking for.

Next post: How I responded

So sue me, I've been busy ~ Comments: 0

Add Comment

The Elephant in the Room


MyRamblings, MyLife, Tech, JobHunting

by Maria on 21 Sep 2013 - 06:27  

Elephant, not in a room

For about 13 years, I have worked in a neuroscience lab as a programmer and a sysadmin. The last time I was interviewing for a job, I had to convince my potential employers that I was smart, dedicated, easy to work with, and would get the job done. Fortunately, I'm pretty good at that. I knew very little about how to program, but I convinced my future boss that I had a plan, the dedication, and the smarts, to teach myself how to program, so I was hired as a programmer.

And now I have 13 years experience as a programmer and a system administrator, so theoretically, it should be easier to get a job. Unfortunately, the interview has changed. It is no longer enough to tell the interviewer what I have done, what I can do, and how I work. The amount of information about me that is available to a potential employer is way more than it was 13 years ago. But, this time around, what potential employers really want to know, is can I solve a toy programming problem, while they watch me and evaluate me (or worse, evaluate me over the phone using a shared doc), under more or less a timed condition. These are the worst possible conditions for me to perform under, and this test has nothing to do with how I will perform as an employee. Seriously. It doesn't reflect how well I program or how much I know about programming or what kind of an employee I am.

I understand that everyone gets nervous about interviews. But, clearly, some people do not become as brain dead as I do. I have been working hard to overcome this. I practice as much as I can, but the situation is frustrating. I know that if I continue to practice, I will get better at it, and eventually I will be able to finish an interview without feeling like I can no longer even recite the alphabet. (I find practice interviews help only a little bit, since most of the pressure is missing.) Eventually, with enough time and practice, I'll get lucky, and the interview will consist of questions that don't put me in panic mode. But, why should I have to do this? Why have we settled on this as the process, when it has so little to do with what candidates need to succeed at work? Interestingly, the process favors people who job hop a lot, and therefore get more practice with real interviewing. That, and showoffs.

And why are interviews a particular problem for me?

It isn't the male environment. I've been living in a mostly male world since I started playing tackle football with the neighborhood boys at age 8.

When I was in the Army, I attended a school to learn large diesel truck mechanics. At one point in the school, one of the instructors had me take over the class, because he felt I knew the material better and was a better instructor. As an undergrad, I was fine with teaching the first year physics lab series, even enjoyed it. For years, I taught weight training. Clearly, the problem isn't speaking in front of people.

It is not the white board. As someone who has been in academia for a very long time, I am very intimate with the white board, and even its predecessor, the black board. It is a very useful tool for sharing ideas with others, and I am more than happy to write code on it, if I feel like we are collaborating and/or learning, and not like I am being judged and timed.

It is not the pressure, per se. Pressure I can deal with, and can thrive in. I ran a mail server for years, and there is nothing quite like the pressure of the mail server going down while your colleagues are at an important conference and very dependent on email. This sort of pressure can energize me.

It isn't even that I don't like these sorts of coding problems, I actually do, as long as I'm doing them in my living room in my pajamas for fun.

So, what is it then? I first noticed this problem of my brain shutting down when I was an undergrad in the physics department. I knew the material. I did well on the assignments. And then, I looked at the test and my brain stopped functioning. What was different about physics and auto mechanics? Well, physics is definitely more difficult (unless you're engineering the auto, or troubleshooting the electrical system, and not just replacing the cv boot). But, that certainly can't explain all of it, because I was doing fine on assignments, and even quite a few of the tests, even though I sometimes felt like I was working at half brain capacity. So, it wasn't simply the difficulty of the material.

Instead, I think it was the structure of the testing. In the physics department, the tests were usually designed so that most people wouldn't finish the tests, and so that no one would get a perfect score. They didn't always succeed in their design plan, going in both directions. I remember tests where the mean was 25 out of 100, and I remember tests where a couple of people managed to get perfect scores. But, usually the mean was right around 50%. This was much different from the auto mechanic courses, and quite frankly, different from most of my other college subjects. And it was demoralizing and scary. And it didn't help that instructors often said things like, 'It should be obvious that...', for things I didn't find obvious at all. Fortunately, none of them were patronizing. Oh, wait. And the more I became insecure about my abilities, the more difficult the tests became. I saw this happening, but could not find a way to stop it. I nearly switched majors because of it. I feel the same kind of pressure now in interviews, but there are different factors.

1. As many geeks are, I am an introvert. I have a hard time talking to strangers, especially small talk. I've mostly gotten over this, but when combined with the other three factors, I think it still plays a role.

2. I think before I speak. So, sometimes there are those long pauses that interviewers hate, because they want to know what is going on in your brain. I try to go back, and say this is what I thought of, and why I rejected it, but it is very difficult for me to speak while I am thinking. Weird, I know. Apparently, this is a thing. And, when I realize I have been silent for a while, I get nervous about that, and we start another cycle of brain freeze.

3. I sometimes experience Impostor Syndrome. I am hyper-aware of how much I do not know. I love learning, and am constantly learning and growing, but sometimes the awareness of how much I don't know makes me feel inadequate, hence, an impostor. And admitting that I sometimes experience Impostor Syndrome makes me feel inadequate. Totally kidding, the recursion is not infinite.

4. I do not have formal CS training.

All of this means is that I become particularly terrified during interviews, but NONE of these things has ever had any bearing on my actual work. Impostor Syndrome seems to particularly affect women, and so I have to wonder if it is the confluence of some of these factors: introversion, impostor syndrome and awful tech interviews that discourage geeky women in particular from staying in the tech industry. Of course, it is more complicated than this, but I do believe the interview structure sure can't be helping the numbers of women. If I, and I am stubborn, and I love making my life as difficult as all hell, sometimes wonder if I should bail because of interviews alone, then it must also be a factor for others.

So, what can be done? What is it that employers really need to know about an applicant before they hire them?

1. Will they get the job done? If they don't know something they need to solve the problem, do they know how to figure it out in a reasonable time? Do they know how to google (seriously, this is an art), and regularly use IRC and/or mailing lists? Are they organized, and do they approach problems reasonably systematically? Do they know how to troubleshoot? Are they tenacious? Do they know when to ask a mentor/colleague for help? Are they willing to try new things?

2. Are they reasonably easy to work with?

3. Do they fit in with company culture and the particular team?

Is there anything about the current popular tech interview format that answers these questions?

My best experience with an interview was one in which the interviewer described what the group was working on, and specifically what I would be working on. We discussed ways to move forward on the current project. We discussed existing problems, my ideas on what to do, and their ideas on what to do. We discussed which technologies I had worked with before, how deep my understanding of them was, which ones were new, and how I would get up to speed on the new ones. At the end, I think we both felt pretty comfortable about what we were getting. I understand that sometimes companies don't want to divulge this much information about what they are working on. But, they can certainly say something like, on day 1 when/if you start here, you will be using technologies, A, B, and C. Which of these are you comfortable with, and which do need to get up to speed on? How would you go about getting up to speed? Which combinations of technologies have you used before, and what were the challenges in how they worked together?

Ideas on other ways to understand applicants:

In that interview, we did not sit down and look at any code, but I could imagine sitting down and looking at a bug in some code and discussing how to solve the bug. Since most of a programmers time is spent debugging, refactoring, optimizing, and testing, and often you are dealing with an existing code base, it seems that talking about refactoring and troubleshooting are way better ways to learn how a person thinks, in a way that is relevant to how they will perform on the job. And I do mean talking, not testing their coding ability. In all of the interviews I have had so far, absolutely no one has asked about troubleshooting and refactoring code. Try some pair programming. Have a candidate look at some code and describe to you what they think the code is doing. If the company is sensitive about its code base, maybe they can fork some open source code that is close to a realistic problem they might face, and the interviewer and interviewee could discuss the merits of the code, maybe even hack on it a little, on an actual computer. Yes, if you feel a deep need for the candidate to write some code, at least have them work on a computer, preferably their own, without someone looking over their shoulder. How about some pair programming or or pair troubleshooting so it feels collaborative, and more like what actually working with this person will feel like? Who says you can only discover how someone thinks by talking to them while they are thinking? Why not wait until they are done, and then you can talk about why they made the choices they did, and what other things they thought of and rejected? I have had companies ask me to write sample code, and then bring me in for an interview, and never bring up the sample code at all. That makes no sense to me. Ask them why they made the choices they made, if they have thought of any ways to improve it, etc. Try to help the candidate feel more comfortable, because that is more realistic for how they will work. For coding, stick with computers. Whiteboards are really awesome for discussing concepts, illustrating (literally) what code is doing, and designing, and can be used for these things during interviews, but despite what I said above, they kind of suck for actually writing code.

Recently I was talking to a recruiter at a large company, and he mentioned how this company was going to start offering tech interview classes. Really?!?!?! This is ridiculous. If your interview process is not screening for what you need it to screen for, and if you know there are qualified people out there, that you want to hire, and you find yourself starting to offer them training on how to get through your interview process, then it seems that it is the process that is screwed up, and not all of the qualified applicants who can't seem to jump through your hoops. Think out of the box, employers!

The bottom line is this, if I am treated as if I am an expert, and you are inviting me in to see if I can help you to solve a problem, you are going to get a much better idea of how I work and how I am to work with, than if you give me a random problem to solve and ask me to solve it on the whiteboard while you watch me and your watch.


Other people complaining about tech interviews in interesting ways:

The Elephant in the Room ~ Comments: 2

Add Comment