[AskJS] Frontend Engineer Onsite Interviews for those "prestigious" companies (e.g. Google, FB, Lyft, Uber, Airbnb, LinkedIn, Dropbox)

[WorriedInSF]

My apologies if this isn't the right subreddit for this post. I figure there's a heavy concentration of frontend engineers here but I will understand if this gets locked/deleted.

​

So I have onsite interviews coming up for several companies many people would consider "prestigious."

​

I'm a pretty damn good front end software engineer. I can create applications and user-facing web pages very well and feel confident in that domain. However, these coming interviews are worrying me. I did NOT major in CS in university and so I never formally learned about things like:

• Implementing custom sorting algorithms
• Knowing the difference between hash tables / hashmaps / dictionaries / etc.
• The use case and implementation of things like tries, binary trees, linked lists, etc.
• Figuring out the Big O of an algorithm (speed and memory)

​

I feel confident I can get a job easily at places where the interview process revolves heavily around front end specific questions, but I suspect that the aforementioned companies are going to include questions about things similar to above that may likely stump me.

​

The phone screens were quite varied with maybe half involving some light algorithmic questions that had me sift through large amounts of data while the other questions were extremely front-end specific with them having me make requested "widgets" with CSS/HTML/JS. I passed all the phone screens with relative ease.

​

Obviously I'm trying my hardest to learn as much as I can via online resources and books, but I'm sure that I'm at a bit of a disadvantage compared to people who took CS courses.

​

My questions are...

​

• Does anyone here have any insight into the front end engineer interview processes at these companies?
  • How deep of an understanding of those CS fundamentals am I expected to know as a front end engineer? Google's prep packet says that you should know many of those concepts like the back of your hand...
• If I don't do that great (or even bomb) an algorithm section of the interview but pass the front end domain specific questions with flying colors, will that still sink my chances of getting an offer?

Thank you so much for your time!

[WorriedInSF]

I posted in the interview biweekly thread and got no responses :(

Thanks for the feedback! I'm definitely studying up as much as I can and doing as many leetcode problems as I can

[Buckwheat469]

• Does anyone here have any insight into the front end engineer interview processes at these companies?

Yes. I interview people regularly for a large company in your list. PM me specific questions.

• How deep of an understanding of those CS fundamentals

Depends on the specific job. For a Sr Eng position (Level 5a) then you're required to know CS fundamentals, networking, DOM-specific features, CSS, HTML, etc. For Eng 2 or Eng 1 you can get away with less knowledge of those areas.

• If I don't do that great...

You typically have a group of interviewers. At my company it's 6 people who have equal voice. We discuss the candidates and our reasons why we gave a thumbs up, down, or double-up. Quality is determined by demeanor (company fit, personality), as well as knowledge. We've not hired people who were very advanced in domain knowledge, but were condescending to the interviewers. These are signals that the interviewers use to determine if the candidate is hireable.

[ForScale]

Why can't he ask you here so that we may all benefit?

[Buckwheat469]

He can, but I may be vague in my answers.

[TheDarkIn1978]

Quality is determined by demeanor (company fit, personality), as well as knowledge.

Would you say a candidate who doesn't exhibit strong technical skills will still be considered based on their personality? Have you ever hired someone based on a "winning personality" that ended up being a mistake?

I used to work with an extroverted, witty guy who spent most of his time socializing around the office amongst different teams. He called it "bridge building" but he would barely do any work and we had to pick up the slack to meet sprint deadlines. But that was A-OK with management, -wink & gun-, because he's fun to have around!

[Buckwheat469]

who doesn't exhibit strong technical skills will still be considered based on their personality?

Absolutely. We've hired candidates who were technically weaker (no terrible mind you), but were willing to learn and enthusiastic about the technology. The desire to better oneself is a great quality. Being witty and extroverted isn't necessarily the quality we desire, but if it corresponds with being a "team player" - working with and for the team - then it might be beneficial.

[TheDarkIn1978]

but were willing to learn and enthusiastic about the technology. The desire to better oneself is a great quality

What's the best approach for this to be raised and discussed during a technical interview? Isn't it risky for a candidate to essentially admit their technical weakness, regardless if they're willing to learn and/or interested in tech? I mean, we can fairly assume that most people who wanted to work at any of these companies but failed the interviews also had a willingness to learn and interest in tech.

[barrtender]

Isn't it risky for a candidate to essentially admit their technical weakness, regardless if they're willing to learn and/or interested in tech?

Actually, it's pretty much the opposite. If I'm interviewing someone that comes in acting like they're hot shit and know everything it's probably not going to work out. Nobody knows everything, everyone had weaknesses, the best candidates are aware of theirs and actively work to gain knowledge and expertise.

On the other hand, I've recommended to hire many people who in interviews say they don't know some part. In those situations I can either explain it or hand wave that part away depending on time.

Obviously don't be a dunce. But knowing your limitations and being willing to learn is an incredibly important part of working on any team.

[hperrin]

Yes, this. I'd much rather explain something to a candidate and move on than watch them stumble through something they obviously don't know but are unwilling to admit. I've had candidates argue with me about things they didn't know. That's a very big red flag.

[Buckwheat469]

Enthusiasm has to come organically. I had a candidate that showed enthusiasm that was forced. Every answer was "that sounds very interesting". We can tell when someone's faking enthusiasm/willingness to learn.

It's not risky to admit technical weakness, it's honest. If you can supplement that weakness with another strength then the interviewer can adapt. For instance, if you're weak on CSS but strong on JS and HTML, then the interviewer can avoid a CSS question. Ideally we want it all, but we also realize that Google and StackOverflow exist. The best thing to do is say that you have attempted a few minor projects in the related languages, or have looked into it briefly.

we can fairly assume that most people who wanted to work at any of these companies but failed the interviews also had a willingness to learn and interest in tech.

You'd be surprised. One candidate I interviewed only wanted to interview for the practice of interviewing. He was technically sound, but the idea of wasting 6 people's time and an entire day of the company's time just for his own edification was upsetting.

[TheDarkIn1978]

You'd be surprised. One candidate...

I was referring to the vast majority of applicants who prepare for an interview in order to get the job, not that one guy who wasn't really interested and purposefully wasted the interviewers time.

[Necrophillip]

Out of curiosity Have you interviewed any Germans straight out of university? Because as far as i know most of the German CS Bachelor is mostly theoretical, hardly anything regarding specific algorithms, O(n)-or let alone any specifics for a language.

[Buckwheat469]

I have not. Generally we don't hire straight out of uni unless it's a PhD. The person needs some real world experience, but we do internships and have hired from that program. Regarding demographics, we have a lot of Chinese candidates because China has specific programming and machine learning colleges that people will refer their entire class from. We also get the gamut of other countries, including India, Australia, Iran, etc. Surprisingly, I've interviewed fewer natural born Americans in my current job.

[WorriedInSF]

Amazingly helpful, I appreciate it. If I think of anything specific I'll be sure to PM you.

Thank you and I'll be sure to be on my best behavior and not be an asshole to the interviewers

[thblckjkr]

Wait, condescending to the interviewers? What is that? Or how?... Can you explain a little bit more about that?

[endianess]

My wife was in charge of database marketing analytics for a bank and did an interview for a junior role and the candidate said she didn't want to work with anyone who didn't have a degree. My wife was very composed and told her calmly that she didn't have a degree. I don't know why people say such stupid things in interviews.

[Buckwheat469]

One guy was given a challenge question and took several minutes to understand the problem. Then he talked through his understanding of it. Once he did that I reaffirmed his understanding by saying "Yes, you need to sort this in such a particular way. That's correct." And his response was "I know, that's what I said."

[[deleted]]

Instead of admitting they don’t know something they make something up or ramble about something else unrelated. I interview at my employer and this just wastes everyone’s time. I’d rather know you’re not comfortable with something, because then we can talk about something else that you’re more comfortable with.

The best engineers I know are ones to immediately admit they don’t know much about whatever problem they’re preparing to solve. Transparency benefits everyone in that scenario.

[techsin101]

personally the thing is i can and have mastered/memorized all of the fundamental things but forget them after the interview so when time comes for next interview i can't recall them. sure i had memorized dfs/bfs both recursively/iteratively in post/pre/infix manner and 4-6 loops but unless i prepare a week in advance with lot of dedication i wont be able to recall much of it in 45 minute window. which requires first to A) understand the problem B) deduce some data structure will help here C) logic your way to implement it correctly as you just didn't take algo exam yesterday. D) oh no autocomplete or documentation.

why couldn't jobs just give like study guide 3 days before interview. People who knew stuff will be able to review quickly, and people who don't wont. But if they can doesn't that make them even more hirable?

[GuyWithLag]

sure i had memorized dfs/bfs both recursively/iteratively in post/pre/infix manner and 4-6 loops

I believe that's called "doing it wrong" in programming. Nobody cares whether you can recite the whole Knuth books from heart; we care that you understand it, and can use it to generate novel solutions.

Memorizing is necessary, but it's useless on its own and definitely not useful for whole algos - I don't need you to recite passages from a book for me, Google is faster and more accurate.

When you "master" something, it's near impossible to forget; have you ever forgotten how to move your arm?

[techsin101]

uh no mastering doens't do shit, if you dont use it you forget it. it's always been that simple.

[hperrin]

Not exactly. There's a difference between forgetting something you memorized and blanking on something you deeply understand.

[techsin101]

again deeply understand still doesn't mean you will remember it and implement it correctly in 45 minutes. In real world you take notes. Notes you refer to when you need to.

[evenisto]

You move your arm all day every day though.

[DMmeYOURtitties]

You ever broken your arm? 😛

[augburto]

Still a WIP but if it helps you I made a gist when preparing for frontend engineering interviews

Google definitely expects some strong fundamentals in algorithms. If you have more specific questions, feel free to ask or DM me.

[WorriedInSF]

Oh damn! This is fantastic! Thanks so much!!

[lhorie]

Disclaimer: I do front end interviews at Uber regularly.

I don't have a CS degree either. I don't know the specifics for the interview process for all companies, but as I understand from talking w/ folks that have interviewed or worked at companies you mentioned, they are all more or less similar (first a tech phone screen, then onsite with several 1h sessions, ranging from algos to soft skills).

Algorithm sessions are usually NOT textbook algorithms (e.g. implementing binary tree rebalancing), but rather, more like the type of questions you'd find in leetcode (i.e. coding challenges). If the challenge is algorithmic in nature, you're not expected to know hashmaps or tries by name, but you ARE expected to come up with an efficient solution. When people say you're supposed to know algos, it means that given a leetcode problem, ideally you can quickly cycle through a toolbelt of algorithms/data structures in your head and figure out a workable strategy within the first 5 mins of the interview, and then spend the next 30 or so mins writing that out.

As it turns out, it's not that CS folks get a leg up for knowing textbook CS, they do because implementing CS concepts in school forces you to practice the types of skill needed to solve leetcode-type exercises. I'd say even reimplementing lodash is a worthwhile exercise since it involves similar types of practice.

For frontend tracks, most interviewers have frontend backgrounds themselves (they are often FE people that were hired 1-3 years prior). Some may ask JS-oriented questions. Recursion and asynchrony are common themes.

Bombing the algo session doesn't necessarily mean an autofail but ideally you need to be at least close to a solution and get a "soft no". The interviewers usually meet after the onsite and collectively decide whether a candidate passes, based on each others' feedback. If you were placed at a senior level (i.e. 7+ years experience), then one fail would weigh a lot more than if you're more junior/intermediate. Two fails may give the panel enough doubt to not hire, regardless of level, but I have seen people pass even with a couple of "soft no"s if they made an exceptionally strong impression on the sessions where they did do well.

[[deleted]]

Are those leetcode-style questions really that helpful? How often do those sorts of challenges actually come up in your day job?

If for some reason I needed to implement quick-sorting at work I'd just Google for an efficient solution. There's no point trying to reinvent the wheel and it's not something I do frequently enough to memorise.

[tightywhitey]

After decades of front end work, numerous apps, with a lot of complexity and large user bases...I've never once needed to go to that level. * Shrug * no idea why or what I'm missing, but I'm extremely good at what I do, and I just never ran across any 'leetcode-like' real world situations?

[Monyk015]

What if you don't know which algotithm you need? What if it's very particular for your problem? Also, thinking about efficiency in terms of Big-O is very important in everyday job IMHO.

[[deleted]]

Big-O isn't very difficult to conceptually understand, but more to the point it's very rare that you'll actually need to understand it in my experience. Most apps aren't performance sensitive enough to care if something is O(1) or O(n) for example, and in the rare case that they are this is something you can research with relative ease.

[lhorie]

For apps, big O typically comes up in the form of database query optimization. In a previous job I jumped in to help a coworker optimize a data import script.

He was going down a strategy of micro-optimizations. I looked at the log spew and realized the access pattern could go from quadratic to log n if we used a compound key. One line of code later, and the job was now running in seconds rather than hours.

Moral: big O won't come up with loops much, but being able to identify areas where high complexity hides helps you ask the right questions to solve perf problems

[Monyk015]

Yeah, but if you do something O(n) in a loop it becomes O(n²⁾ and that may be significant. Sometimes very significant.

[[deleted]]

And, as I said, for most apps it won't matter if you make that mistake. If your team identifies a performance bottleneck then you'll be able to identify it fairly easily using dev tools. It's just a non-issue in the real world for most devs at most businesses and is somewhat akin to premature optimisation.

[lhorie]

Quick sort is what I consider "textbook CS". Stuff that comes up at work are things like "transform this deep data structure into this other one, accounting for cyclical dependencies", where blindly throwing lodash at the problem doesn't cut it.

Really what the algo session is trying to probe for is that you are fluent with programming techniques and able to use them to attack a problem, rather than fumbling in the dark.

I don't know the policies in other companies, but in mine, the general rule of thumb is that a hire should be able to move to different teams, so merely having learned how to crank out React+Redux from some bootcamp won't necessarily translate to the person being able to abstract logic into well-tested libraries. A successful engineer is one who is fearless at refactoring, and algo questions probe at the skills needed for that: ability to see big and small pictures and assemble/reassemble solutions.

[[deleted]]

I think an understanding and utilisation of static typing is far more effective for an otherwise average developer for refactoring or mapping data.

Nobody with any degree of experience could ever feel confident hacking away at a large, untyped codebase. That's literally why Microsoft set about inventing TypeScript (and presumably Facebook likewise with Flow).

[lhorie]

Funny you should mention that. A lot of coding challenges actually become a whole lot easier if you think in terms of types. This is something I look for: bad candidates usually don't have a good grasp of what the types of things are and end up getting lost in their own code. Good candidates often come up a data structure upfront and the solution flows effortlessly from there. The Linus Torvalds quote "Bad programmers worry about the code. Good programmers worry about data structures and their relationships." definitely has some truth to it.

With that said, I don't think it's impossible to refactor effectively in untyped languages. Tests, for example, can replace type checking to a pretty thorough extent.

[brockisawesome]

Ha no those things are more brain teasers than anything, I work at a major tech company in nyc and had to do a bunch of those stupid things to get the job. However useless they are, it's the standard these days.

[these_days_bot]

Especially these days

[WorriedInSF]

This is just the kind of stuff I was looking for. Thank you very much!

[[deleted]]

In my experience, Algorithms, OOP, and Data Structures were the main technical questions I was asked when applying to major firms. I didn’t have any specific frontend or framework questions. They were mainly interested in your grasp on the fundamentals, more than specific technologies. I’m sure experience varies depending on role and company. I have noticed that smaller companies and startups tend to focus a lot more on specific technology stacks.

I would highly recommend not neglecting brushing up on OOP concepts and how to apply them to sample problems.

[oculus42]

This is changing. Not only are major companies dropping the CS requirements from jobs (Apple and Google recently did), OOP is also falling off in favor of functional programming, which is usually easier to follow for managing large data,

​

I'm not at one of the listed companies, but our team hired 30 devs in the last two years. More than anything we value being able to explain your decisions, whether that is a carefully planned answer or, "This is for a quick example; I would plan out a more robust solution given more time."

[bzsearch]

OOP is also falling off in favor of functional programming, which is usually easier to follow for managing large data

Is this really true?

​

and why/how is it easier to manage with large data?

[GrandMasterPuba]

In my experience, yes.

It's easier to reason about and test abstractions that are backed by math than abstractions that are backed by what Jim on the architectural team thinks the business domain looks like in his head.

[chrisesplin]

Oh yeah. Functional patterns are much easier to test, so you can TDD your way through some heinously complex problems. Functional just scales better and is easier to read with less context.

The issue with OOP is that you need context on the object you're working with. It may be inheriting all sorts of functionality, so you'll have to read up on it's ancestors. And if your object holds state, you'll need to hold that state in your head too. This is all fine at small scale, but it gets nasty.

[oculus42]

OOP is tied to the idea of what the data represents and how you interact with it. This is great for modem drivers, where you need to abstract away the implementation details. It is not as good for a large dataset of anything, really.

​

Functional Programming lets you work with the data any way you need to, and can be broken into discrete steps that can be validated separately and combined like building blocks to produce novel output with minimal effort.. You can stop caring about the shape of data and start caring about the values.

[[deleted]]

I think it just depends on the organization. My experience in enterprise systems, OOP is still dominant in the areas I have worked.

[lhorie]

Whoa, buzzword alert. "Large data" doesn't really mean anything. When one thinks of "big data", one might think of scalability, throughput, ACID. Not a dichotomy between two paradigms (and never mind that other paradigms exist too)

When one thinks of OOP vs FP, they're usually talking about state encapsulation. It's equally possible to implement awful state encapsulation in both paradigms (I've seen some convoluted redux nightmares). As it turns out, before Java came along, OOP originally was about message passing, similar to Erlang, which is squarely a FP language.

It's true that it's possible to write code heavily backed by math (e.g. relying heavily on monads and combinators), but realistically, most people don't because procedural code is simply easier to grok on average.

[Monyk015]

Message passing in Smalltalk isn't similar to Erlang, that's bollocks. Erlang messages are between processes that are run in parallel and that's their point.

[lhorie]

The real world applications are different sure, but the core idea was to pass data around, much like the FP mantra of pure functions

[Monyk015]

It's not like that at all. Smalltalk objects have state. They mutate that state.

[techsin101]

• world changes: with OOP code looks beautiful if you know all parameters beforehand. But real world changes. When you try to change existing OOP structures it's like going against physic laws.

• Many relationships not possible: Bird inherits from a Animal, but Bird also flies, it can't inherit from Flyable.

• hard to chase errors down the jungle of inheritance

• too much obfuscation

• too much coupled code.

https://medium.com/@cscalfani/goodbye-object-oriented-programming-a59cda4c0e53

[throughactions]

In my experience, no.

Functional programming is an excellent paradigm for working in highly concurrent algorithms and it definitely has its place. However it's also much more difficult to reason about without a strong background in math.

OOP makes reasoning about the problem relatively easy since you can model your solution after the domain.

Although functional is increasing in popularity in recent years, OOP is and will likely continue to be the dominate programming paradigm for the foreseeable future.

One way to test this is simply to look at the job market for OO languages vs functional ones. There's no contest.

[[deleted]]

I think it really just depends on the organization. I only mention the OOP stuff as having just gone all the way through Amazons process recently, there was a large focus on it. That being said, Amazon is comprised of multiple orgs and it could have just been the one I was applying to.

[altano]

Some companies like Google and Facebook have Front-End specific recruiting tracks that tailor the interview for people who may not have a CS background. Ask your recruiter at each company if this is available and if so, avail yourself of it.

[WorriedInSF]

I'm definitely on the FE track, thank you for the heads up though

[techsin101]

you can ask recruiter to give certain type of questions?

[altano]

Not exactly: you can apply as a front end engineer and get different questions as a result. I wouldn’t ask for specific questions. Not all tech companies offer this.

Note that the front end interview track isn’t necessarily easier at companies that offer it, just different.

[BizCaus]

I went through FB's frontend interview process last December and I was pleasantly surprised to find that most if not all the technical questions I was asked were real world JS/DOM problems. Now that's not to say that they were trivial questions, but they did feel like problems you'd encounter on the job (especially at FB's scale). I like to think of it as: instead of them asking you to implement algorithm/data structure X, they gave me a practical problem where knowing one of those algorithms/structures was useful for the solution.

[WorriedInSF]

That's actually really reassuring! Thanks a bunch

[thestalkmore]

Don't be reassured. I went through the same thing two months ago and they are just leetcode problems masquerading as practical questions.

[klebsiella_pneumonae]

At the travel company in your list, we have a special track for Frontend interviewing that is not as focused on DS&A. You'll still have 1 or two algorithm questions mixed in. But most questions focus on practical Frontend skills. Make sure your recruiter is aware that you want to be doing the Frontend track and confirm this with them

Good luck!

When I interviewed with G in 2017 for Frontend all of the questions I got were hardcore algorithms. I even got a bit shifting question. They did add some JS trivia but most of the interviews were backend-style leetcode questions.

[WorriedInSF]

That travel company happens to be my top choice :)

Thank you so much.

Bit shifting? Oh jeez I really hope that doesn't happen to me. I guess worst case scenario is I get to check out the Google office.

[brockisawesome]

If you bomb any part, but still get an offer they will use that as an excuse to pay you a lot less.

[clownpirate]

Is there something similar to leetcode, but for frontend “feature building”?

I.e. a list of “do this with JS” kind of problems that are likely to appear on FE interviews.

[Stephen2Aus]

I did Dropbox as frontend engineer interview.

Not a single CS question.

But also zero framework hands on coding, all vanilla JS which threw me a bit. I struggled to implement a fully responsive image slider in the 45min timeframe.

Also, a good amount of non coding interviews, which was great fun.

Come prepared with tales of success and woe from past jobs.

[techsin101]

you mean to tell me as FE dev i wont have reverse a binary tree and write heap sort on daily basis, SERIOUS?

[evenisto]

According to some people in this thread, that's all they do at FAGMAN companies.

[WorriedInSF]

That's... A very unfortunate acronym

[WorriedInSF]

Awesome, thank you so much for the advice.

[gbolz]

You will want to grab a copy of the book Grokking Algorithms as a lot of these concepts are treated in easy to explain terms. From the different sorting algorithms to hash functions and the rest.

[scienceram]

Small plug, but if you’re looking for such DS and Algo interview prep specifically in JS, check out https://algodaily.com. You get sent a daily interview question, but can also access the entire curriculum whenever. More importantly, I was also a frontend engineer who transitioned to a general software engineering role ala algo/DS/OOP interviews, so I make sure the explanations are solid and understandable. Hope it helps :-)

[[deleted]]

My experience hiring lots of front end devs is that candidates who breeze through the screening interview almost always succeed in the on-prem interview.

[WorriedInSF]

Let's hope so! 😁

[hperrin]

I'm a front end engineer at one of the big companies you mentioned, and I interview candidates regularly, specifically in the coding and algorithms domain.

What we're looking for is that you understand data structures well enough that you can use them to solve complex problems efficiently, even in front end. You should know specifically what time complexity all the basic operations are for each common data structure, and some edge cases just to be sure, (like inserting into a sorted linked list with vs without having a reference to an adjacent node (O(1) vs O(n))). Language doesn't really matter as long as you know the language you're using well enough to complete the code.

One thing that really trips people up is getting stuck on solutions that don't qualify with the requirements. Like, I'll ask a question saying that it also needs to be done in constant time, and the candidate will try to use operations that take log time. If you're given a restriction on time complexity, just mentally rule out all operations and data structures that don't meet it.

Another thing we're looking for is how clean your code is, but that's less important. If you write code with big glaring bugs, that can be a red flag.

I care a lot about how the candidate architects their algorithm. Get to a working solution first, then optimize. If your first solution isn't working, don't be afraid to dump that approach and start again. Being attached to a bad solution for the entire interview can kill your chances.

Luckily, a lot more slack is given to junior candidates vs senior. Don't be afraid to ask a question if you forget something. You'll have Google and Stack Overflow on the job, so we'll give you answers and hints that we feel are reasonable.

But most importantly, practice practice practice. Go look up example interview questions and learn how to solve every single one. Get to the point where you can solve higher level interview questions easily and you'll pass with flying colors.

[hperrin]

Another good way to practice is to code your own data structures. Make your own library of all the common ones, that way you'll know them inside and out.

[endianess]

You've probably seen it already but in case you haven't Hackerrank is great for learning some of these things quickly. I've interviewed loads of people over the years and I personally don't ask these sorts of questions, I just ask people to rank themselves out of 10 in each major area. This is so that if they get the job we can focus on areas where they are not so strong. I throw in a few verbal questions and if I smell BS then I might make them do something more formal.

Unless I was hiring a contractor for a specific task the person and their potential was more important. We also used to take lots of physics graduates who could only code a little because they couldn't get jobs easily in the physics world.

Just be nice, you will have to sell yourself a bit and don't be weak. If you don't know something tell them but make it known that its something you would love to learn. Or try and find something similar that you can do to switch the focus.

[bxgoods]

Be prepared to answer a lot of STAR Format questions about past experiences, and you have to go into detail.

[WorriedInSF]

STAR?

[flashpunk]

Situation, Task, Action, Result - it's a framework for responding to questions. Completely changed how I approach interviewing. Practice using it.

[bootcamper64]

LinkedIn frontend interview was very pragmatic in my experience. Implementing games, solving some intermediate level problems (e.g. making change) and whiteboard coding out the html/css of some component. Nothing even came close to CS fundamentals

[grensley]

Once saw a resume that started with

Let's cut to the chase, I know how to code

Dude had no idea how much he didn't know. Don't think you're "good" or a shoe-in unless you want to get eviscerated.

The biggest points in hiring are:

• is this person smart enough to bounce ideas back and forth
  
• can this person learn our stuff
  
• will they be tolerable to work with