programming since the third grade. • Dropped out of the University of Wisconsin • CTO of a hedge fund at 20 • Started DesignerPages.com at 24 • Started Flatiron School at 28
something that you are weak on but that you are currently working on. • Mention something that has nothing to do with the job, hey, maybe you’re a weak dancer but are taking dance classes? • Don’t do the “my biggest weakness is I work to hard” • Don’t answer honestly. You absolutely have no weaknesses and shouldn’t ever use that word in an interview.
manholes round?) • Don’t get flustered, just start talking it through. • Break it down. It’s always 1 big problem wrapped in lots of small problems. • It isn’t about right answers, it’s about thought process. • Ask questions, work with the person. • Tell them about your favorite brain teaser.
manholes round?) • Don’t get flustered, just start talking it through. • Break it down. It’s always 1 big problem wrapped in lots of small problems. • It isn’t about right answers, it’s about thought process. • Ask questions, work with the person. • Tell them about your favorite brain teaser.
Teasers apply here. • Syntax isn’t as important as logic. Use pseudocode, it’s your friend. • UML a lot. Just use boxes and shapes to represent systems, data, applications, methods, whatever. Show your work.
Binary Search Nodes, Sorts • If you just don’t know it, ask questions, like “What’s that used for? Is that like a Benchmark? Where can I read more about it?” • But try to reason it out (and do research - even if you’ve heard about it and have a vague notion of how to answer it, that’s better) • Go home, research it, master it, write a blog post, email interviewer.
there are classic problems (FizzBuzz, JSON parser), research! Or have written a blog post in advance so if you get asked, you can even mention that. • Test drive it. Or if you didn’t at interview, do that at home and email. • Be flexible! It isn’t about ‘right answers,’ it’s about what it’s going to be like coding with you.
twitter, no gmail, no phone. • Talk, ask them who should drive first? What editor do they like using? Whatever, get to know your pair a bit first. • Be methodical and slow. Switch git branches. Confirm a method signature. Don’t rush. Work with them. • Ask how you did and recognize what you need to improve.
awesome stuff and brand yourself an expert by blogging and speaking and teaching. You’ll get offers. • Get ready to go on 30 interviews. For fun, for practice, even if you already have a job. You get to meet awesome people and hear what they are working on and what their needs are. Get offers, turn them down. • Be fun. Don’t get frustrated in an interview. Don’t get mad. Don’t say anything stupid. Follow up. Do more work. They want to hire you, so don’t be nervous. • Research and prepare. For the company and the code.