Applying for a job in technology means proving your technical proficiency.

There are many ways you can be asked to do this,

and we'll go over some of the common methods, depending on the role.

First, let's go over how you can be interviewed for a designer role.

A design job has very visual outcomes,

so expect the questions and tests to be weighted similarly.

If you are applying for a design job, you will have to showcase your work.

The most common way you will be asked to do this is by presenting your portfolio.

Things that employers could be looking for are visual weight,

does it look good; information hierarchy, are the most important things

on the page immediately visible; information organization,

are related ideas near one another;

intuitiveness, is it clear what you're supposed to do next;

and clarity of copy.

Once you show your portfolio, you can be asked to explain your design process.

If you don't know what this means, pick your three best pieces of work

and ask these questions about them.

What problems were you given?

How did you approach solving each problem?

How did you iterate from idea to final product?

How many concepts did you work on, and how did you decide on a final concept?

The goal here is to show that you have a rational, thoughtful process

that balances the requirements of the client with the end goals of the user.

Aside from presenting visual examples of your work,

you can be asked a variety of questions about your approach to being a designer.

You will be asked questions that show your initiative to learn.

Design, like everything in the tech industry, is constantly changing.

And you will have to keep with the trends, best practices, and new technologies.

Are you willing to learn this?

And how proactive are you at identifying these trends and changes?

Testing these initiatives can come in the form of questions like

What do you read? What is an example of good user experience and why?

How do you stay up to date on trends in the industry?

Finally, you could be asked to run through a quick project at the interview.

You could possibly be given a UI component to redesign

or a description of a problem and be asked to walk through a solution.

Carry these exercises out at home, so that you are best prepared.

Developer interviews are a bit hard to generalize, because jobs can vary by

language and other areas of expertise.

Let's go over different types of interview structures you can expect to run into,

and then we'll talk about different questions.

In addition to the general interview questions, you will run into situations

where you have to demonstrate your ability to code.

There are a couple different ways you can be asked to do this.

Whiteboard tests are a practice that many people have heard of

but not a lot of people, at least developers I know, have been through.

There is a general antagonistic trend towards whiteboard testing.

A lot of people see it as highly unrealistic and an ineffective way to test a candidate.

Nevertheless, it does happen, so you should be prepared.

With whiteboard tests, employers are testing a few different things.

A whiteboard is a finite space, so writing out some code

quickly and then backtracking to add another variable or loop will get messy.

They're testing your ability to think through a problem and how to solve it

given the finite space that you have.

Secondly, they're checking that you know your language without having an IDE

all to complete your stuff for you.

If you forget a colon, comma, or semicolon, it's not the end of the world.

But they're looking to see if you can remember language-specific stuff.

Finally, they want to see how you work.

Do you ask questions and clarify any assumptions?

Do you read over your code and check things?

Is coding a collaborative process to you?

Do you ask questions and explain your reasoning to the employer?

Or do you like to be left alone?

If you Google whiteboard coding, you will see a lot of people arguing against it.

Regardless of where you stand on the issue,

if there's a chance you might have to do a whiteboard test,

it is best to practice beforehand.

The second type of interview you can run into is a pair programming interview,

where you code with someone from the company.

Like whiteboard tests, pair programming has its own set of criteria

to test in an interview.

It is good at exposing an interviewee's programming style.

Coding with someone allows you to see if they're open to criticism

or are thoughtful and have the ability to express their ideas clearly.

It can also show you if they're aggressive or competitive and hard to work with.

Second, you get a very early glimpse of their creative skills.

A key part of a developer's job is to read an insufficient set of requirements

and come up with creative solutions to fulfill needs.

Finally, you see through their thought process as they work through complex problems

and get an idea of how they complement your team.

Pair programming doesn't test at all job levels, so it's not ubiquitous.

But for mid to higher level positions, you can expect to run into this kind of test.

Then there's also written tests on paper.

You could be handed code samples to review and identify errors.

This kind of test is looking to evaluate the same set of criteria

as a whiteboard test.

As to the type of questions you could be asked, there's lots of different topics.

You could be asked simple factual questions about a specific programming language

or questions regarding data structures or algorithms.

It just all depends on the positions you are applying for.

A great way to figure out questions you might be asked at a specific interview

is to check out websites like glassdoor.com or LinkedIn.

Glassdoor is a great website to get all sorts of information about a job,

from reviews, salary information, and most importantly interview questions

that people have been asked when they interviewed with that certain company.

I've included a document in the downloads with a list of potential interview questions

by topic, ranging from easy to hard.

The list probably only covers a tiny part of all the different questions

out there, but, hopefully, it's enough to give you an idea of what to prepare for.

Now that's all I have to add to the topic.

But to round it off, let's look at what some of our teachers

have to say about being interviewed for jobs they've done in the past.

>>So it's interesting. There's such demand for mobile development right now.

The moment I updated my online profiles to say I was doing mobile development,

I started to get requests and job offers.

I wasn't even looking for a new job, and people started to contact me,

through LinkedIn and other ways, to say, hey, I see you've got these skills.

Let me tell you about my company.

And I went on a couple interviews just to see what things were like.

And it's kind of an intense process.

It's one of those things where, in my experience and I think this is relatively general,

people want to know what you can do.

They don't care as much about your degree or— >>Right.

>>or what certifications you have. They want to see your code.

And they want to see you code.

So we mentioned having things available online for people to look at.

But one of the experiences I had was, with some small companies,

they wanted to—one company gave me an assignment to do.

And I had to write some code, send it back to them so that they could review it,

and do it within a certain period of time,

so they knew I could turn things around and meet a deadline.

And then another—a friend of mine had an experience where

he went, interviewed for the company. They really liked him.

They invited him back to do some pair programming,

because they wanted to pick apart his brain, give him something to solve,

and watch how he worked through it, and they ended up—

there was an iPhone application they were working on,

and they found some weird bug, and he was working through stack overflow

and navigating the documentation, and he really just impressed them

with how he could solve the problem and how he wrote the code.

>>So pair programming is essentially you're there, and there's someone else watching you code.

>>Yeah, he was working with a developer at the company for a couple of hours,

on a small project, just to see how he worked with a team

and how he thought about the problem. >>That could sometimes be nerve-wracking, too.

>>Oh, sure. >>Someone watching over your shoulder and watching you code.

>>Yeah, I didn't have that experience, but I imagine it was very nerve-wracking.

It was nerve-wracking enough just to put together the code and send it

away from somebody to evaluate, but it was also a good experience

in that I could make it pretty much how I wanted it.

I was putting my best out there, and it was up to them.

As opposed to a more traditional interview, where you feel like

you've got to answer the questions the right way, and you can leave the wrong impression.

When you're just sending a product for them, like this is what I can do—

it was a better experience for me.

>>Yeah, I think, more and more, when it comes to actually coding in dev positions,

the employers are asking you to send over code,

or they ask you to solve a little puzzle, or they ask you to build a little feature

that they could use in their app.

So that they can review your code, they can see that you deliver on time,

and they can see the depth of your knowledge, too.

I mean, having the breadth is good, but a lot of employers do look for depth,

especially when it comes to mobile dev.

Do you know the language, do you know the ins and outs of the language?

I think one of the craziest questions I got, which was totally unrelated

to the development aspect, but it was more—can you think on your feet kind of thing—

was, given two phones with both the airplane mode on,

there's text on one phone, how would you transfer that text to the other phone?

So it was just like it stumped me completely.

I was like, well, there's no airplane mode, there's no Bluetooth,

you can't have an accessory attached to the phone, like—

how would you do it?

I couldn't answer it, of course. (laughter)

>>You know, we're given these detailed answers, and that's—

this is for a more advanced senior-level developer position.

I think a lot of companies, because it's a—there's a lot of demand,

a lot of companies do realize that people are coming in as entry-level,

needing to learn the technology, so that's a different experience, too,

where I think, in that case, you just need to show that you have

an appetite and an ability to learn.

And that the culture and the fit with the team is important, too.

They want to just make sure—whether you're working remotely or on site,

just that you can communicate clearly

and that you'll have the same, a similar work ethic

as the rest of the people you're working with.

>>Being interviewed for a development position varies from company to company.

Sometimes there's maybe small entrance exams, sort of thing, so

the most technically capable person in that company,

which may be very technical or may be not that at all,

may ask you how to start something in JSS

or may ask you generic computer sciencey type things.

And depending on your performance, I've often found

even with a semi-okay performance, don't be too hard on yourself

because you're often more technically competent than the other entrants.

So always go in there with a positive attitude, and

brush up on the particular skills that you know that they'll be looking for.

>>It's been a very different interview process for every single job that I've had.

For example, my professor hired me in college during my sophomore year,

so that was the longest eleven-week interview I've ever had.

So there was that one, but I've also interviewed for a more traditional

advertising agency, where I had to come in with my computer

and show them my favorite pieces and explain what problems I solved

and really thoroughly go into them.

And then another interview I had was just literally through Twitter.

It was very casual. He mentioned that there was a job opening.

I tweeted that at him, and he called me and set up a more official interview.

But they've all kind of been very different experiences for me.