You have a week to study for a big tech interview as best you can

>you have a week to study for a big tech interview as best you can

What do you do? What problems do you emphasize?

yes

>tech

What kind of tech OP you fucking retard?

Development?
Infosec?
Systems Engineering?
IT?
Desktop support?

What?! Ya tit!

Software Engineer/Dev 1 (Novice)

>Be medical student with five, 3 hour exams in the next 9 days
>mfw I read about baby problems

>do your own homework dumbass-kun

Can someone show me the funny in this?

CTCI

2-3 questions from Cracking the Code Interview from each chapter.
Crush through leetcode questions in acceptance % ascending, starting at medium then to hard questions.
Write out my answers for the generic behavioral stuff.

Done.

Can you program? If yes, you will probably be hired. You may not be hired if your asking salary is too high, or if there are more qualified candidates than you and a limited number of positions. Spend this week learning what type of programming questions are going to be asked of you, and what languages [that company] uses more often.

If you cannot program, spend this week studying how to program. A week is a decent amount of time, if you have the right mentality.

>Studying for an interview
I already know all my shit

Uh if you can't program and somehow you've landed a tech interview at a big tech company, then you're not going to get the job regardless of how much you study in a week.

They might be picking up fresh grads for cheap.

Fuck off third world tripfaggot. You have no idea how the job market works in a civilized country. Are you still trying to hire a web developer for pennies a day?

Someone has never interviewed at big tech.

Definitely from shit country.

This is good advice

Language ?

Java.

Falcon, I normally like you, but unless you're a serious auto-didactic or a literal autist, you're not going to learn how to code on a production level in a week, especially from scratch.

what are the odds you would even study the thing they ask? I would just play Nintendo

faggot

I worry about this but their is so much shit to know in the interview game.

Knowing quicksort/mergesort, balancing BSTs, linkedlist tricks, plenty more.

>Knowing quicksort/mergesort, balancing BSTs, linkedlist tricks, plenty more.
Do they actually ask for this standard library included garbage? I'd expect them to ask relevant stuff, not "ey do you remember that class from college?"

Yes? I'm pretty sure they do.
It's a fucking game, rarely does the interview reflect on what the programming relevant to the team will consist of.

Not always, but definitely not rare either.

The interview game is such a meme.

>let me test you on something useless you learned in class 2nd year

Fuck that shit. Just look at the projects I've done and hire me faggot.

I've never been asked a sorting algorithm question on an interview before. Mind you I've only been to like 3-4.

I've been on the other end of the table for interviews for a very big tech company.

You won't get asked to specifically implement any algorithm or datastructure. We're not going to ask you to make randomized quicksort, or kruskal's algorithm, or fucking skip lists.

What you will get asked is thinly veiled generic data structure/algorithm question. At least a couple or a few of these.

The idea is that if you have the knowledge of all that shit listed (and plenty more) then you have more tools in your tool box to answer. Most of the algorithm/DS questions you will be asked have many ways of solving them. Some clearly better than others, and some solutions have trade offs which one might want over the other in specific situations.

Those specific kind of programming questions are generally one part of the long tech interview process.

Ideally, you will get other people on your interview loop to ask you about design, architecture, general behavioral stuff, etc.

Lastly, always remember that the goal isn't to necessarily get the right answer. We want to know how you think and how you approach problems. Also really good interviewers will always be able to raise the stakes and expand the breadth or depth of any programming question. Not only do we want to see how you think and approach problems, we want to see how you deal with ambiguity, stress, and what you do when you genuinely have no idea what to do next. Do you give up? Do you panic? etc.

> Just look at the projects I've done and hire me faggot.
This is great but Pajeet's have ruined the industry so much by lying on resume and portfolios that big tech now has to test this kind of bullshit to filter them out.

Acid wash tests take care of them pretty quick.

Any tips my good user?

Anything at all, i'm sure you've observed many common slip-ups.
Things like making sure to clarify at the beginning what they mean, or always talking out loud. Etc.

Yeah I assume that would be more the style.

>had my first interview with a software company
>4 interviewers
>every question was technical
>mfw

Never been more nervous in my life

What questions did they ask, if you can remember?

I went through palantir and I had 1 screen, 4 onsite, then 1 after.

How to poo in the loo.

>Are you still trying to hire a web developer for pennies a day?
I am offering a middle-class salary, and it is more than the typical rate that other people are offering here. No, I cannot offer a first-world salary, because I cannot afford to pay that much, and I am not living in the first world.

OP did mention it was a novice position. That said, you are probably right.

I am interviewing a guy in the next 15 minutes. Want to see the programming questions I am going to ask?

Can you interview me for practice? Would be kind of you.

If you can't, just list the questions.

You can't learn the answer to every programming problem in a week.
From my experience interviewing people, here's the advice I'd give:
*Ask clarifying questions.
*Learn how to write code on a whiteboard (if that's the interview style)
*Get a working understandable solution first, then discuss performance if there is time. *Never work yourself into a corner where you don't know what your own code is doing.
*Speak aloud what's going though your mind (important, the interview should never be silent for more than 20 or so seconds)

When I was interviewed for a small company for an entry level job, I was asked to do:
fizzbuzz
fibonacci
linked list
A word problem

When I interviewed at a big company for a 6 figure job, I was asked to do:
Finding a missing number in a list of numbers in a range.
string to floating point num.
Odd 2 dimensional binary search tree.
Convert a depth first tree's nodes in a breath first order.
In a directed cyclic graph (not a DAG) with a single sink, find the sink.

Good luck

watch anime

I would love to interview you, but you may need to wait something like an hour or so, as I am literally waiting for someone to come in for an interview in the next few minutes.

Send me your resume. I can call you via Google hangouts, if you that is convenient. My email is public.

Sent to what I think your email is.
Can you reply and confirm?

Did not get anything yet. I am going to afk for the interview, will check my email once it is over.

If you're getting interviews, then I wouldn't worry too much about personal projects.

If you're failing interviews, then you have to be aware of what you might be doing wrong.

If you're in school, I would get a friend to interview you and then have them provide feedback. Preferably someone who has had an internship at a big tech company or a reputable start up.

When it comes to the programming questions, generally people fail with the following

1. Not explaining their approach beforehand
2. Not explaining while they are coding
3. Very sloppy coding
4. Brazen fixes instead of being thought out
5. Not properly testing
6. Not clarifying requirements
7. Straight up just giving up.

CTCI covers most of that. In the end, a lot of it is just practice. It sucks but just put the time into it. No one on this earth is going to give you pity for not wanting to play the game, when the prize is a cushy 6 figure job.

For behavioral questions, prepare before hand and practice! Write out every story you have for all the diferent likely questions.

I've noticed in interviews candidates tend to think of one story and then use that to answer every question. It might work from the candidate's perspective, but its better when the answers to these questions all stem from different places. Usually I attribute this to a candidate just being nervous.

Practice user. Practice. Practice alone in front of a whiteboard, with pets, with peers, etc. You have to be confident, but not a cunt.

Sent. Pls help. If you didn't get just give me a hint to where it is.

OP didn't mention it was for a novice position. You don't even have the proper reading comprehension to understand the basic scenario that OP posited.

No big tech company (Msoft, Google, FB, Amazon, etc) is going to hire new grads for cheap. Do you have any fucking clue how expensive hiring the WRONG person is?

Fuckers have to get trained, and other developers have to spend time helping them with all their shit for at least 3-4 months before they can be somewhat useful. Having some idiot produce shit code is expensive.

And yes, those companies are desperate for hires. The key is that they are desperate for GOOD engineers, not bottom of the barrel shit. New grads at those companies make over 6 figures. No one is going to hire some fucking idiot who has just learned to code in the past week.

If you're browsing this thread I would advise you not follow any advice this fucking idiot has.

I have a really impressive project that I hope to carry as my crutch. It has so far worked.

I can talk about a lot of interesting shit, but i'm definitely mediocre in problem solving.
I think i'll just have to get lucky. Still going over every problem in CTCI.

I'll do anything it takes. I'm just behind because I didn't really want to interview yet but was lured, and couldn't delay it.

>Learn how to write code on a whiteboard (if that's the interview style)
>Tfw your writing is illegible, your sentences slant down, your character size varies, and you can't properly close a circle ever
Suffering

Seriously it doesn't need to be pretty, just readable. Write bigger, Slant upwards to counteract, practice writing letters. I had a shitty handwriting, and that last one made me feel like a fool who needed to go back to first grade. However, after filling sheets of paper with the same letter written over and over again, my handwriting turn from shitty chicken scratch to typewriter perfect.

>I am offering a salary
Hire me?

Brush up on general programming and algorithms. I'm pretty good at talking about my own projects and other bullshit so I don't worry about that.

In general I don't cram for interviews because I can't memorize a whole bunch of new algorithms in a week and it just stresses me out. I focus on revising what I already know and if they throw something at me I don't know, I do my best and admit I'm not familiar with the problem.

He's offering literally pennies a day. Anyone in a third world shithole could make more doing shit on Mechanical Turk.

If you are a Malaysian, or with a Malaysian PR, I can interview you.

>Anyone in the third world could make more on Mechanical Turk.
I am giving above average salaries. Not HUGELY above average, but above average. They would have to go for a much larger company with a much larger budget, or go to another country altogether, if they wanted to get paid more.

But still a third world salary. I cannot do anything about that part.

Sounds decent, user. Dont let these western neckbeards get you down.

>3 hours later
>no interview questions
fuck off falcon,this isn't a government secret

I am interviewing the OP live right now.

Probably read a book like Cracking the Code Interview

I study how to poo in loo

So I took falcon's interview, am OP.

The questions were not difficult, but definitely a good few levels above fizzbuzz aside from first 1,2.
Difficulty is a 4/10 I would say compared to other mock interviews i've had and seen.

Syntax is what really fucked me, am pretty new to Java so I had some minor slip-ups here and there. Especially because i'm tired as fuck.

Feedback is great, but admittedly the behavioral questions were quite non-American as far as the answers he expected. Not his fault of course.

Also like how he furthers the constraints to see thinking on the fly. Good stuff.
Overall great mock interview, props to him.

I'll just check how to reverse a binary tree and go to sleep.

Interview over. I asked OP most of the code questions in pic. These are trivial for a senior programmer, so do not get upset: OP is looking for a novice position, and I have been interviewing junior developers. If you are looking for questions that are asked in senior interviews, then other people may help.

The theory questions are stuff that I got from previous threads in Sup Forums, and online. I have never asked them in an interview... yet.

Enjoy.

coding on whiteboard is worst fear. what if you forget to add lines before and stuff? I guess strategy is to use a lot of space in between lines just in case.

Theory 4:
I don't suppose pulling a time signal off of a gps satellite is allowed so the time can just be sent over the packet more than 3 seconds before it's time. How syncrhonised is synchronised? GPS can get you within a nS or so. WIth a long enough time to get a feel for the link, ntp can get you within a few ms with pretty good certainty.
5: lol. How to weed out Richard Stallman: the interview question.
I don't understand testing a programming language in an environment without a compiler. That's what pseudo code is for. I had a CS professor who made us write c++ on a test. I always got at least 10% of the value of the question taken off for some stupid syntax error. I turned in my 500 line homework assignment and it worked 100%, why do you need to test my ability to make machine readable code? Compiling a single file is not an expensive process. Not doing it is like buying word processing software and not using the spell check.

Installing gentoo and reading sicp.

I'm not a programmer by any stretch of the imagination, but a few of these seem obvious while the rest I'm probably just too dumb to grasp.
code 1: echo $firstName $lastName
code 4: nested for() loops that increment x and y then multiply them
theory 1: gut says TTH, but I'm thinking either is equally random
theory 2: set 2 aside, weigh 3v3. if scales are even, the heavy one is in the two set aside. if scales tip, set one aside and weigh remaining two. same thing.
theory 3: start from floor 50 and test drop. if it breaks, go to 25. if not, go to 75. repeat by cutting gap in half each time.
>pretty sure this isn't right, because if it breaks actually breaks at 5 and your first two tests are at 50, then 25, at best you know it breaks at 25 or under. this isn't accurate enough imo but only allows for two eggs.

would love to hear the answers to these questions but totally understand you not posting them considering they're meant for an interview.

Wew
I guess programming just ain't for me

>gentoo

>not maining Gentoo

>not running debian in a VM

we got a special snowflake here.

no you don't

Code 1-5 are easy enough that anyone who paid attention in class can get them. 6 is the one that will show whether the candidate is a programmer or a copy/pasting "coder". Perfect syntax is not critical, but working logic is.

You can find the answers for most of the theory question online. Just make sure that you think about them enough to exercise your brains properly. If you just give up and get the answers, then you are robbing yourself of an opportunity to honestly test yourself.

>be in cram school with thirty two 4 (four) hours exam in may, in 8 different field with no connections whatsoever, over the course of less than a month
>not counting the oral exams afterwards
>my face when I read about little baby's problem

Just bought a fucking whiteboard to practice this cuck shit.

how do i not get tired from studying this all day

>study for interview

how else to prepare for 8 hour interview

They (e.g. Google) usually ask CS101 algorithms questions do you should be able to figure those out

Snort some meth to improve your self-confidence

Questions i'm seeing on glassdoor are definitely not CS101 questions. Have you interviewed with them or just pulling shit out of ass?

If they were just CS101 then you would see a good chunk of CS majors being google-ready, which obviously is not the case.

Having gone through multiple interview stages with companies like Uber(easiest), Facebook(medium) and Google(hardest). leetcode.com is your best bet, it's seriously worth just going through and solving from easiest to hardest. Every questions I've been asked has been there.

If you're going for a general software engineering role (or mobile in my case) they generally don't ask the 'hard' algorithm questions as there really just isn't enough time and they tend to be looking for your understanding of basic data structures and your thought process when you are given a problem (Do not underestimate how important this is). Due to this memorizing answers rarely works because it becomes quite obvious if you're pretending to solve a problem you already know the optimal answer to.
For this reason, what you should really be looking for is patterns in how particular problems can/should be solved and the correct data structures to use in the solution.

They potentially may throw you some general array based sorting problems but the smart thing is to focus on problems based around: LinkedLists, HashMaps and Binary trees. In that order.
It's also a good idea to practice both Iterative and recursive based solutions as some interviewers may ask you why you chose a particular approach or if you can implement both.

Be aware the faster you solve a particular issue (or they feel you didn't tell them you already know the solution), the more they're going to grill you on your implementation and why you made specific choices. They may even add extra parameters to the original question to complicate it.

Also if they've scouted you and you're going through their in-house recruiters, pay careful attention to what your recruiters tells you to do for prep, they're telling you for a reason and in one of my cases they gave me 3 example type questions they asked me 2 of them in the later stage interview. Remember, they better you perform, the better they look.

Good luck.

So should I memorize sorting algos or not?
If so, probably quicksort would be enough. yeah?

Code 5:
One array containing all card types (ace to jack)
One array containing card types (spades, clubs)

choose random from first array min being 0, max being array size
choose random from second array, min being 0, max being array size.

concatenate values from method call to be one card.

do method call again and display the other card.

Of course I didn't think of removing the card because the data structure doesn't support it, maybe just have a list of 52 cards.

This one is the end of me.

Code question 6:
Create a boolean array with the size of 1000.

Loop through array of integers
Set each Boolean index to true on each integer
If Boolean index was already set to true, break loop

Could also implement this using a hash set

Isn't hashset essentially the same as your first solution?
Can't you think of inserting the boolean in the i index for the number as a hash-table because the function is instant and no collisions?

any advantage to either?

bump because I really want to know if there is any difference.

With a hash set (of type integer) it reserves a portion of memory so that you can add integers to the set. Calling a contains method goes through a hash function to see whether the item exists in the hash set.

With a Boolean array you're specifying how large the portion of memory you're using, everything is initialised as false. You also can call each of the indexes of the array unlike a hash set. A hash set is great for searching items in the set but difficult to get all items in the set.

this is confusing me, but does this mean the boolean array method is better? instant search and get, yeah?

hashtable has to go through a hashfunction and potential collisions. so it's strictly worse in this instance?

The larger the Boolean array, the less efficient it becomes due to memory allocating space for pointers. The worse the hash function, the more collisions there are (running up to O(n))

With this example it's likely that a Boolean array would be faster, but don't take my word for it, try testing it out.

Interesting. thanks user.

Would having more memory for pointers in the Boolean array somehow slow down the function?
Does occupying more memory affect speed? Or is it independent of speed in that instance.

I should just time this shit out I guess.

Also to add: for Boolean arrays this is implying that you know the maximum number, as the maximum number is what determines the size of your Boolean array


HashSet

For loop:
If set.contains(number) break
set.add(number)


HashTable

For loop:
if set.containsKey(number)
If set[number] break //optional
Set.add(number, true)

Boolean array[1000]

For loop:
If arr[number] break
arr[number] = true

For loops:

why wouldn't you just make a loop that checks each index of the original array and return the current index if array[i-1] == array[i]. seems a lot simpler

And yet you still find time to shitpost?
You're going to fail you degenerate

c++ example
for(int i = 1; i < array.length(); ++i){
if(array[i] == array[i-1])return i;
}

or just start at index 0 and check for index i == i + 1, returning i + 1

this means the duplicate elements are right next to each other, problem talked about unsorted.

won't work.

Yes to be exact:

For a 32-bit Boolean array (up to index of 4M), eachindexis 4 byte integer and also 1 byte for reference to the bool array object, that makes 4 * 1000 + 1 = 4001 bytes

Depending how much memory the HashTable or HashSet takes it may be more or less. This is mostly handled by the library itself though.

Because that assumes that the duplicate is next to each other and not somewhere else.

Take for example {3, 7, 4, 2, 7}

true. misread the question

Whoops, miscalculation. It should be 1 * 1000 + 4 = 1004 bytes for a Boolean array of size 1000

int[] occurences = new int[array.size()];

for(int i = 0; i < array.size(); ++i){
++occurences[array[i]];
if(occurences[i] > 1)return i;
}

Still trying to understand how using more memory affects speed. Just want to understand exactly what is going on.

I understand that it may take more bytes, but where in the compiler or o/s will this affect speed? Doesn't saying array[n] always have the same fetch speed independent of array size? why does a bigger array take longer to fetch it?

Tell me about it
These CS retards don't know suffering until they've taken a test like the PCAT or MCAT

>be engineering student with 8 4-hours exam over 5 days
>hear about some mednigger trying to look down on others