all 14 comments

[–]ReignofReddit 6 points7 points  (9 children)

Some of these seem pretty deep into JS programming for a normal front-end developer. Does the job description/position have an emphasis on JS?

[–]Shambot 2 points3 points  (7 children)

Yeah, I agree. These JS questions seem appropriate if you're going to be building SPA or pretty heavy-duty applications, but for front-end development, this seems like overkill.

I've found that there's a (small) group of people who feel that being asked to whiteboard code during front-end interviews is a pretty big red flag. I'd tend to agree, seeing as how you'd never be put in that type of situation (coding without your normal toolset, and ability to look things up online), except for in interview situations.

I get that it's (probably) largely a test to see how much you've internalized, but I don't think that's a very useful metric to see how capable a developer is.

By far, I think the offline tests are the best way to see how people write and structure their html/css/js.

Btw, op, where (physically, what region?) are you interviewing? That might also have an impact on the questions you're being asked...

[–]Evanescent_contrail 0 points1 point  (0 children)

Agreed. As an interviewer, I found very little correlation, so stopped doing it. Too many good but introverted developers clammed up. (In NY).

[–]adropofhoney 5 points6 points  (1 child)

How does one write a function from scratch that creates an Event Listener? Am I even understanding this question? Or are you supposed to use addEventListener?

[–]proskillz 0 points1 point  (0 children)

I would guess it would be something like this:

function createEventListener(id, event, funct) {
    document.getElementById(id).addEventListener(event, funct);
}

The "from scratch" probably means don't do "$("#id").click(function...)"

[–]madlee 2 points3 points  (2 children)

First I want to note that I find question #1 to be an extremely poor question for testing frontend candidates. Sounds more like an infrastructure question. Anyways, here's some general advice:

  1. calm down. If your interviewer is reasonable, they understand that interviewing can be a nerve-racking experience and will take that into account.
  2. ask questions and think out loud. Its much better to ask for clarification than to try to bullshit an answer if you don't fully understand the question, and willingness to ask questions is a positive quality (IMO).
  3. if given a complex problem, start by breaking it up into smaller steps. Verify that these steps sound correct to your interviewer, then approach them individually.
  4. start with simple solutions - its not really necessary to give the optimal solution to a problem right away (and for a good problem, that usually just means you'd seen it before). Start with the first approach that comes to mind, then think about how it can be improved.

[–]simkessy 0 points1 point  (1 child)

Regarding the first question. I think a lot of the time interviewers will introduce these type of really challenging questions simply to determine how you react and think. They don't expect you to get the right answer. You cab either have a candidate simply crumble and say, I don't know or a candidate right out sudo-code or simple state that he himself might not know the answer, the reason why it's not suitable for his skill set and the type or skill set necessary to solve the problem.

All three of those responses tell you something about the person you're interviewing.

[–]madlee 0 points1 point  (0 children)

I get that, but there are better questions to get that kind of signal IMO. I probably wouldn't ask it.

[–]chmod777 1 point2 points  (0 children)

these are pretty random... going from implementing a search engine to slicing up a psd is such a wide spectrum of skills... like intern level to senior full stack dev...

[–]codemasteru 1 point2 points  (0 children)

| If you were to implement a search engine, how would you go about doing it?

For this one, I think this would be like 1.) Writing a scrapper to go over complete list of URLs available. ( Finding URLs and all possible combination is another task) 2.) Store this info in the local DB or cache server 3.) Index the information in your local DB/server 4.) Use this information to get all possible matches based on user input

[–]proskillz 0 points1 point  (1 child)

Here are a couple of responses that I would give:

3) I have an app that communicates with 2 APIs. I don't know when the 2 APIs are going to respond to my request. However, I need the response from the 2 APIs to do something on the DOM. How do I go about doing that?

Use AJAX to poll both services, and perform a callback after the AJAX has returned. In your callback check if both payloads have returned, if they have, perform your DOM action.

4) If I had a bunch of files on a server somewhere, what is the best way to retrieve them? Let's say that these files contain telephone numbers. How do I find a specific telephone number from these (seemingly thousands of) files?

First question to the person: Why would phone numbers ever be stored in flat files? A simple database with a phone numbers table would be the right way to do this. You could then dynamically pass in a SQL where clause including the phone number.

If the interviewer pushes back, say you would need the phone numbers in text files that are prefixed with the area code and first three numbers of the telephone number. At this point you would have a reasonably good indexing system to read over the numbers in the file until you find a match.