Brighton Search Group

Questions You Should Expect In Your Interview

It never fails – no matter how much homework you do on the company and how much you prepare, you are inevitably hit with any number of interview questions you were not expecting. The more prepared you are heading into an interview scenario, the better you look to the prospective employer, which is a winning combination for everyone. Truly the best thing to expect is the unexpected, so along with your preparation, go into your interview with an open mind and avoid making snap judgments about your progress.

General Questions

1) Give an example of one of your biggest strengths and one of your biggest weaknesses. (This is an oldie but a goody, and it never fails to come in one form or another. The only way to tackle this is to think it out in advance so you aren’t stumbling during the interview itself)

2) Describe your most recent / favorite project. (You should know all of the details related to the project including: your role, team composition, where you fit in on the team, related technologies/languages, challenges you encountered, how you dealt with them, and finally the outcome of the project)

3) How do you envision this role?

4) What is your ideal role?

5) Where are you in your career currently? What do you see for your career path over the next few years?

6) What did you like most about your last role? What did you like least? (Please avoid badmouthing your previous employer at all costs)

7)    Tell me about a time your boss or a co-worker made you angry. How did you respond?

8)    Tell me about a time you failed to meet an objective. Where did the project go wrong? How did you recover if at all?

9)    Why should we hire you over other candidates?

10) Describe a time when you were faced with a challenge and explain how you solved the problem.

*Extra tips: Know your résumé backwards and forwards and study it before your interview, as many questions relate directly to skills and projects that you’ve listed.

The above post was from a site that is no longer live, so the link is broken.  It is Copyright to BINC

Questions You Should Ask In Your Interview

Often candidates forget that an interview is a two way street. Throughout the process, it is just as important for you to interview the company as it is for them to interview you. You should always have a list of 5-10 questions prepared FOR EACH INTERVIEW. This serves to show the company you’re interested as well as providing you with answers to vital questions you may not have known you needed answers to. By the end of the interview you should have your answers and know whether or not you’re prepared to take the next step in the process – whether it’s another interview or a final offer. The following are a list of questions that you should be prepared to ask in an interview:

About the Company

1) Tell me about your team/company and how you feel I could fit in.

2) What are some of the current challenges the team/company is facing? What are some challenges you anticipate you will be facing over the next year? (The second part of this question is excellent for testing to see if the team or company has a vision beyond the immediate future)

3) What is the 1-5 year goal of the company/team?

4) Describe the company culture and work environment.

5) How are you faring against your major competitors?

6) How are you distinguishing yourself in your marketplace?

About the Role

1) Why is this position open? (Is this position new, or will you be replacing someone? This is important in knowing what the company’s angle is)

2) What are your expectations for this role? (This is a good way to relay the expectations of the hiring manager/interviewer against the job description, which could have been written by someone else entirely)

3) What could I do to make an immediate impact? OR How can I hit the ground running? (This one is excellent for showing your enthusiasm)

4) If I joined your team today, what would you expect my growth to look like? What is the normal growth path for people in my role? (This question should be left for a face-to-face scenario as it is sometimes hard to get your intentions across over the phone – you don’t want to sound uninterested in the role you’re interviewing for)

5) Who would I report to in this role?

6) What is a day-in-the-life like?

About the People

1) Where did you work before you were here? Why did you leave? (This question seems direct, but it’s an excellent way to get at the perks of the company and get the interviewer talking about themselves. It’s a great way to build rapport)

2) Why do you still work here? What has kept you at the company?

3) Describe the dynamic of the team.

4) What are some common characteristics that successful people in this company share? (Interviewers are usually surprised by this question and think very hard to get the right ones across. It’s a great way to divert the attention away from yourself for a moment)

The above post was from a site that is no longer live, so the link is broken.  It is Copyright to BINC

 

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.