Brighton Search Group

How To Do Your Best in a Technical Interview, Part III: Questions I’d Like To Hear

http://tedyoung.blogsome.com/2009/12/01/how-to-do-your-best-in-a-technical-interview-part-iii-questions-id-like-to-hear/

The following post was written by Ted Young (Copyright by Ted Young http://www.tedmyoung.com) This is probably the most relevant interview help we have found anywhere...

There are three categories of questions I’d like to hear from a candidate:

1. About the company itself: products, finances, market, etc.


2. About the culture: work-life balance, level of formality, number of meetings, etc.


3. About the development process: roles, requirements, testing, state of the code base, etc.

The first one is important, because you’d like the company to be around for a while. Hopefully you’ve done some initial research about the company before you walk in the door.

The next two categories require some thought. Think for a minute: what would your ideal day be like at work? Would it be sitting at your desk at 7pm, debugging through some hairy code, trying to get a build out the door for the next day’s demo to users (or management)? Most people will probably not choose that scenario as an ideal day, though there are those who are quite attracted to that kind of pressure and love living on the edge in that way.

Not me.

After going through many years of being a consultant, founding or co-founding three companies (four if you count the one I co-founded with my father), working for a consulting company, and then working for some “real” companies (eBay, Google, etc.), I’ve gotten to the point where I know a lot about what I want in a company’s culture and development process. No company is perfect, but I’ve learned through lots of experience (i.e., mistakes) what environment works well for who I am.

That’s the key: not every environment (i.e., company) works for everyone (as great as Google can be, it simply wasn’t for me). For example, do you like lots of alone time to think and write your code? Or do you prefer throwing ideas (and code) back and forth with other developers. Do you like gnarly algorithmic problems or squeezing performance out of every SQL call? Or maybe you prefer working with users/customers/interaction designers to come up with interfaces for an application?

Or do you just want a job?

If that’s you, and you’re pretty good at what you do, there are lots of places where it’s easy to just have a job. But make sure that’s what you’re happy with, because if you just want a job, you can be sure that the people around you just want a job as well, but don’t be surprised if you find that you care more about things like quality and craftsmanship and good tests than they do. After all, it’s just a job.

Some other questions to think about asking when you’re diving into the development process:

• How would you like to get requirements, i.e., in what form? On paper? As a mockup or prototype? Lots of whiteboard discussions?


• Do you want things like Continuous Integration? How about bug tracking?


• Do you care how available the people who define the requirements (product managers, owners, customer proxies, etc.) are?


• How about testing: how much is done by an official QA group and how much is done by developers?


• How complex is the code base? What’s the test coverage?


• Would you rather deal with a single active development branch, branch per feature, etc.?


• How does the team decide what to work on? Is it assigned by a manager or do developers pick what to work on?

One last area to think about is how much will you learn by working at the company? And that’s not just limited to their training budget, but it’s about who are the other people you’d be working with? Are they learners and teachers (i.e., do they like sharing their knowledge)? Or maybe the company’s in an area you’d like to know more about, such as finance or consumer-oriented software. Perhaps the non-developers you’d be working with sound interesting.

I could go on and on, but hopefully you understand that it’s less about the questions and more about what gives you satisfaction and joy in what you do. Figure out what questions you need to ask so that you’re as happy as you can be, because (and here’s where I sound like my dad) life is too short to spend a significant part of your life in some company that is a bad fit for you.

How To Do Your Best in a Technical Interview, Part II: Questions

http://tedyoung.blogsome.com/2009/11/22/how-to-do-your-best-in-a-technical-interview-part-ii-questions/

The following post was written by Ted Young (Copyright by Ted Young http://www.tedmyoung.com) This is probably the most relevant interview help we have found anywhere...

After I wrote yesterday’s blog, I knew I’d forgotten something, but forgot what it was that I actually forgot (I believe that’s first-order forgetting). Now I remembered (actually I remembered during this morning’s run): questions. Not my questions (as the interviewer), but your questions (as the candidate). Maybe it’s inexperience, but since we have mainly been hiring senior (as in experienced and skilled, not older) people, I’m amazed that I don’t get asked in-depth questions about our development process, or even about the day-in-the-life of an employee at my company. After all, you should be interviewing the company just as much as they’re interviewing you. After all, you can’t just assume that it’s a great place to work, right? I’ve made that assumption in the past, and I’m too old to put up with certain practices, such as lengthy code reviews before checking code in (I’d prefer to pair program).

So, what are some good questions to ask? I’ll supply some of the questions I used to ask when interviewing (as a candidate) and those I would like to hear in a future blog entry, but I’d rather you give some thought to the kinds of questions you should come in with. Think about what you’d want your day to be like as an employee of the company, then ask questions relative to that ideal. Obviously you’ll never find an ideal workplace, but it’s up to you to find out on which axes the company is not ideal and whether you can live with that for the next 3-5 years.

The Best Question I’ve Never Heard

OK, I’ll give you one great question that I have yet to be asked (and this is after doing 12+ years of interviewing!): how many people have you referred to the company and how many of those have been hired? My answer would be 5. That will tell you a lot about how me, the interviewer, likes the company, more than a typical question I get, i.e., how long have you worked at Guidewire. There’s a world of difference between me working somewhere for a period of time and being willing to ask people I know and respect to work at the same place.

How to do your best in a technical interview

http://tedyoung.blogsome.com/2009/11/21/how-to-do-your-best-in-a-technical-interview/

The following post was written by Ted Young (Copyright by Ted Young http://www.tedmyoung.com) This is probably the most relevant interview help we have found anywhere...

We’ve been interviewing a lot lately at my company and I’d like to offer some tips on how to do your best. Note that I’m not going to tell you "how to succeed" or "how to get the job", because that will depend on your talent and skills. What I can tell you are the things that will allow you to make the most out of those talents and skills.

1. Communicate. In fact, over-communicate. If I’m interviewing you, tell me why you’re doing what you’re doing. Don’t make me guess. Don’t make me ask.

You may be the best darn programmer around, but if you’re thinking quietly and writing on the whiteboard in total silence, and then you make a mistake (and you will!), I won’t be able to help you. Just like in school where the motto "show your work" helps you get at least partial credit, if you just showed the answer it becomes either Pass or Fail—not where you want to be. So, if you tell me what you’re going to do and why and lead me through your thinking, then I’ll be much more willing to give you some hints or help and I’m definitely going to get a better sense of how you solve problems than if you keep your thoughts inside. As an "Introvert" (on the Myers-Briggs scale), I know that this can be hard, but if you can’t do it in an interview, then how do I know you can do it on the job?

1A. Verify assumptions.

This is the "be a good listener" part of communication. Repeat back what you think you’ve heard from me and make sure that agrees with what I said. For example, saying "so some other code will instantiate my object and I don’t have to worry about that, right?" is a good thing to do, because that may be completely wrong, but at least you found out before you started.

2. Admit when you don’t know something.

It’s much better for you to say "Y’know, I’m not really familiar with X" or "I don’t know Y" than to try and fake it or muddle through. If you admit you don’t know something, it’s unlikely I’ll hold it against you (unless you say "I don’t know Java" when the position clearly requires Java and you have Java on your resume). But if you push on through when it’s clear that you don’t really know it, I’ll be concerned that you’ll do the same thing on the job and not ask for help and therefore make serious mistakes.

3. Admit when you’ve gone in the wrong direction.

Similar to #2 above, but I’ve seen interviewees bomb when they keep pressing forward with a solution that’s not working or won’t work and they know it. If you’ve followed #1, I probably wouldn’t have let you go down that road so far.

4. Check your work.

I’m amazed (or dismayed) at the number of folks who write a bunch of code on a whiteboard and don’t read through it to see if they missed anything. Take a few minutes to read through your code and make sure there’s at least not anything obviously wrong. Pretend you’re the computer and execute your code.

5. Know how to write tests.

Seriously. In Java, main() methods with System.out.println()s are not tests (this isn’t 1996, y’know). One test for your code is not enough. 3 tests for 4 different classes is not enough. Naming a test "testValidation1" and "testValidation2" is going to make me wonder about how you name things (whiteboarding is a bit different, which I’ll talk about in a bit). In an interview I won’t push you to do TDD, but you have to know how you would test your code, since that’s as much part of the job as writing the code in the first place.

6. Know how to whiteboard.

Don’t write out every single little thing on a whiteboard. It’s perfectly fine to say "and then I just do more of the same here" or "normally I’d give this a name such as testWhenUserLoginFailsAnAuditLogEntryIsCreated, but I’ll just write testLoginFails". Time is of the essence in an interview and you don’t have time to write compilable code. As long as you’re following tip #1 and communicate well, you can take a lot of shortcuts on the whiteboard.

There are other things, but if you follow these tips, especially #1, the rest is up to your ability to actually program.

Candidate experience with BSG

“Mel is the most organized, efficient and competent recruiter I have ever worked with. She goes beyond the services a recruiter provides to job seekers. For example, she will share her experience with you to prepare you for interviews. This includes pointing out informative resources on the web, giving you interview tips and introducing the interviewers in advance. Mel turns around responses to questions very quickly. She seldom (if ever) drops the ball on tasks for which she has taken responsibility. Plus, she is an energetic, personable and intelligent person. I would recommend Mel to any job seeker as a recruiter, advocate and coach.” March 16, 2010

Badsah - Product Manager

Latest References...

“I hired Mel to do a skilled resource search for a highly specialized consulting role. She listened to the role needs (which were somewhat difficult to describe) and came up with some great resources. Compared with other recruiters I've worked with, the quality of her candidates is much higher. Furthermore, I get great response from her and she doesn't send me any "junk". It's like she can read my mind. My next search - I'm calling Mel first.” March 11, 2010

~ Eugene - Program Manager

 

I'm VP of Engineering at a company called XYZ. Rich gave me your name when I asked him for "any recruiters he's worked with that are kick ass".  I'm currently trying to hire a few people and would love to talk with you to see if you're interested or available to help. March 8, 2010