编程面试宝典：Adnan Aziz与Tsung-Hsien Lee合作精华 - CSDN文库

需积分: 9 34 浏览量更新于2024-07-18 收藏 52.27MB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

资源详情

资源推荐

Broadly

speaking,

the

problems

are

ordered

by

subtopic,

with

more

commonly

asked

problems

appearing

first.

Chapter

25

consists

of

a

collection

of

more

challenging

problems.

Domain-specific

knowledge

is

covered

in

Chapters

21,22,23,

and

24,

which

are

concerned

with

system

design,

programming

language

concepts,

object-oriented

pro

gramming,

and

commonly

used

tools.

Keep

in

mind

that

some

companies

do

not

ask

these

questions—you

should

investigate

the

topics

asked

by

companies

you

are

interviewing

at

before

investing

too

much

time

in

them.

These

problems

are

more

likely

to

be

asked

of

architects,

senior

developers

and

specialists.

The

notation,

specifically

the

symbols

we

use

for

describing

algorithms,

e.g.,

^^[«/^)/<2,3,5,7),A[z

:

;],

M,

(1011)2,

n!,

>

2},

etc.,

is

summarized

start

ing

on

Page

522.

It

should

be

familiar

to

anyone

with

a

technical

undergraduate

degree,

but

we

still

request

you

to

review

it

carefully

before

getting

into

the

book,

and

whenever

you

have

doubts

about

the

meaning

of

a

symbol.

Terms,

e.g.,

BPS

and

dequeue,

are

indexed

starting

on

Page

524.

The

EPI

editorial

style

Solutions

are

based

on

basic

concepts,

such

as

arrays,

hash

tables,

and

binary

search,

used

in

clever

ways.

Some

solutions

use

relatively

advanced

machinery,

e.g.,

Dijk-

stra's

shortest

path

algorithm.

You

will

encounter

such

problems

in

an

interview

only

if

you

have

a

graduate

degree

or

claim

specialized

knowledge.

Most

solutions

include

code

snippets.

Please

read

Section

1

on

Page

11

to

famil

iarize

yourself

with

the

Java

constructs

and

practices

used

in

this

book.

Source

code,

which

includes

randomized

and

directed

test

cases,

can

be

found

at

the

book

website.

Domain

specific

problems

are

conceptual

and

not

meant

to

be

coded;

a

few

algorithm

design

problems

are

also

in

this

spirit.

One

of

our

key

design

goals

for

EPI

was

to

make

learning

easier

by

establishing

a

uniform

way

in

which

to

describe

problems

and

solutions.

We

refer

to

our

exposition

style

as

the

EPI

Editorial

Style.

Problems

are

specified

as

follows:

(1.)

We

establish

context,

e.g.,

a

real-world

scenario,

an

example,

etc.

(2.)

We

state

the

problem

to

be

solved.

Unlike

a

textbook,

but

as

is

true

for

an

interview,

we

do

not

give

formal

specifications,

e.g.,

we

do

not

specify

the

detailed

input

format

or

say

what

to

do

on

illegal

inputs.

As

a

general

rule,

avoid

writing

code

that

parses

input.

See

Page

15

for

an

elaboration.

(3.)

We

give

a

short

hint—^you

should

read

this

only

if

you

get

stuck.

(The

hint

is

similar

to

what

an

interviewer

will

give

you

if

you

do

not

make

progress.)

Solutions

are

developed

as

follows:

(1.)

We

begin

a

simple

brute-force

solution.

(2.)

We

then

analyze

the

brute-force

approach

and

try

to

get

intuition

for

why

it

is

inefficient

and

where

we

can

improve

upon

it,

possibly

by

looking

at

concrete

examples,

related

algorithms,

etc.

(3.)

Based

on

these

insights,

we

develop

a

more

efficient

algorithm,

and

describe

it

in

prose.

(4.)

We

apply

the

program

to

a

concrete

input.

(5.)

We

give

code

for

the

key

steps.

(6.)

We

analyze

time

and

space

complexity.

(7.)

We

outline

variants—problems

whose

formulation

or

solution

is

similar

to

the

solved

problem.

Use

variants

for

practice,

and

to

test

your

understanding

of

the

solution.

Note

that

exceptions

exists

to

this

style—for

example

a

brute-force

solution

may

not

be

meaningful,

e.g.,

if

it

entails

enumerating

all

double-precision

floating

point

numbers

in

some

range.

For

the

chapters

at

the

end

of

the

book,

which

correspond

to

more

advanced

topics,

such

as

Dynamic

Programming,

and

Graph

Algorithms,

we

use

more

parsimonious

presentations,

e.g.,

we

forgo

examples

of

applying

the

derived

algorithm

to

a

concrete

example.

Level

and

prerequisites

We

expect

readers

to

be

familiar

with

data

structures

and

algorithms

taught

at

the

undergraduate

level.

The

chapters

on

concurrency

and

system

design

require

knowl

edge

of

locks,

distributed

systems,

operating

systems

(OS),

and

insight

into

commonly

used

applications.

Some

of

the

material

in

the

later

chapters,

specifically

dynamic

programming,

graphs,

and

greedy

algorithms,

is

more

advanced

and

geared

towards

candidates

with

graduate

degrees

or

specialized

knowledge.

The

review

at

the

start

of

each

chapter

is

not

meant

to

be

comprehensive

and

if

you

are

not

familiar

with

the

material,

you

should

first

study

it

in

an

algorithms

textbook.

There

are

dozens

of

such

texts

and

our

preference

is

to

master

one

or

two

good

books

rather

than

superficially

sample

many.

Algorithms

by

Dasgupta,

et

al

is

succinct

and

beautifully

written;

Introduction

to

Algorithms

by

Gormen,

et

al.

is

an

amazing

reference.

Reader

engagement

Many

of

the

best

ideas

in

EPI

came

from

readers

like

you.

The

study

guide,

ninja

notation,

and

hints,

are

a

few

examples

of

many

improvements

that

were

brought

about

by

our

readers.

The

companion

website,

elementsofprogramminginterviews.com,

includes

a

Stack

Overflow-style

discussion

forum,

and

links

to

our

social

media

presence.

It

also

has

links

blog

postings,

code,

and

bug

reports.

You

can

always

communicate

with

us

directly—our

contact

information

is

on

the

website.

Chapter

Getting

Ready

Before

everything

else,

getting

ready

is

the

secret

of

success.

—

H.

Ford

The

most

important

part

of

interview

preparation

is

knowing

the

material

and

prac

ticing

problem

solving.

However,

the

nontechnical

aspects

of

interviewing

are

also

very

important,

and

often

overlooked.

Chapters

1-3

are

concerned

with

the

non

technical

aspects

of

interviewing,

ranging

from

resume

preparation

to

how

hiring

decisions

are

made.

These

aspects

of

interviewing

are

summarized

in

Table

1.1

on

the

following

page

Study

guide

Ideally,

you

would

prepare

for

an

interview

by

solving

all

the

problems

in

EPI.

This

is

doable

over

12

months

if

you

solve

a

problem

a

day,

where

solving

entails

writing

a

program

and

getting

it

to

work

on

some

test

cases.

Since

different

candidates

have

different

time

constraints,

we

have

outlined

several

study

scenarios,

and

recommended

a

subset

of

problems

for

each

scenario.

This

information

is

summarized

in

Table

1.2

on

Page

9.

The

preparation

scenarios

we

consider

are

Hackathon

(a

weekend

entirely

devoted

to

preparation),

finals

cram

(one

week,

3-4

hours

per

day),

term

project

(four

weeks,

1.5-2.5

hours

per

day),

and

algorithms

class

(3-4

months,

1

hour

per

day).

The

problems

in

EPI

are

meant

to

be

representative

of

the

problems

you

will

encounter

in

an

interview.

If

you

need

a

data

structure

and

algorithms

refresher,

take

a

look

at

the

EPI

website,

which

includes

a

collection

of

review

problems

that

will

get

you

ready

for

EPI

more

quickly

that

a

textbook

would.

A

large

majority

of

the

interview

questions

at

Google,

Amazon,

Microsoft,

and

similar

companies

are

drawn

from

the

topics

in

Chapters

5-15.

Exercise

common

sense

when

using

Table

1.2,

e.g.,

if

you

are

interviewing

for

a

position

with

a

financial

firm,

do

more

problems

related

to

probability.

Although

an

interviewer

may

occasionally

ask

a

question

directly

from

EPI,

you

should

not

base

your

preparation

on

memorizing

solutions.

Rote

learning

will

likely

lead

to

your

giving

a

perfect

solution

to

the

wrong

problem.

Chapter

25

contains

a

diverse

collection

of

challenging

questions.

Use

them

to

hone

your

problem

solving

skills,

but

go

to

them

only

after

you

have

made

major

inroads

into

the

earlier

chapters.

If

you

have

a

graduate

degree,

or

claim

specialized

knowledge,

you

should

definitely

solve

some

problems

from

Chapter

25.

Table

1.1:

A

summary

of

nontechnical

aspects

of

interviewing

The

Interview

Lifecycle,

on

the

current

At

the

Interview,

on

Page

13

page

•

Don't

solve

the

wrong

problem

•

Identify

companies,

contacts

•

Get

specs

&

requirements

•

R6sum4

preparation

•

Construct

sample

input/output

o

Basic

principles

•

Work

on

concrete

examples

first

o

Website

with

links

to

projects

•

Spell

out

the

brute-force

solution

o

Linkedin

profile

&

recommendations

•

Think

out

loud

•

R^siun^

submission

•

Apply

patterns

•

Mock

interview

practice

•

Assume

valid

inputs

•

Phone/campus

screening

•

Test

for

corner-cases

•

On-site

interview

•

Use

proper

syntax

•

Negotiating

an

offer

•

Manage

the

whiteboard

•

Be

aware

of

memory

management

•

Get

function

signatures

right

General

Advice,

on

Page

17

Conducting

an

Interview,

on

Page

20

•

Know

the

company

&

interviewers

•

Don't

be

indecisive

•

Communicate

clearly

•

Create

a

brand

ambassador

•

Be

passionate

•

Coordinate

with

other

interviewers

•

Be

honest

0

know

what

to

test

on

•

Stay

positive

0

look

for

patterns

of

mistakes

•

Don't

apologize

•

Characteristics

of

a

good

problem:

•

Leave

perks

and

money

out

o

no

single

point

of

failure

•

Be

well-groomed

o

has

multiple

solutions

•

Mind

your

body

language

o

covers

multiple

areas

•

Be

ready

for

a

stress

interview

o

is

calibrated

on

colleagues

•

Learn

from

bad

outcomes

o

does

not

require

unnecessary

domain

•

Negotiate

the

best

offer

knowledge

•

Control

the

conversation

o

draw

out

quiet

candidates

o

manage

verbose/overconfident

candi

dates

•

Use

a

process

for

recording

&

scoring

•

Determine

what

training

is

needed

•

Apply

the

litmus

test

The

interview

lifecycle

Generally

speaking,

interviewing

takes

place

in

the

following

steps:

(1.)

Identify

companies

that

you

are

interested

in,

and,

ideally,

find

people

you

know

at

these

companies.

(2.)

Prepare

your

resume

using

the

guidelines

on

the

facing

page,

and

submit

it

via

a

personal

contact

(preferred),

or

through

an

online

submission

process

or

a

campus

career

fair.

(3.)

Perform

an

initial

phone

screening,

which

often

consists

of

a

question-answer

session

over

the

phone

or

video

chat

with

an

engineer.

You

may

be

asked

to

submit

code

via

a

shared

document

or

an

online

coding

site

such

as

ideone.com,

collabedit.com,

or

coderpad.io.

Don't

take

the

screening

casually—it

can

be

ex

tremely

challenging.

(4.)

Go

for

an

on-site

interview—this

consists

of

a

series

of

one-on-one

interviews

with

engineers

and

managers,

and

a

conversation

with

your

Human

Resources

剩余543页未读，继续阅读

rogerouyang

粉丝: 0
资源: 1

最新资源

资源上传下载、课程学习等过程中有任何疑问或建议，欢迎提出宝贵意见哦~我们会及时处理！点击此处反馈